[bug #51711] non-helping error output with find

[James Youngman]

Update of bug #51711 (project findutils):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #51711] non-helping error output with find

[anonymous]

Follow-up Comment #10, bug #51711 (project findutils):

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

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

[Bernhard Voelker]

Follow-up Comment #9, bug #51711 (project findutils):

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

Additional Item Attachment:

File name: 0001-find.1-improve-explanation-in-the-NON-BUGS-section.patch
Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [bug #51711] non-helping error output with find

[kalle]

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

[bug #51711] non-helping error output with find

[anonymous]

Follow-up Comment #8, bug #51711 (project findutils):



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



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

[Bernhard Voelker]

Follow-up Comment #7, bug #51711 (project findutils):

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

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

[anonymous]

Follow-up Comment #6, bug #51711 (project findutils):

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

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

[anonymous]

Follow-up Comment #5, bug #51711 (project findutils):

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

[Bernhard Voelker]

Additional Item Attachment, bug #51711 (project findutils):

File name: 0001-doc-add-a-NEWS-entry-for-the-previous-commit.patch Size:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

[Bernhard Voelker]

Follow-up Comment #4, bug #51711 (project findutils):

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

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

[Assaf Gordon]

Follow-up Comment #3, bug #51711 (project findutils):

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

Additional Item Attachment:

File name: 0001-find-give-helpful-hint-for-unquoted-patterns-errors.patch
Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

[Bernhard Voelker]

Update of bug #51711 (project findutils):

  Status:None => Fixed  
 Assigned to:None => berny  

___

Follow-up Comment #2:

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

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [bug #51711] non-helping error output with find

[Bernhard Voelker]

On 08/10/2017 01:12 AM, anonymous wrote:
> 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.

Sorry to say, but actually you did not pass 2 patterns to find.
Instead, you rather passed the 2 patterns to the shell which
globbed the file names before passing them to find(1).

With the above content of the directory (which is presumably
the output of 'ls -1' instead of the shown 'ls'), the shell
passed 3 arguments after the -name option; this can easily be
demonstrated by prepending the command line with 'echo':

  $ echo find . -name fax* block*
  find . -name fax.pdf blockadesw.jpg blockbunt.jpg
  ...

And find told you the offending part.

I have to admit that the file name is a little lost in the error
diagnostic.  IMO the file name should be quoted, and the "Usage"
text should be omitted.  With this, the actual error would be
more prominent:

  $ find . -name fax* block*
  find: paths must precede expression: `blockadesw.jpg'

The attached fixes it.  Comments?

Have a nice day,
Berny
>From 50a7c5d1f572d50d6c9d43d04e9c9fd55d66b466 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Thu, 10 Aug 2017 08:45:56 +0200
Subject: [PATCH] find: avoid usage() in more error cases

When the user passes a bad command line, then find(1) outputs the
error message followed by a short usage() text, e.g. (wrapped):

  $ find . -name a* b*
  find: paths must precede expression: bfile
  Usage: find [-H] [-L] [-P] [-Olevel] \
  [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]

Omit the usage() text in more cases like this in order to make the
error diagnostic more eye-catching.

* find/tree.c (build_expression_tree): Exit with EXIT_FAILURE
immediately in more cases, i.e., without outputting also a short
usage() text.  While at it, add quotes around the offending argument
in one another place.
* NEWS (Improvements): Mention the fix.

Reported in https://savannah.gnu.org/bugs/?51711
---
 NEWS|  3 +++
 find/tree.c | 17 +
 2 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/NEWS b/NEWS
index 2f263aa..61269c1 100644
--- a/NEWS
+++ b/NEWS
@@ -35,6 +35,9 @@ of the - yet more portable - '( -type l -o -type d )'.
 find now diagnoses failures returned by readdir().  This bug was inherent
 in the use of FTS.
 
+find now exits in more cases immediately after the error diagnostic, i.e.,
+without the following usage text, to make the former more eye-catching.
+
 xargs now supports the -o, --open-tty option to reopen stdin as /dev/tty
 in the child process before executing the command; useful to run an
 interactive application.  Added for compatibility with BSD.
diff --git a/find/tree.c b/find/tree.c
index 2bbfbe5..ee466ea 100644
--- a/find/tree.c
+++ b/find/tree.c
@@ -1275,18 +1275,14 @@ build_expression_tree (int argc, char *argv[], int end_of_leading_options)
 {
   state.already_issued_stat_error_msg = false;
   if (!looks_like_expression (argv[i], false))
-	{
-	  error (0, 0, _("paths must precede expression: %s"), argv[i]);
-	  usage (EXIT_FAILURE);
-	}
+	error (EXIT_FAILURE, 0, _("paths must precede expression: `%s'"), argv[i]);
 
   predicate_name = argv[i];
   parse_entry = find_parser (predicate_name);
   if (parse_entry == NULL)
 	{
 	  /* Command line option not recognized */
-	  error (0, 0, _("unknown predicate `%s'"), predicate_name);
-	  usage (EXIT_FAILURE);
+	  error (EXIT_FAILURE, 0, _("unknown predicate `%s'"), predicate_name);
 	}
 
   /* We have recognised a test of the form -foo.  Eat that,
@@ -1306,21 +1302,18 @@ build_expression_tree (int argc, char *argv[], int end_of_leading_options)
 		  /* The special parse function spat out the
 		   * predicate.  It must be invalid, or not tasty.
 		   */
-		  error (0, 0, _("invalid predicate `%s'"), predicate_name);
-		  usage (EXIT_FAILURE);
+		  error (EXIT_FAILURE, 0, _("invalid predicate `%s'"), predicate_name);
 		}
 	  else
 		{
-		  error (0, 0, _("invalid argument `%s' to `%s'"),
+		  error (EXIT_FAILURE, 0, _("invalid argument `%s' to `%s'"),
 			 argv[i], predicate_name);
-		  usage (EXIT_FAILURE);
 		}
 	}
 	  else
 	{
 	  /* Command line option requires an argument */
-	  error (0, 0, _("missing argument to `%s'"), predicate_name);
-	  usage (EXIT_FAILURE);
+	  error (EXIT_FAILURE, 0, _("missing argument to `%s'"), predicate_name);
 	}
 	}
   else
-- 
2.1.4

[bug #51711] non-helping error output with find

[Dale Worley]

Follow-up Comment #1, bug #51711 (project findutils):

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."

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

[anonymous]

URL:
  

 Summary: non-helping error output with find
 Project: findutils
Submitted by: None
Submitted on: Wed 09 Aug 2017 11:12:29 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: kalle
Originator Email: ka...@projektwerkstatt.de
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.4.2
   Fixed Release: None

___

Details:

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




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/