Re: Official position on POSIX compliance?
> No.
> 1) policy says nothing about e.g. chmod, as it is no shell builtin.
Policy does not guarantee that chmod will not be a shell builtin.
sash implements chmod as a builtin, for example. Furthermore, since
maintainer scripts typically do not specify an exact path for the
command in order to allow the system administrator to place an
alternate chmod somewhere in the PATH, someone may put a
strictly-POSIX-conformant chmod in /usr/local/bin.
If one does so, is a script using
"chmod -cfR --reference=/etc/passwd /var/tmp/blah"
buggy, or is the sysadmin buggy for not using coreutils?
> 2) We have yet not even decided which superset of POSIX-sh we will
> require (probably just UP and echo -n)
It would be silly to require all those interactive features for
#!/bin/sh maintainer scripts, especially since the people interested in
embedded systems want to cut bloat.
> 3) "echo -n" is definitely not POSIX (even forbidden for XSI) but we
> encourage it in policy anyway.
Attitudes on this seem to have changed since that was declared, both
within Debian and within POSIX; note that POSIX no longer conflicts with
Debian policy in this regard.
> 4) There is usually[1] no point submitting bugs about usage of non-POSIX
> options for our userland. In the first place our userland is not POSIX
> compatible (check e.g findutils) and in the second place we call it
> Debian/GNU Linux *because* our userland offers more than barebone
> posix.
If you're going to mandate use of findutils, then I think it's
reasonable to use all the fun featurees of GNU find. However, if you're
going to allow the user to manage via alternatives GNU find and FreeBSD
find, you need to stick to the lowest common denominator or be able to
explicitly specify the one that you want.
Reply to: