bugfindutils - Bugs: bug #58205, Double dash option (--) mentioned...

 
 

bug #58205: Double dash option (--) mentioned only in manpage, unclear/nonworking

Submitter:  Andreas Metzler <ametzler>
Submitted:  Sun 19 Apr 2020 11:49:20 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  berny
Originator Name:  Open/Closed:  Closed
Release:  None Fixed Release:  4.8.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 17 Aug 2020 10:07:46 AM UTC, comment #5: 

Thanks for the review.
I already pushed.
Marking this as fixed.

Have a nice day,
Berny

Bernhard Voelker <berny>
Group administrator
Mon 17 Aug 2020 09:12:59 AM UTC, comment #4: 

Bernhard Voelker wrote in comment #3:

> Thanks for your comments.
> I suggest the attached documentation change.

[...]

> (file #49666)


Looks good. Thank you!

cu Andreas

Andreas Metzler <ametzler>
Thu 13 Aug 2020 10:23:59 PM UTC, comment #3: 

Thanks for your comments.
I suggest the attached documentation change.

Have a nice day,
Berny

(file #49666)

Bernhard Voelker <berny>
Group administrator
Tue 23 Jun 2020 05:31:51 PM UTC, comment #2: 

Bernhard Voelker <INVALID.NOREPLY@gnu.org> wrote:

> Andreas Metzler wrote

[...]

> The "--" separates the options from the rest of the call arguments,
> which for find(1) could be path arguments followed by predicates
> (i.e. tests and actions).


> Unfortunately, the synopsis in the manpage does not show this.
> It should be changed like this:


> -find [-H] [-L] [-P] [-D debugopts] [-Olevel] [starting-point...]
> [expression]
> +find [-H] [-L] [-P] [-D debugopts] [-Olevel] [--] [starting-point...]
> [expression]


Thanks for expanding on the manpage. It matches my "Imho the
functionality does not make a lot of sense for find," ;-)
"--" would allow specifying "-L" instead of ./-L (but not -print instead
of ./-print) if it was implemented as documented.

> The problem with the synopsis of find(1) - which is veeerry old - is that
> there's no way to tell find whether a word following the "--" is a starting
> point or an expression.


> This is reflected in your other examples:


> > ametzler@argenau:/tmp/findtest$ LANG=C find -- -L
> > find: unknown predicate `-L'
> The next argv[i] is -L, and as it starts with a minus "-", find
> assumes that now an expression would follow.  As it does not know
> the expression -L (it is an option!), it complains about that
> "unknown predicate".


That is a bug imho. "--" says no options after this point in the
commandline.  i.e. any literal "-H", "-L", "-P", "-D debugopts",
"-Olevel" or "--" is to be taken literally (be it either as a starting
point or as argument in an expression) That is a straightforward
algorithm, isn't it?

>> ametzler@argenau:/tmp/findtest$ LANG=C find ./ -- -regextype grep
>> find: unknown predicate `--'
> The tool already detected at the "./" argument, that the options (-L,-H,...)
> have ended, then hits "--" which falls in the same case as above:
> it starts with a minus "-", but is not a "known predicate".


Same bug as above. Since the -- is an option, and cannot be specified
after the first path it must be interpreted as a starting point.

> > ametzler@argenau:/tmp/findtest$ LANG=C find -- *
> > find: unknown predicate `-L'
> Here, find knows from the "--" that no options (-L,-H,...) will follow.
> Now it depends on the shell globbing which file name is passed next.
> In this case, it is again the file "-L", but find has no chance to know
> that the user wanted to pass it as file name.


As above.

[...]

> The only thing I can think of to get out of this dilemma is to add an
> option to read the starting points from a file, best Zero-separated.


> # Pass starting points before expressions:
> find [-H] [-L] [-P] [-D debugopts] [-Olevel] [--] [starting-point...]
> [expression]
> # Alternative synopsis: read starting points from file:
> find [-H] [-L] [-P] [-D debugopts] [-Olevel] -files0-from=FILE [--]
> [expression]


> # e.g.
> ... | find -L -files0-from=- -type f ...


Well, since none of the (useless) cases where "--" should work according
to the documentation actually do work and never have it might be best to
either totally drop "--", or warn avbout it and mark it in the
documentation as it exists but does nothing useful.

Imho adding a -files0-from option is not called for, there exists a well
known workaround (./-L).

cu Andreas

Andreas Metzler <ametzler>
Sun 21 Jun 2020 10:41:13 PM UTC, comment #1: 

Sorry for the late reply, I did not receive an email for this issue.

The "--" separates the options from the rest of the call arguments,
which for find(1) could be path arguments followed by predicates
(i.e. tests and actions).

Unfortunately, the synopsis in the manpage does not show this.
It should be changed like this:


-find [-H] [-L] [-P] [-D debugopts] [-Olevel] [starting-point...] [expression]
+find [-H] [-L] [-P] [-D debugopts] [-Olevel] [--] [starting-point...] [expression]


The problem with the synopsis of find(1) - which is veeerry old - is that
there's no way to tell find whether a word following the "--" is a starting point
or an expression.
This is reflected in your other examples:

> ametzler@argenau:/tmp/findtest$ LANG=C find -- -L
> find: unknown predicate `-L'

The next argv[i] is -L, and as it starts with a minus "-", find
assumes that now an expression would follow.  As it does not know
the expression -L (it is an option!), it complains about that
"unknown predicate".

> ametzler@argenau:/tmp/findtest$ LANG=C find ./ -- -regextype grep
> find: unknown predicate `--'

The tool already detected at the "./" argument, that the options (-L,-H,...)
have ended, then hits "--" which falls in the same case as above:
it starts with a minus "-", but is not a "known predicate".

> ametzler@argenau:/tmp/findtest$ LANG=C find -- *
> find: unknown predicate `-L'

Here, find knows from the "--" that no options (-L,-H,...) will follow.
Now it depends on the shell globbing which file name is passed next.
In this case, it is again the file "-L", but find has no chance to know
that the user wanted to pass it as file name.

I don't think adding another kind of separator like "--" to force find to treat
some argument as starting points would help here, because that would have
the same problem:

find [-H] [-L] [-P] [-D debugopts] [-Olevel] [--] [starting-point...] [--] [expression]

# What if there is a file named "--"?  This would also fail ...
find -L -- * -- -type f


The only thing I can think of to get out of this dilemma is to add an
option to read the starting points from a file, best Zero-separated.

# Pass starting points before expressions:
find [-H] [-L] [-P] [-D debugopts] [-Olevel] [--] [starting-point...] [expression]
# Alternative synopsis: read starting points from file:
find [-H] [-L] [-P] [-D debugopts] [-Olevel] -files0-from=FILE [--] [expression]

# e.g.
... | find -L -files0-from=- -type f ...


Bernhard Voelker <berny>
Group administrator
Sun 19 Apr 2020 11:49:20 AM UTC, original submission:  

Hello,

quoting find.1:
-----------
This manual page talks about `options' within the expression list. These options control the behaviour of find but are specified  immediately after the last path name. The five `real' options -H, -L, -P, -D and -O must appear before the first path name, if at all.   A  double dash -- can also be used to signal that any remaining arguments are not options (though ensuring that all start points begin with  either  `./' or  `/'  is  generally  safer if you use wildcards in the list of start points).
-----------

Afaict this is not mentioned in the info manual. The whole paragraph is unclear, does "--" apply to "real options" or "positional options"?

Imho the functionality does not make a lot of sense for find, since find is rarely used without a find expression just with paths.

Also I cannot get this to work:
ametzler@argenau:/tmp/findtest$ LANG=C ls -l
total 4
drwxrwxr-x 2 ametzler ametzler 4096 Apr 19 07:06 -L
-rw-rw-r-- 1 ametzler ametzler    0 Apr 19 13:40 -regextype
-rw-rw-r-- 1 ametzler ametzler    0 Apr 19 07:06 file
ametzler@argenau:/tmp/findtest$ find -L
.
./-regextype
./file
./-L
./-L/below
ametzler@argenau:/tmp/findtest$ find ./-L/
./-L/
./-L/below
ametzler@argenau:/tmp/findtest$ LANG=C find -- -L
find: unknown predicate `-L'
ametzler@argenau:/tmp/findtest$ LANG=C find ./ -- -regextype grep
find: unknown predicate `--'
ametzler@argenau:/tmp/findtest$ LANG=C find -- *
find: unknown predicate `-L'

Andreas Metzler <ametzler>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49666:  0001-find.1-clarify-double-dash-option.patch added by berny (2KiB - text/x-patch - [PATCH] find.1: clarify double dash '--' option)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by berny (Posted a comment)
  • -email is unavailable- added by ametzler (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-01-09 berny Open/ClosedOpen Closed
        Fixed ReleaseNone 4.8.0
    2020-08-17 berny StatusCode Review Fixed
    2020-08-13 berny Attached File- Added 0001-find.1-clarify-double-dash-option.patch, #49666
        StatusIn Progress Code Review
    2020-06-21 berny StatusNone In Progress
        Assigned toNone berny

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code