積丹尼 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
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
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
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
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
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
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
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
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
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-
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,
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
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
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
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
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
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
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
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/
"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
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
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
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
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
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
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
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
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
"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
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
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
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
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
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
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
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
> 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
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.
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
> 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({
> 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
> 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
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
> 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
(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.
45 matches
Mail list logo