Thu 14 Sep 2017 06:43:07 AM UTC, comment #10:
thank you berny.
and for the other point:
is it so obvious, that '-name' only takes one argument? Because, as I pointed out several times it is not pointed out either in the "info"-file nor in the "man"-file.
Instead, I found an plural 's' in the 'info find'-document, node 'Primary Index'.
greetings,
kalle
|
Wed 13 Sep 2017 10:54:37 PM UTC, comment #9:
Sorry for the late reply - now I understand: there's really a "NON-BUGS" section in 'find.1'. Thanks for insisting.
The attached is an attempt to improve the explanation.
It would be good if a native English speaker could check.
Have a nice day,
Berny
(file #41800)
|
Tue 29 Aug 2017 07:23:11 AM UTC, comment #8:
>> -the number of acceptable -name arguments
>
> I tried to find a place both in find's manpage and the Texinfo
> manual (in latest Git), but didn't find an ambiguous place where
> I could read that -name would accept more than 1 argument.
> Would you please point to the relevant place?
As I pointed out in comment #5:
"I didn't find the place, where it does. What I found in man find was
'-name pattern' instead of 'patterns', but this is not a clear statement
imo. But also: in 'info find', node 'Primary Index' I fond '-name Base
name patterns' with s! "
I argued, that it is not written, that it accepts only one argument,
while you argue, that it is not written, that it accepts more than 1
argument. Is this a standard (that normally there is only one argument,
if not specified else) or why do you assume so? Then I would be sorry
for having taking your time because of this.
> -the insufficient non-bug explananation in man find [...]
> ________________^^^^^^^^^^^^^^^^^^^^^
> sorry, I don't understand what you mean by this.
> Would you please point to a place there you think is not
> sufficient (and suggest a better wording, ideally as a Git
> patch)?
I meant, that in "man find" the part "non-bug" assumes, that "of course"
the there given example will not work. No more explanation why. This is
not enough.
have a nice day,
kalle
|
Mon 28 Aug 2017 08:39:56 PM UTC, comment #7:
I pushed the commit with the NEWS entry fix:
https://git.sv.gnu.org/cgit/findutils.git/commit/?id=a8fc03d98036
> I think the discussion missed a bit what I pointed on:
> -the non-helping error message
Improved with Assaf's and my commits:
https://git.sv.gnu.org/cgit/findutils.git/commit/?id=9530e31f6d
https://git.sv.gnu.org/cgit/findutils.git/commit/?id=50a7c5d1f5
> -the number of acceptable -name arguments
I tried to find a place both in find's manpage and the Texinfo
manual (in latest Git), but didn't find an ambiguous place where
I could read that -name would accept more than 1 argument.
Would you please point to the relevant place?
-the insufficient non-bug explananation in man find [...]
________________^^^^^^^^^^^^^^^^^^^^^
sorry, I don't understand what you mean by this.
Would you please point to a place there you think is not
sufficient (and suggest a better wording, ideally as a Git
patch)?
Thanks & have a nice day,
Berny
|
Mon 28 Aug 2017 10:09:46 AM UTC, comment #6:
I think the discussion missed a bit what I pointed on:
-the non-helping error message
-the number of acceptable -name arguments
-the insufficient non-bug explananation in man find, in relationship to the number of -name arguments
-shell-globbing and good quoting wasn't the point. I also pointed this out by quoting the man find -non-bug.
kalle
|
Mon 28 Aug 2017 09:38:16 AM UTC, comment #5:
Dale wrote :
As far as I can tell, the error message means, "Syntactically, this is a situation where a predicate must occur, but this argument is not a predicate. It looks like what would happen if you tried to specify a directory, but didn't put it in front."
I don't understand what you want to say. I'm not totally sure about the term predicate: is "-name" a predicate? Where must a predicate occur, where it doesn't in my example? For the second and third search pattern?
Dale wrote:
You write, "How could one know, that options like "-name" can only have one name?" Well, the documentation says that -name can have only one argument.
I didn't find the place, where it does. What I found in man find was '-name pattern' instead of 'patterns', but this is not a clear statement imo. But also: in 'info find', node 'Primary Index' I fond '-name Base name patterns' with s!
Dale wrote:
The problem is amplified by the fact that what you wrote (.c) isn't what find saw ... but that is actually a central feature of all Unx-style shells -- the expansion of non-escaped wildcards (but only when they match at least one existing file). Like smoking a cigar in a fireworks store, it works fine as long as you're constantly aware of it.
I am aware of the problem of shell globbing but don't understand,what you write. For example, "that what you wrote (.c) isn't what find saw" was posted but not written by me, since I copied it from `man find'.
Dale wrote:
It would probably be better if the message didn't assume you were trying to specify a directory but rather explained the problem literally. Something like "Argument 4 is 'fax2.c', following 'find . -name fax1.c', but it is not used as an argument by the preceding predicate and directories to be searched must appear before all predicates."
I had some problems understanding your sentence, but now I think I understand it and agree with you.
|
Fri 18 Aug 2017 06:45:49 PM UTC, comment #4:
I like it - pushed at:
https://git.sv.gnu.org/cgit/findutils.git/commit/?id=9530e31f6d
Another follow-up (not yet pushed):
- [PATCH] doc: add a NEWS entry for the previous commit
|
Wed 16 Aug 2017 08:20:33 PM UTC, comment #3:
Hello all,
Since this type of erroneous usage is so common (forgetting to quote the shell glob pattern), perhaps it's worth detecting this case and giving a specific hint?
See the attached (mostly untested) patch, which gives:
$ touch a.txt b.txt c.txt
$ find -name *.txt
find: paths must precede expression: `b.txt'
find: possible unquoted pattern after predicate `-name'?
regards,
- assaf
(file #41546)
|
Wed 16 Aug 2017 03:21:03 PM UTC, comment #2:
Pushed:
https://git.sv.gnu.org/cgit/findutils.git/commit/?id=50a7c5d1f572
|
Thu 10 Aug 2017 01:53:49 AM UTC, comment #1:
Certainly the problem is real, but it's even more complicated.
As far as I can tell, the error message means, "Syntactically, this is a situation where a predicate must occur, but this argument is not a predicate. It looks like what would happen if you tried to specify a directory, but didn't put it in front."
You write, "How could one know, that options like "-name" can only have one name?" Well, the documentation says that -name can have only one argument.
The problem is amplified by the fact that what you wrote (.c) isn't what find saw ... but that is actually a central feature of all Unx-style shells -- the expansion of non-escaped wildcards (but only when they match at least one existing file). Like smoking a cigar in a fireworks store, it works fine as long as you're constantly aware of it.
It would probably be better if the message didn't assume you were trying to specify a directory but rather explained the problem literally. Something like "Argument 4 is 'fax2.c', following 'find . -name fax1.c', but it is not used as an argument by the preceding predicate and directories to be searched must appear before all predicates."
|
Wed 09 Aug 2017 11:12:29 PM UTC, original submission:
akraum@akraumGI ~/Downloads $ ls
2017-07-29_Entwurf-Berichtsteil-Lebensstile.pdf
Ant Videos
blockadesw.jpg
blockbunt.jpg
DSC1316.jpg
faustklein.JPG
fax.pdf
notanugget.jpg
todktter1.jpg
todktter2.jpg
Widerstand-gegen-Wiesenhof-Part-1.pdf
akraum@akraumGI ~/Downloads $ LANG=C find . -name fax* bloc*
find: paths must precede expression: blockadesw.jpg
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]
This was, what I got by typing two patterns into find-command. The answer "paths must precede expression" didn't help me any further in understanding the problem, since my path "." was preceding the expression "-name fax* bloc*".
How could one know, that options like "-name" can only have one name?
Invoking "man find", it says at the bottom of the page:
"NON-BUGS
$ find . -name *.c -print
find: paths must precede expression
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]
This happens because *.c has been expanded by the shell resulting in find actually receiving a command line like this:
find . -name bigram.c code.c frcode.c locate.c -print
That command is of course not going to work. Instead of doing things this way, you should enclose the pattern in quotes or escape the wildcard:
$ find . -name \*.c -print"
Here it assumes, that "of course" this will not work. No more explanation. This is not enough.
Furthermore I don't understand why it gave out to me the file "blockadesw.jpg". Obviously, it is the first file, to match a pattern.
My version is findutils 4.4.2
thanks,
kalle
|