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

Re: Proposed new POSIX sh policy

On Thu, 16 Nov 2006 17:40:20 -0700, Bruce Sass <bmsass@shaw.ca> said: 

> On Thu November 16 2006 11:06, Thomas Bushnell BSG wrote:
>> On Thu, 2006-11-16 at 04:14 -0700, Bruce Sass wro
>> > AFAICT, "/bin/sh can be a symbolic link to any POSIX compatible
>> > shell" does not really convey what Debian wants, it would be
>> > better to state that, `only POSIX features should be used in
>> > Debian "sh" scripts', followed by a list of exceptions (which
>> > would presumably be a subset of those features in common use
>> > which exist in all shells allowed to be "sh".)
>> The problem is that "POSIX feature" is a meaningless term in this
>> context.

> I see your point.

        I don't, but really, I am not sure I ought tobe spending much
 more time on an arcane reading of this corner case.

        The  issue, apparently, is that under policy, some shell can
 come up with all kinds of shadowing of things like debconf.  I
 suggest that if brought before the TC, the TC shall decide that is a
 bug in the shell.  Policy is not supposed to be written to specify
 all kinds of silly and deliberate malice  on the part of shell

>> If "test -a" is not a POSIX feature (or any other random test
>> arguments bandied about here), then so calling "debconf" is also
>> not a POSIX feature, and for exactly the same reason: either might
>> be overridden by a builtin.

> "test" is included in the spec, so a script's use of "test" should
> be restricted to features included in the spec of "test" for the
> script to be compliant with the spec. "debconf" is not included in
> the spec, so use of it can not be non-compliant because it is
> impossible to not comply with something which doesn't exist.

> So, maybe something alone the lines of:

> The use of commands included in the spec must comply with the spec
> of those commands.

        O, good grief.  This is not Law 101.  This is the technical
 policy all kinds of non native developers must read, understand, and
 follow; arcane corner cases and increasingly complex language to
 resolve corner cases just makes policy asinine, turgid, obfuscated,
 and abstruse.

"I've seen the forgeries I've sent out." John F. Haugh II
(jfh@rpp386.Dallas.TX.US), about forging net news articles
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: