On Fri, 28 Jun 2019 00:52:33 -0700
Michael Forney <mforney_AT_mforney.org> wrote:
Dear Michael,
> I'm really sorry for ignoring this for so long. Someone asked me about
> the `argv0 = *argv, argv0 ? (argc--, argv++) : (void *)0;` one-liner,
> and I remembered this patch. I finally took the time to investigate
> this issue in more detail.
>
> I was confused by this for a bit, but I think you are referring to
> http://austingroupbugs.net/view.php?id=192, which was not present in
> the 2008 edition[0], but did make it into the 2013 edition[1].
>
> As far as I know, unless the documentation states that a utility shall
> conform to the Utility Syntax Guidelines, it is not required to
> support `--`. However, it does use the language "should" which
> means[2]:
>
> For an implementation that conforms to POSIX.1-2017,
> describes a feature or behavior that is recommended but not mandatory.
>
> It looks like these tools formerly supported `--`, but this was
> removed in 9016d288[3], with the justification that echo(1) is
> mandated to *not* support `--` and that there is no reason why other
> tools with no options should handle it. I would argue that there *is*
> a reason to support `--`, and that is the Utility Syntax Guidelines.
> echo(1) is an exception that is explicitly called out, but a single
> exception shouldn't set a precedent for other tools. In fact, tty(1)
> is actually required to support the Utility Syntax Guidelines[4], so
> 9016d288 actually breaks POSIX conformance. The examples you mentioned
> in basename(1) and dirname(1), and also a note about `--` I found in
> expr(1) seem to support this view.
>
> Rather than add a special ENOFLAGS macro, I am tempted to revert
> 9016d288 instead. The question that remains is how to handle arguments
> that look like options (start with `-`) for tools that don't have any
> specified options. It seems for some tools it is important to treat
> them as operands (e.g. printf, expr), but for others that are commonly
> extended with additional options, it might make sense to fail with
> usage() to catch unsupported uses (e.g. hostname, tsort, chroot).
thanks for elaborating about it more! This topic was a big point of
debate back then. In this matter Posix should have the final word. So
in this sense, if Posix mandates for e.g. dirname(1) to support -- then
we should not ignore -- and the user will have to write
$ dirname -- --
I think though that we all agree that an ENOFLAGS-macro would be
insanity.
With best regards
Laslo
--
Laslo Hunhold <dev_AT_frign.de>
- application/pgp-signature attachment: stored
Received on Fri Jun 28 2019 - 10:36:18 CEST