Re: Removal of upstart integration

[Christian Seiler <christian@iwakd.de>]

On 09/24/2017 01:32 AM, Thomas Goirand wrote:
> On 09/13/2017 02:56 PM, Ian Jackson wrote:
>> Alexandre Detiste writes ("Re: Removal of upstart integration"):
>>> Please also sprinkle these maintainers scripts with some
>>>
>>>   rmdir /etc/init  --ignore-fail-on-non-empty
>>
>> That should be
>>
>>   rmdir --ignore-fail-on-non-empty /etc/init
>>
>> in case an environment variable is set requesting traditional
>> (non-GNU) positional option parsing.
>>
>> Ian.
> 
> I didn't know such an env var even existed. Would you mind expliciting
> what this env var is exactly?

POSIXLY_CORRECT. Try it yourself:

ls / -l
POSIXLY_CORRECT= ls / -l

See also:
https://manpages.debian.org/stretch/manpages-dev/getopt.3.en.html

Since not every program does option parsing via getopt(3) the
situation is actually a bit more involved in general. There are
the following three possible things that can happen:

 - Programs that either use getopt(3) or manually implement
   POSIXLY_CORRECT will show the same behavior as ls or rmdir:
   use pure POSIX semantics if the option is set and use the
   GNU extension (which mainly boils down to allowing options
   after parameters) if it's not set.

 - Other programs that implement option parsing manually or use
   another library than getopt(3) will only follow pure POSIX
   semantics.

 - Yet other programs that implement option parsing manually or
   use another library than getopt(3) will only follow the GNU
   extension (or at least a variant thereof).

In the case of most programs such as cp, ls, rmdir etc.
getopt(3) is used and the environment variable does have an
effect.

Regards,
Christian