Re: find: ... -ok rmdir ... No such file or directory

2019-07-28 Thread Dale R. Worley
積丹尼 Dan Jacobson writes: > All I know is you need to document "in this case, find, for some reason, > needs to needlessly check the directory is still there after the command > it invokes exits, therefore one needs to add -depth" (I don't recall > Unix find(1) had such weird habits.) > > Anyway, t

Re: The returned value of -prune and its documentation

2019-04-30 Thread Dale R. Worley
Cristian Zoicas writes: > The following directory structure and the following statement show that -prune > does not return false when -depth is given. > > mkdir -p test/s_files/ > echo a-top > test/a-top.txt > echo s-top > test/s-top.txt > echo a > test/s_files/a.txt > echo s1 > test/s_files/s1.tx

Re:

2019-03-15 Thread Dale R. Worley
I think what you are asking for is something like: i=0 while ... do find . -mindepth $i -maxdepth $i ... i=$(( i+1 )) done That will look at all the files and directories at one depth before looking at all the files and directories at the next greater depth. (It doesn

Re: Introduce posix_spawn

2018-09-06 Thread Dale R. Worley
Tavian Barnes writes: > One thing you'll probably run into is that posix_spawn() has no interface > for running the spawned process in a new working directory. That makes > implementing -execdir/-okdir somewhat awkward. Couldn't you change the w.d. to the correct target, spawn, and then change t

Re:

2018-07-30 Thread Dale R. Worley
James Youngman writes: [From Posix:] >> The st_ino and st_dev fields taken together uniquely identify the >>file within the system. > > Find (for example in the -samefile test) relies on this behaviour. > However, if only one file on the whole system has st_ino==0, this > uniqueness condition stil

Re: Manual Readability Feedback

2018-07-11 Thread Dale R. Worley
A couple of quite minor items: Bernhard Voelker writes: >> "Only use 'assert' to catch fully-implemented features of your code." > ^~~~ > > This sounds odd to me - as non-native English speaker - as well. > What about "Avoid to use 'assert' to m

Re: Why is `find -name '*.txt'` much slower than '*.txt' on glusterfs?

2018-01-21 Thread Dale R. Worley
James Youngman writes: > Perhaps stat calls are relatively > expensive on glusterfs (this happens on at least some other cluster > filesystems because obtaining a correct value fort st_size requires finding > the consensus answer for the current length of the file, while obtaining > the list of it

Re: Why is `find -name '*.txt'` much slower than '*.txt' on glusterfs?

2018-01-20 Thread Dale R. Worley
Peng Yu writes: > There are ~7000 .txt files in a directory on glusterfs. Here are the run > time of the following two commands. Does anybody know why the find command > is much slower than *.txt? Is there a way to change the API that `find` > uses to search files so that it can be more friendly t

Re: Bizzare bug in find, potential security implications

2017-12-22 Thread Dale R. Worley
Bernhard Voelker writes: > As the OPs case just needs matches for the suffix of the basename, > I'd personally always go with good old -name: > > find htdocs -type f -name '*.exe' Yes. I would use -iname, because I'm unsure of what rules Windows uses to decree a file as executable. Dale

Re: Bizzare bug in find, potential security implications

2017-12-21 Thread Dale R. Worley
Eric Blake writes: > POSIX says that regex only has to match characters (in particular, the > glob '.' matches characters, not encoding errors). If you pick a locale > with multibyte characters that are subject to encoding errors when > processing random bytes (as is the case when using a UTF-

Re: Fwd: bug#28079: find -type l -xtype and recursive symbolic links

2017-08-15 Thread Dale R. Worley
The problem is that the property "a symbolic link that points to itself" actually isn't related to any of the properties that find's predicates test. (Other than that it has to be a symbolic link, trivially.) It's also messier than that phrasing says, since the link could point to *another* link,

Re: "find: '/usr/...': Too many open files" when using -execdir

2017-06-04 Thread Dale R. Worley
Kamil Dudka writes: > I believe it is fixed by the following upstream commit, which includes also > indentation changes, unfortunately: > > http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=183115d0 And "git tag --contains=183115d0" shows that it's in 4.5.12 and later versions. Unfo

"find: '/usr/...': Too many open files" when using -execdir

2017-06-03 Thread Dale R. Worley
I know I've seen something about this before: When I use -execdir, I get a message like: find: '/usr/share/texlive/texmf-dist/tex4ht/ht-fonts/alias/kurier/sy-iwona': Too many open files find: Failed to save working directory in order to run a command on 'qx-iwonacap': Too many open files But I

Re: [bug #51069] find changes access time on directories

2017-05-22 Thread Dale R. Worley
Adesh Kumar writes: > I thought "find" uses only stat syscalls, but yeah I can see how that > cannot help with directory contents. My guess is that for simple tests > like iname or name, find does not need to read the direcotry list. Is > my understanding correct? As I consider it intuitively (wh

Re: Documentation of -atime, etc.

2017-04-04 Thread Dale R. Worley
Andreas Metzler writes: > Try it out. ;-) Starting with a directory of files with mtime x hours > + a couple of minutes ago (x=1..48) and named as such: Thanks for the information. Normally I dislike "experimental programming" because I never can tell (a) whether the behavior I'm seeing is *spec

Documentation of -atime, etc.

2017-03-31 Thread Dale R. Worley
I was looking at an old sandbox I have that contains some partially-made changes to the documentation of -atime and related predicates. In find.texi is: @deffn Test -atime [+|-]n @deffnx Test -ctime [+|-]n @deffnx Test -mtime [+|-]n True if the file was last accessed (or its statu

Re: RFE: allowing "" as a path specification for 'current dir' w/o prepending './' ?

2017-02-28 Thread Dale R. Worley
L A Walsh writes: > What do 'ls' and 'du' do, since in the absence of a path > they start from the current directory but don't seem to > prepend './'. However, I would not want to change how find > operates in the absence of a path -- compatibility problems. I think these show that the curre

Re: debugging --findoptions (Possible bug fix) updatedb (GNU findutils) 4.6.0

2017-01-17 Thread Dale R. Worley
Freeman Mayberry writes: > So updatedb was taking too long, as in never finishing, I decided to try > and find out why. However when I entered (after much googling): > > nice -n -19 updatedb --findoptions="-D stat" > > it kept telling me the option was not found. > > > In file C:\cygwin64\bin\upda

Explaining +/-n

2016-11-22 Thread Dale R. Worley
I started working out the manual changes to address http://savannah.gnu.org/bugs/?49640 Because my setup is old, I figured I'd start trying out the new wording using commit 1a009ccb from 2015-12-20. But the structure of that commit is peculiar: the find.1 manual page is installed from findutils/

Re: [CLEAR] alias find issue

2016-09-07 Thread Dale R. Worley
"Julien Rivoal" writes: > I have a question for an aliases utilization, I use since a long times this > alias : alias ff='find . -name "\!*" -print' > > And now I can't use it and I don't understand why ? I assume that the goal is to find all files whose names start with the "!" character. The c

Re: link

2016-07-25 Thread Dale R. Worley
Pascal writes: > I think I misled on "*except while processing the command line argument*" > for the -H option, wich is for find and not for exec command :-( > after some internet research, I tried this : > > find . -type l -exec sh -c "md5sum \$( readlink {} )" \; > d41d8cd98f00b204e9800998ecf842

Re: link

2016-07-22 Thread Dale R. Worley
Pascal writes: > how find links and exec command on pointed files ? > > $ touch a > $ ln -s a b > $ ll > a > b -> a > $ find -H . -type l -exec md5sum '{}' \; > d41d8cd98f00b204e9800998ecf8427e ./b > > md5sum is running on "./b" and not on "./a" like excepted :-( But that is the behavior expecte

Re: examples in find's man page

2016-07-17 Thread Dale R. Worley
James Youngman writes: >> > find /sbin /usr/sbin -executable \! -readable -print >> >> let's escape ! here for no reason > > The interpretation of and quoting rules for ! have changed > substantially over the years (for example, it is a reserved word in > only some sh variants, and who knows how i

Re: find -die. -exec-die-upon-error

2016-05-12 Thread Dale R. Worley
Dan Jacobson writes: > Or perhaps -exec ... -o -die > > How could find live without a -die action? How about "-quit", which seems to be implemented in find 4.5.11? -quit Exit immediately. No child processes will be left running, but no more paths specified on the comman

Re: Patches to -type x,y,z

2016-04-06 Thread Dale R. Worley
Bernhard Voelker writes: > I thought a bit about the implementation and thought it'd be better > to avoid artificially creating the OR-ed predicates, and rather store > the wanted file types in an array and check for that in pred.c. > I think this should be faster, too. I may be overlooking somet

Re: [6 PATCHES] New feature added to find: -type xyz

2016-03-02 Thread Dale R. Worley
Eric Blake writes: >> The instructions to build is in the README-hacking file. Perhaps we >> should add INSTALL file. > > INSTALL is generated as part of bootstrapping the package. > README-hacking tells how to bootstrap the package. Building from git is > different than building from a tarball

Re: [6 PATCHES] New feature added to find: -type xyz

2016-03-01 Thread Dale R. Worley
Young Mo Kang writes: > I have modified from the most recent git commit 4.7.0-git > 19f6f691de4f41b4af76c33782a96f191378830a to enable this feature, but > have not done much testing; I just added one simple test case. It looks like that is the latest commit, but it hasn't been named "4.7.0" in an

Re: [6 PATCHES] New feature added to find: -type xyz

2016-02-29 Thread Dale R. Worley
Young Mo Kang writes: > I just thought it would be useful to enable multiple type search at > once feature in find, i.e., find's option "-type xyz" can be a > shorthand form for "( -type x -o -type -y -o -type z )". It should > work with -xtype exactly the same way. I heartily support this featur

Re: find traverses through directory while it's excluded

2016-02-12 Thread Dale R. Worley
"PenguinWhispererThe ." writes: > So while someone might think -not -iwholename excludes that directory that > is looping it will still traverse it. > Why is find still traversing if a directory is excluded? > Is this for corner-cases? Can someone give an example of those? > > I understand there i

Re: on interrupt, xargs does not wait for subprocess to exit

2015-08-27 Thread Dale R. Worley
Frederik Eaton writes: > In brief: > > $ seq 1 10 | xargs sh -c 'trap "" INT; sleep 3; echo hi' > ^C > [130]$ hi > > Notice that I pressed ^C and xargs exited, the shell prompt appeared, > some seconds later the word "hi" appeared. > > Is this the correct behavior for xargs? It could b

Re: Allow `find` to use exported function for -exec*?

2015-04-16 Thread Dale R. Worley
Eric Blake writes: > On 04/15/2015 08:50 PM, Peng Yu wrote: >> Hi, It seems that it might be convenient to allow `find` to use >> exported functions from shell for -exec*? Can this feature be added in >> the future? > > If your shell supports function exports, then the feature already > exists. M

Re: Faster way to prune directory?

2015-04-16 Thread Dale R. Worley
Bernhard Voelker writes: >> real 0m5.354s >> user 0m1.145s >> sys 0m1.539s > > Well, half a second for times creating and running /usr/bin/test > doesn't seem too much. At least, I can second your timing results. In a sense, the question is "Do you think that creating, running, and destroyi

Re: -exec test (use which to only find test once)

2015-03-29 Thread Dale R. Worley
James Youngman writes: > While I agree with you from a technical point of view, had find been > implemented the other way (figuring out the absolute path to the > utility on startup) I would not find this a convincing argument to > change that hypothetical existing implementation :) True, had fin

Re: -exec test (use which to only find test once)

2015-03-25 Thread Dale R. Worley
Peng Yu writes: > I find that "-exec test ..." can be slower than "-exec $(which test) > ...". Is possible that `find` internally use "which", so that users > don't need to explicitly call it? It's possible, I suppose, but the semantics of -exec can be changed by turning the program name into a s

Re: question about contributing

2015-03-22 Thread Dale R. Worley
Pietro Bertera writes: > this old patch: http://savannah.gnu.org/bugs/?27558 should works with > all systems compatible with Posix 1e (IEEE 1003.1e). Honestly at the > time I wrote it I tested only on GNU/Linux. If I read the man page change in that patch correctly, the test passes if the file co

Re: How test for directory with single quote (') in the name (with find)?

2015-03-05 Thread Dale R. Worley
Peng Yu writes: > /tmp/tryfind$ find . -type f > ./'/.export > /tmp/tryfind$ find . -type d -exec sh -c "test -d '{}'/.export" ';' -print > sh: -c: line 0: unexpected EOF while looking for matching `'' > sh: -c: line 1: syntax error: unexpected end of file The problem is that you're constructing

Re: Feature request for find command -- process "nodump" flag

2014-11-29 Thread Dale R. Worley
> Date: Wed, 26 Nov 2014 19:36:53 -0600 > From: Derek Pressnall > > Since the find command is often used to generate a list of files to > include in a system backup, it would be useful if it included tests > for some filesystem-specific tests such as the "dump" extended > attribute flag on the ex

Re: bug in find?

2014-10-27 Thread Dale R. Worley
One way to phrase it is "Do you know how quoting works?" If the shell sees an argument like "*.zip*" (the quotes are mine, not part of the argument), then: 1) If expanding *.zip* finds one or more files, the shell changes the argument into a series of arguments which are the names of the files.

Re: bug in find?

2014-10-27 Thread Dale R. Worley
There is kind of an error: The message "paths must precede expression" does not really make sense. What is meant is "One of the arguments that is part of the expression does not start with '-' like it should. Perhaps it is the name of a path to search, but the paths have to be before the express

Re: /opt/bin/find error

2014-10-14 Thread Dale R. Worley
> From: James Youngman > > open(".", O_RDONLY|O_LARGEFILE) = 3 > > fcntl64(3, F_GETFD) = 0 > > fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 > > uname({sys="Linux", node="Venus", ...}) = 0 > > ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0 > > gettimeofday({

Re: /opt/bin/find error

2014-10-13 Thread Dale R. Worley
> From: Steve Forman > > I'm getting this error and can find absolutely no information on it. > find: ‘.’: Unknown error -89 > > No matter what path I use I always get this message. > Any ideas? What is the command line? http://www.chiark.greenend.org.uk/~sgtatham/bugs.html Dale

Re: /opt/bin/find error

2014-10-13 Thread Dale R. Worley
> From: Steve Forman > > I'm getting this error and can find absolutely no information on it. > find: ‘.’: Unknown error -89 > > No matter what path I use I always get this message. > Any ideas? What is the name/description of error 89 in your system's errno.h file? In the set of files that yo

Small fix to README-hacking

2014-09-16 Thread Dale R. Worley
This is trivial, but how the Git pre-commit hook is distributed has changed, and README-hacking needs to be updated. Dale >From e45baabec78f1745a92cf9fc50d6a4ce450b793c Mon Sep 17 00:00:00 2001 From: "Dale R. Worley" Date: Tue, 16 Sep 2014 12:21:30 -0400 Subject: [PATCH] C

Re: Problem with import-gnulib.sh

2014-09-16 Thread Dale R. Worley
> From: Bernhard Voelker > So for your case, I recommend to do what the above output already > suggested: remove the gnulib directory and start over with > import-gnulib.sh. And indeed, I did delete ./gnulib (it was empty, so it looked safe), and everything worked. I just wanted to make sure pe

Problem with import-gnulib.sh

2014-09-15 Thread Dale R. Worley
(I hope this is going to the right place for discussions.) I'm looking at making some modifications to 'find'. Looking at the instructions in README-hacking, I do: $ git clone git://git.sv.gnu.org/findutils Cloning into 'findutils'... remote: Counting objects: 18835, done.