bugfindutils - Bugs: bug #51711, non-helping error output with find

 
 

bug #51711: non-helping error output with find

Submitted by:  None
Submitted on:  Wed 09 Aug 2017 11:12:29 PM UTC  
 
Category: findSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Bernhard Voelker <berny>
Originator Name: kalleOriginator Email: -unavailable-
Open/Closed: OpenRelease: 4.4.2
Fixed Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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

Anonymous
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)

Bernhard Voelker <berny>
Project MemberIn charge of this item.
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

Anonymous
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

Bernhard Voelker <berny>
Project MemberIn charge of this item.
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

Anonymous
Mon 28 Aug 2017 09:38:16 AM UTC, comment #5:

Dale wrote :
As far as I can tell, the error message means, &quot;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.&quot;

I don't understand what you want to say. I'm not totally sure about the term predicate: is &quot;-name&quot; 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, &quot;How could one know, that options like &quot;-name&quot; can only have one name?&quot; 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, &quot;that what you wrote (.c) isn't what find saw&quot; 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 &quot;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.&quot;

I had some problems understanding your sentence, but now I think I understand it and agree with you.

Anonymous
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
Bernhard Voelker <berny>
Project MemberIn charge of this item.
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)

Assaf Gordon <agn>
Wed 16 Aug 2017 03:21:03 PM UTC, comment #2:

Pushed:
https://git.sv.gnu.org/cgit/findutils.git/commit/?id=50a7c5d1f572

Bernhard Voelker <berny>
Project MemberIn charge of this item.
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."

Dale Worley <worley>
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

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #41800:  0001-find.1-improve-explanation-in-the-NON-BUGS-section.patch added by berny (2KiB - text/x-patch - [PATCH] find.1: improve explanation in the NON-BUGS section)
file #41572:  0001-doc-add-a-NEWS-entry-for-the-previous-commit.patch added by berny (988B - text/x-patch - [PATCH] doc: add a NEWS entry for the previous commit)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by agn (Updated the item)
  • -unavailable- added by berny (Posted a comment)
  • -unavailable- added by worley (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 13 Sep 2017 10:54:37 PM UTCbernyAttached File-=>Added 0001-find.1-improve-explanation-in-the-NON-BUGS-section.patch, #41800
    Fri 18 Aug 2017 06:47:21 PM UTCbernyAttached File-=>Added 0001-doc-add-a-NEWS-entry-for-the-previous-commit.patch, #41572
    Wed 16 Aug 2017 08:20:33 PM UTCagnAttached File-=>Added 0001-find-give-helpful-hint-for-unquoted-patterns-errors.patch, #41546
    Wed 16 Aug 2017 03:21:03 PM UTCbernyStatusNone=>Fixed
      Assigned toNone=>berny

    Back to the top


    Powered by Savane 3.1-cleanup1