Current Gentoo stable version `findutils-4.1.20-r1' and latest Gentoo unstable version `findutils-4.2.20' don't accept repetition specification `\{N\}' in regex expression where N stands for N-times. Consequently, $ find -regex '.*/[a-z]\{4\}\.html' -print doesn't find a file name like `abcd.html' I have tested the latest GNU version `findutils-4.2.23'. Repetition specification does work under this version. I would like to request the inclusion of version 4.2.23 in Portage tree. Reproducible: Always Steps to Reproduce: 1. 2. 3. root:Build# emerge --info Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r9 x86_64) ================================================================= System uname: 2.6.12-gentoo-r9 x86_64 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=nocona -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.ecc.u-tokyo.ac.jp/GENTOO http://mirror.gentoo.gr.jp http://gentoo.gg3.net/ http://mirror.averse.net/pub/gentoo/ http://gentoo.channelx.biz/ http://gentoo.arcticnetwork.ca/ http://cudlug.cudenver.edu/gentoo/ http://ftp.gentoo.or.kr/ ftp://gg3.net/pub/linux/gentoo/ http://gentoo.mirrors.easynews.com/linux/gentoo/" LINGUAS="en ja" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X alsa avi berkdb bitmap-fonts cdr crypt cups curl eds encode esd fam foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib ipv6 java jpeg kde libwww lzw lzw-tiff mad motif mp3 mpeg mysql ncurses nls ogg opengl pam pdflib perl png python qt quicktime readline ruby sdl slang spell ssl tcltk tcpd tetex tiff truetype-fonts type1-fonts usb userlocales vorbis xine xml2 xmms xpm xv zlib linguas_en linguas_ja userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
There are some changes in regex syntax since findutils-4.2.21. Regex meta-character `+' in old syntax must be written as `\+' in new syntax, which may have a significant side-effect in various system-administration scripts. Hasty move to findutils-4.2.23 may not be such a good idea, after all.
4.2.23 is in the tree. It's in package.mask for a bit. Stefaan -- please could you test this on an AFS system and let me know what I need to change? SELinux people -- I forward ported your patch. Don't know whether it works...
Created attachment 67246 [details, diff] findutils-selinux.patch you could just take the selinux patch from Redhat ... this is what they use for 4.2.23
Doesn't work with USE flag afs, mainly because they crippled the code upstream. I filed a bugreport there, number 14332.
Remarks in comment #4 have been fixed in findutils-cvs. But I guess a linking problem remains (there's currently no code included in the ebuild to locate and link with the 'pioctl'-symbol).
Ok, how about we just totally drop the AFS stuff?
For now, that seems like an excellent option to me. I may take a look at afs support in findutils in the future, and will submit patches upstream when I do. But I'm not giving that any priority. The main reason we actually do want afs support in findutils, is the following error message: sderoeck@olympia /afs/stefaan.ulyssis.org $ /usr/bin/find > /dev/null /usr/bin/find: WARNING: Hard link count is wrong for .: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched. I also got this recently: stefaan@defiant /afs/stefaan.ulyssis.org $ find > /dev/null find: ./.. changed during execution of find And, I also envision an option to findutils that would let you skip backup volumes, so you just need to search half of what you used to. But this is just a preliminary idea. But in short, I agree that afs-support in findutils should be dropped until findutils does something sensible with afs.
Yay.
