[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Public service announcement about Policy 10.4



I wrote:
>> I don't know what kind of importance a policy clause can have if it
>> has "nil" practical impact.

Steve Langasek wrote:
> I mean that the practical *benefit* of such strict enforcement is nil.
> The *impact* is that it would be a royal waste of developer time to
> make all scripts compatible with a strict POSIX shell that isn't even
> optimal from a size POV.
>
> It's still useful to have a package which lets one practically test
> one's scripts for POSIX compatibility, but it just doesn't make any
> sense to enforce this level of strictness archive-wide.


OK, so this policy won't be strictly enforced archive-wide.

Given that fact, the existing posh is less useful as a debugging tool
than it would otherwise be.  If almost all packages worked with posh
then some people could run with /bin/sh -> posh and report script
failures.  As things are, too many scripts break to make it reasonable
for anyone to run with /bin/sh -> posh.

People actually use dash, rather than posh, for portability testing.
That is fine.  But successful testing with dash does not guarantee that
policy 10.4 is being followed.  Dash, like bash, implements many non-
POSIX features.  So should we replace 10.4 with something that
describes actual practice?  (E.g., "/bin/sh scripts must run on dash
and bash.")  That would resolve the "legal" situation, but some people
oppose writing the names of particular shells into 10.4.  Doint that
makes policy a target that moves whenever there is a new dash release.
Also, that change would significantly enlarge the feature set that
would have to be implemented by new shells designed to be /bin/sh
candidates.

I would appreciate it if someone would create the "potash" shell,
consisting of posh modified to implement "test -a", "test -o" and
"local".  Debian would probably run on that well enough for it to
be used as /bin/sh, and it could become the de facto testbed for
10.4 compliance.

(An alternative for potash would be to de-implement the "test"
builtin and rely on the program of the same name.  However,
because the test program is in /usr/bin, potash could then not
be used by early /etc/rcS.d/ scripts if /usr/ is mounted later
in the boot process.)

Later there was a complaint that eliminating bashisms causes
inconvenient divergence from upstream.  But that divergence can be
limited to this short patch per offending script:

    1c1
    < #!/bin/sh
    ---
    > #!/bin/bash

If "test -a", "test -o" and "local" are no longer considered
illegal bashisms then there won't be much need for this.
-- 
Thomas Hood



Reply to: