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

[Andreas Metzler]

Follow-up Comment #2, bug #58205 (project findutils):

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

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58205>

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