On 2024-04-15, Helmut Waitzmann <nn.throttle@xoxy.net> wrote:
> Compare (using GNU ls) with Christians well‐behaving "ls":
>
>
> touch -- foo -l
>
> $ ls foo -l
> -rw------- 1 helmut helmut 0 Apr 15 15:28 foo

touch deviates in the first place; omit the -- and you get

$ touch foo -l
touch: invalid option -- 'l'

That's crazy. foo is a non-option argument, so the options
have ended at that point.

I see where it is documented in "2 Common options" (Coreutils manual):

Normally options and operands can appear in any order, and programs act
as if all the options appear before any operands. For example, ‘sort -r
passwd -t :’ acts like ‘sort -r -t : passwd’, since ‘:’ is an
option-argument of -t. However, if the POSIXLY_CORRECT environment
variable is set, options must appear before operands, unless otherwise
specified for a particular command.

It is disingenous to call it "POSIXly correct", because in fact the
POSIX rules are how everyone understands it and how other implementors
of utilities implement it. (Does anyone else do this crazy thing?)

If all the vendors feature a given extension, so that it is portable,
but POSIX refuses to adopt it, then, sure: the mode which takes the
extension away can be flippantly called "POSIXly correct".

Also the claim "options must appear before operands [in POSIX]" is
misleading, because "must" is usually interpreted as an imposed
requirement, which can be violated and diagnosed. But in fact it is
*logically* impossible for options to appear elsewhere because arguments
that look like options placed in the non-option part of the command line
are operands. It's the logical "must", not the reuqirements "must".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <643-408-1753@kylheku.com>:
> On 2024-04-15, Helmut Waitzmann <nn.throttle@xoxy.net> wrote:
>> Compare (using GNU ls) with Christians well‐behaving "ls":
>>
>>
>> touch -- foo -l
>>
>> $ ls foo -l
>> -rw------- 1 helmut helmut 0 Apr 15 15:28 foo
>
> touch deviates in the first place; omit the -- and you get
>
>
> $ touch foo -l
> touch: invalid option -- 'l'
>
> That's crazy. foo is a non-option argument, so the options
> have ended at that point.
>

Yes, that's the same problem like with GNU "ls".  (I decided to
silently avoid it by making use of the end‐of‐option marker
without commenting it.)

> I see where it is documented in "2 Common options" (Coreutils
> manual):
>
>
> Normally options and operands can appear in any order, and
> programs act as if all the options appear before any operands.
> For example, ‘sort -r passwd -t :’ acts like ‘sort -r -t :
> passwd’, since ‘:’ is an option-argument of -t. However, if
> the POSIXLY_CORRECT environment variable is set, options must
> appear before operands, unless otherwise specified for a
> particular command.
>

If I understand the last sentence correctly, setting the
POSIXLY_CORRECT environment variable forces the GNU utilities to
stop option processing before the first non‐option argument
(i. e. an argument beginning not with a "-") as if that argument
had been preceded by the end‐of‐option argument "--".

> It is disingenous to call it "POSIXly correct", because in fact
> the POSIX rules are how everyone understands it and how other
> implementors of utilities implement it. (Does anyone else do
> this crazy thing?)
>
>
> If all the vendors feature a given extension, so that it is
> portable, but POSIX refuses to adopt it, then, sure: the mode
> which takes the extension away can be flippantly called "POSIXly
> correct".
>

Maybe my knowledge of the English language is not good enough to
understand you correctly.  Under the premise, that the
POSIXLY_CORRECT environment variable has been set, do you see the
GNU utilities behaving in any different way from what is the
behavior specified by POSIX?

> Also the claim "options must appear before operands [in POSIX]"
> is misleading, because "must" is usually interpreted as an
> imposed requirement, which can be violated and diagnosed. But in
> fact it is *logically* impossible for options to appear
> elsewhere because arguments that look like options placed in the
> non-option part of the command line are operands. It's the
> logical "must", not the reuqirements "must".
>

The GNU manual does not say "in POSIX" but says "if the
POSIXLY_CORRECT environment variable is set", but otherwise I
agree with you.  This is, why I recommend to not make use of the
GNU behavior of looking for options right of the first non‐option
operand when neither the end‐of‐option marker is used nor the
POSIXLY_CORRECT environment variable has been set, but rather
always put any options (if present) first, then – regardless of
whether any options are actually present – in any case supply the
end‐of‐option marker ("--") and finally any non‐option operands. 
This way both, POSIX utilities and GNU utilities, will behave the
same, even, if the POSIXLY_CORRECT environment variable happens
not to be set.