Follow-up Comment #2, bug #58205 (project findutils): Bernhard Voelker <invalid.nore...@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/