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

 
 

bug #51711: non-helping error output with find

Submitter:  None
Submitted:  Wed 09 Aug 2017 11:12:29 PM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  berny
Originator Name:  kalle Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.4.2
Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group administrator
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>
Group administrator
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>
Group administrator
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: 
Bernhard Voelker <berny>
Group administrator
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 Un*x-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 Files:
   
   
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
  • -email is unavailable- added by jay (Updated the item)
  • -email is unavailable- added by agn (Updated the item)
  • -email is unavailable- added by berny (Posted a comment)
  • -email is unavailable- added by worley (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-08-29 jay Open/ClosedOpen Closed
    2017-09-13 berny Attached File- Added 0001-find.1-improve-explanation-in-the-NON-BUGS-section.patch, #41800
    2017-08-18 berny Attached File- Added 0001-doc-add-a-NEWS-entry-for-the-previous-commit.patch, #41572
    2017-08-16 agn Attached File- Added 0001-find-give-helpful-hint-for-unquoted-patterns-errors.patch, #41546
    2017-08-16 berny StatusNone Fixed
        Assigned toNone berny

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code