Debian Bug report logs - #267142
Specify allowable behavior for /bin/sh shell builtins

version graph

Package: debian-policy; Maintainer for debian-policy is Debian Policy List <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy.

Reported by: Thomas Bushnell BSG <tb@becket.net>

Date: Fri, 20 Aug 2004 21:03:05 UTC

Severity: wishlist

Found in version 3.6.1.1

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
New Bug report received and forwarded. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 20 Aug 2004 13:28:00 -0700
Package: debian-policy
Version: 3.6.1.1
Severity: normal

This arose out of David Weinehall's search for the use of non-Posix
features in package scripts.  See bug #260092 for an example, and
#264176 for some of his discussion with me.


Policy 10.4 reminds that "The standard shell interpreter /bin/sh can
be a symbolic link to any POSIX compatible shell....Thus, shell
scripts specifying /bin/sh as interpreter should only use POSIX
features."

And we will note section 6.1, which says: "Programs called from
maintainer scripts should not normally have a path prepended to them."

If you look at bugs #260092 and #264176, you'll see that the complaint
is that the script is using -o and -a as arguments to "test".  It is
true that -o and -a are not specified by Posix "test".  But--and this
is absolutely crucial--Posix "test" is not part of the Posix shell
specification.  As far as Posix is concerned, "test" is simply one
more program.

Because of policy 6.1, we are not supposed to write /usr/bin/test.  

What is going on here is that Posix allows a conformant shell to
implement programs as builtins.  ANY program.  ANY program WHATSOEVER!
Ain't that a kicker?  The assumption of Posix is that the shell and
the utilities are being written and distributed by the same people,
and that the shell, when it builds something in, will build it in in a
way which matches the behavior of the utility.  But this assumption is
(oddly!) nowhere specified by Posix.

If you install "dash" as /bin/sh on a Debian system, then you break
this assumption.

From the Posix perspective, there are two kinds of utilities: those
specified to exist by Posix, and those which are extra.  A
Posix-conformant shell is allowed to buildin *either* of those.  (And
shells liberally take advantage of this, of course.)  Posix assumes,
but does not require, that you won't make a buildin which is
inconsistent with a regular program.

For a Posix-specified utility, it is obvious that a Posix-conformant
shell (if it builds it in) must build in a Posix-conformant
implementation of the utility.  And dash does do this.  But it also
builds in one which is inconsistent with /usr/bin/test on Debian, and
that's a problem.

But I hasten to note that a Posix-conformant shell is allowed to build
in *anything*, and if it's not a Posix-specified utility that's being
built in, then it can have *any behavior whatsoever*.  For example, a
Posix-compatible shell may build in a shell command named "debconf",
such that when you run it, it tries deletes everything in /etc.  Since
my maintainer scripts are require to work with any Posix-compatible
shell whatsoever, I cannot call debconf from the PATH.

Given Policy as it currently exists, the only way to reliably conform
to section 10.4 is either:
  * Never use /bin/sh, ever, as a shell interpereter; or
  * Call all programs with fully specified paths to avoid unexpected
    builtins.

The second of those solutions conflicts with section 6.1's requirement
not to normally prepend a path.  The former seems suboptimal, but does
work.  However, Policy as currently worded makes it sound like it is
ever safe to use /bin/sh, and it is not, ever.

David Weinehall proposed one possible fix, to extend 10.4 to restrict
the use not only of non-Posix shell features, but also non-Posix
features in other commands, if those commands are "historically built
in".  This is unworkably vague, but can be toned up to something that
does work; see the third option below.

I believe there are four reasonable sorts of policy amendment that
would solve this problem:

  OPTION 1: Change 10.4 to require that scripts never use /bin/sh.

  OPTION 2: Restrict /bin/sh to a specified list of shells, rather
  than "any POSIX compatible shell", and require that shell scripts
  run correctly on that list.

  OPTION 3: Extend 10.4 to require the use only of Posix features not
  only for the shell, but for a specified list of other commands; that
  list would be based upon which commands are in fact being built-in
  by shells like dash in ways which are inconsistent with the binaries
  in /usr/bin.

  OPTION 4: Change section 10.4 to require the use of full pathnames
  for everything which is not ordered by Posix to be builtin to the
  shell; remove the "no pathnames on commands" direction in section
  6.1.  


I strongly prefer option 2.  Options 1 and 3 seem ok to me, with a
slight preference for option 1 because it is more maintainable.
Option 4 is horrible, and you don't need me to say why.


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Kernel: Linux 2.4.20-ben10
Locale: LANG=en_US, LC_CTYPE=en_US

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@grep.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 267142@bugs.debian.org (full text, mbox):

From: Wouter Verhelst <wouter@grep.be>
To: Thomas Bushnell BSG <tb@becket.net>, 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 21 Aug 2004 01:33:30 +0200
On Fri, Aug 20, 2004 at 01:28:00PM -0700, Thomas Bushnell BSG wrote:
> I believe there are four reasonable sorts of policy amendment that
> would solve this problem:
> 
>   OPTION 1: Change 10.4 to require that scripts never use /bin/sh.
> 
>   OPTION 2: Restrict /bin/sh to a specified list of shells, rather
>   than "any POSIX compatible shell", and require that shell scripts
>   run correctly on that list.
> 
>   OPTION 3: Extend 10.4 to require the use only of Posix features not
>   only for the shell, but for a specified list of other commands; that
>   list would be based upon which commands are in fact being built-in
>   by shells like dash in ways which are inconsistent with the binaries
>   in /usr/bin.
> 
>   OPTION 4: Change section 10.4 to require the use of full pathnames
>   for everything which is not ordered by Posix to be builtin to the
>   shell; remove the "no pathnames on commands" direction in section
>   6.1.  

There's also,

OPTION 5: Change section 10.4 to require the use of full pathnames when
non-Posix extensions are being used in commands; remove the "no
pathnames on commands" direction in section 6.1, but do discourage its
use whenever possible.

> I strongly prefer option 2.  Options 1 and 3 seem ok to me, with a
> slight preference for option 1 because it is more maintainable.
> Option 4 is horrible, and you don't need me to say why.

Indeed. However, I think option 5 is, at least, worth considering, even
if it's hard to implement. Your thought?

-- 
         EARTH
     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
         WATER
 -- with thanks to fortune



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #15 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Wouter Verhelst <wouter@grep.be>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 20 Aug 2004 16:41:18 -0700
Wouter Verhelst <wouter@grep.be> writes:

> There's also,
> 
> OPTION 5: Change section 10.4 to require the use of full pathnames when
> non-Posix extensions are being used in commands; remove the "no
> pathnames on commands" direction in section 6.1, but do discourage its
> use whenever possible.

Under one interpretation, this option doesn't work; under the other,
it is as bad as option 4.

First, if you mean "when non-Posix extensions are being used in
Posix-specified commands" (like "test"), then it doesn't work, because
a shell might well override "debconf" with a builtin, as I described.

But if you mean "when non-Posix extension are being used, or non-Posix
commands" then (because almost everything is non-Posix) we end up with
all the brittleness that section 6.1 is trying to avoid, and we lose
all the performance benefits of shell builtins (when those builtins
are well-behaved).

Perhaps I have not really understood how this option works, however.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@grep.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #20 received at 267142@bugs.debian.org (full text, mbox):

From: Wouter Verhelst <wouter@grep.be>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 21 Aug 2004 02:05:49 +0200
On Fri, Aug 20, 2004 at 04:41:18PM -0700, Thomas Bushnell BSG wrote:
> Wouter Verhelst <wouter@grep.be> writes:
> 
> > There's also,
> > 
> > OPTION 5: Change section 10.4 to require the use of full pathnames when
> > non-Posix extensions are being used in commands; remove the "no
> > pathnames on commands" direction in section 6.1, but do discourage its
> > use whenever possible.
> 
> Under one interpretation, this option doesn't work; under the other,
> it is as bad as option 4.
> 
> First, if you mean "when non-Posix extensions are being used in
> Posix-specified commands" (like "test"), then it doesn't work, because
> a shell might well override "debconf" with a builtin, as I described.

Well, yeah, theoretically a shell could do that. However, in this
specific example, I would consider such a shell to be horribly broken.
'debconf' is a name which is clearly chosen to avoid namespace conflicts
such as the ones you're suggesting; and seen the fact that debconf is
quite well known right now, I consider it extremely unlikely for that to
be implemented in such a way.

Of course, that's not what you meant; but I'd think that other examples
would need to be examined on a case-by-case basis, and dealt with as
they occur, using a fair dosis of common sense.

The point being that, yeah, this is a possibility, but one that isn't
too likely. Given a) that Policy is just a guideline on how to perform
computer implementations, not one of those implementations itself; and
b) the absence of any proof to the contrary, I don't think these
problems are so likely that we need to worry about them right now. Also,
even if it's allowed, I don't think it's likely for a shell to implement
a builtin which is not specified by Posix (but I don't know all shells
out there and haven't read a Posix standard, ever, so I could be wrong)

Worst case, we could use wording which would make it clear that in the
case such a conflict ever appears, scripts breaking because of that
conflict should prepend a fixed path to the problematic command (or stop
using /bin/sh).

In other words, I suggest to deal with the things that are more likely
to happen, and to just ignore (but of course not dismiss) the less
likely problems.

> But if you mean "when non-Posix extension are being used, or non-Posix
> commands" then (because almost everything is non-Posix) we end up with
> all the brittleness that section 6.1 is trying to avoid,

No, that's the wrong interpretation ;-)

> and we lose all the performance benefits of shell builtins (when those
> builtins are well-behaved).

Indeed; however, if performance is an issue, then using /bin/sh is not
a real option anyway.

-- 
         EARTH
     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
         WATER
 -- with thanks to fortune



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #25 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Wouter Verhelst <wouter@grep.be>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 20 Aug 2004 17:16:35 -0700
Wouter Verhelst <wouter@grep.be> writes:

> Well, yeah, theoretically a shell could do that. However, in this
> specific example, I would consider such a shell to be horribly broken.
> 'debconf' is a name which is clearly chosen to avoid namespace conflicts
> such as the ones you're suggesting; and seen the fact that debconf is
> quite well known right now, I consider it extremely unlikely for that to
> be implemented in such a way.

But this is exactly the problem.  A shell might well do what dash
does, and override a non-Posix program, but in a minimalizing way
(perhaps, in the assumption that people only need the minimum thing).

> Of course, that's not what you meant; but I'd think that other examples
> would need to be examined on a case-by-case basis, and dealt with as
> they occur, using a fair dosis of common sense.

Why not just fix the problem entirely?  That's what I meant by saying
that this option 5 doesn't work: it doesn't actually fix the problem.

We could always add a new thing that said "stick to Posix test, too",
and that would solve *this* case, but do we really want to have to do
this piecemeal?

By contrast, listing a bunch of shells directly means that policy
doesn't have to get into the nitty gritty--which can only be a good
thing! 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@grep.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #30 received at 267142@bugs.debian.org (full text, mbox):

From: Wouter Verhelst <wouter@grep.be>
To: Thomas Bushnell BSG <tb@becket.net>, 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 21 Aug 2004 04:00:42 +0200
On Fri, Aug 20, 2004 at 05:16:35PM -0700, Thomas Bushnell BSG wrote:
> By contrast, listing a bunch of shells directly means that policy
> doesn't have to get into the nitty gritty--which can only be a good
> thing! 

Sorry; but I find a list of shells far more ugly than using hard-coded
paths.

-- 
         EARTH
     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
         WATER
 -- with thanks to fortune



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #35 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Wouter Verhelst <wouter@grep.be>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 21 Aug 2004 01:02:18 -0700
Wouter Verhelst <wouter@grep.be> writes:

> On Fri, Aug 20, 2004 at 05:16:35PM -0700, Thomas Bushnell BSG wrote:
> > By contrast, listing a bunch of shells directly means that policy
> > doesn't have to get into the nitty gritty--which can only be a good
> > thing! 
> 
> Sorry; but I find a list of shells far more ugly than using hard-coded
> paths.

That's ok; I think we've done a decent job of narrowing the
possibilities down, and I did miss that fifth possible resolution, so
thanks.  

If you don't mind, I'll write up a description of both of our
favorites, giving the pros and cons as I understand them, hopefully
which we would both agree to, and then post it for the comments of
others?




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@grep.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #40 received at 267142@bugs.debian.org (full text, mbox):

From: Wouter Verhelst <wouter@grep.be>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 21 Aug 2004 13:43:03 +0200
On Sat, Aug 21, 2004 at 01:02:18AM -0700, Thomas Bushnell BSG wrote:
> Wouter Verhelst <wouter@grep.be> writes:
> 
> > On Fri, Aug 20, 2004 at 05:16:35PM -0700, Thomas Bushnell BSG wrote:
> > > By contrast, listing a bunch of shells directly means that policy
> > > doesn't have to get into the nitty gritty--which can only be a good
> > > thing! 
> > 
> > Sorry; but I find a list of shells far more ugly than using hard-coded
> > paths.
> 
> That's ok; I think we've done a decent job of narrowing the
> possibilities down, and I did miss that fifth possible resolution, so
> thanks.  
> 
> If you don't mind, I'll write up a description of both of our
> favorites, giving the pros and cons as I understand them, hopefully
> which we would both agree to, and then post it for the comments of
> others?

Good plan.

-- 
         EARTH
     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
         WATER
 -- with thanks to fortune



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #45 received at 267142@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Thomas Bushnell BSG <tb@becket.net>, 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Wed, 25 Aug 2004 22:32:09 +0200
Hello Debian policy,

For the record, I am in favor of mandating that /bin/sh is required
to not have a test built-in or at least provide a test built-in that
understand -a and -o.

More generally shells that provide built-in with name conflicting 
with others basic programms in Debian should not be allowed for /bin/sh.
For example a shell with a 'ls' built-in.

I must say I am not a big fan of the /bin/sh policy: shell scripts are
very often used in critical part of the system and only a very small
number of /bin/sh implementation are tested with them, so the bottom
line is a large number of policy-supported but untested configurations.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #50 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Bill Allombert <allomber@math.u-bordeaux.fr>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 25 Aug 2004 13:47:05 -0700
Bill Allombert <allomber@math.u-bordeaux.fr> writes:

> For the record, I am in favor of mandating that /bin/sh is required
> to not have a test built-in or at least provide a test built-in that
> understand -a and -o.

This might settle just that one case, but the problem is more
general. 

> More generally shells that provide built-in with name conflicting 
> with others basic programms in Debian should not be allowed for /bin/sh.
> For example a shell with a 'ls' built-in.

This is one of my existing options. :)

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marco d'Itri <md@Linux.IT>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #55 received at 267142@bugs.debian.org (full text, mbox):

From: Marco d'Itri <md@Linux.IT>
To: debian-policy@lists.debian.org, 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Thu, 9 Sep 2004 03:57:40 +0200
[Message part 1 (text/plain, inline)]
On Sep 08, Thomas Hood <jdthood@yahoo.co.uk> wrote:

> Current practice is to support bash and dash.  Efforts are made to
> support posh too because this seems like the easiest way to ensure
> that a script satisfies 10.4 as it is currently written.
I do not think that this correctly describes reality, as there are many
people who are not willing to support posh in their packages, on the
ground of it being an useless exercise in blind adherence to a
standard and not representative of real world shells.
Writing portable shell scripts is useful, and writing scripts which can
be run by a shell faster than bash is useful too. There is no use in
writing POSIX-compatible scripts just because you feel like doing it.

-- 
ciao, |
Marco | [7874 deoFGcZ2L2f1Y]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Chris Waters <xtifr@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #60 received at 267142@bugs.debian.org (full text, mbox):

From: Chris Waters <xtifr@debian.org>
To: Thomas Hood <jdthood@yahoo.co.uk>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Thu, 9 Sep 2004 01:59:04 -0700
On Thu, Sep 09, 2004 at 09:44:16AM +0200, Thomas Hood wrote:

> One reason to require posh compatibility is that this increases the
> chances that other shells can be added to the list in the future.

I'm not sure that's true (although I'm not sure it's not).  But the
immediate problem (the one we're trying to solve right now) has to do
with shell builtins that override our more featureful non-builtin
utilities.  I don't think posh has any issues in this area, so adding
posh to the required list is not necessary to fix the current bug.
So, the question is, do we want to add it anyway?

I'm very reluctant.  Posh is new, and not very extensively tested.  If
we're going to require compatibility, I want it to be compatibility
with known, widely used, field-tested shells.

Furthermore, posh is supposed to exist as a test of policy.  If it
becomes part of policy, then we have a sort of chicken-and-egg
problem.  The notion makes my head hurt slightly.

As a compromise, I suggest that we say that scripts *must* be
compatible with our real, working shells, bash and dash, and that
further, they *should* be compatible with any reasonable
POSIX-compliant shell.  Then, if something breaks under posh, it'll
still be a bug.  But it won't be release-critical unless it breaks
under a shell that people actually use.

And later, if posh catches on, then we can add it.  But for now, I'd
rather stick with the practical and trustworthy - the software our
users actually use.

-- 
Chris Waters           |  Pneumonoultra-        osis is too long
xtifr@debian.org       |  microscopicsilico-    to fit into a single
or xtifr@speakeasy.net |  volcaniconi-          standalone haiku



Information stored:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Hood <jdthood@yahoo.co.uk>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #65 received at 267142-quiet@bugs.debian.org (full text, mbox):

From: Thomas Hood <jdthood@yahoo.co.uk>
To: debian-policy@lists.debian.org
Cc: 267142-quiet@bugs.debian.org, Chris Waters <xtifr@debian.org>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Thu, 09 Sep 2004 14:31:05 +0200
On Thu, 2004-09-09 at 10:59, Chris Waters wrote:
> I'm not sure that's true (although I'm not sure it's not).  But the
> immediate problem (the one we're trying to solve right now) has to do
> with shell builtins that override our more featureful non-builtin
> utilities. I don't think posh has any issues in this area, so adding
> posh to the required list is not necessary to fix the current bug.
> So, the question is, do we want to add it anyway?


The current policy is roughly equivalent to: "Make scripts work with
posh because this will guarantee that they work with all shells that
implement POSIX features + echo -n".

The problem is that the rationale is incorrect.  A script can work with
posh and still not work with all shells that implement POSIX features
+ echo -n.  (Again: because the script may run programs that some shells
implements differently as builtins.)

Assuming that the goal of 10.4 is portability of scripts across shells
(and thus, freedom for the administrator to point /bin/sh at targets
other than bash) and that we want to retain this goal, we need to
tighten up the language.  The most expedient way to do that, in my
opinion, is to say that the script must work not only on posh but also
on bash and dash.  Posh is effectively already on the list so there is
no question here of "adding" it.  The question that arises from your
comment is whether or not we should remove it.


> Posh is new, and not very extensively tested.  If
> we're going to require compatibility, I want it to be compatibility
> with known, widely used, field-tested shells.
>
> Furthermore, posh is supposed to exist as a test of policy.  If it
> becomes part of policy, then we have a sort of chicken-and-egg
> problem.  The notion makes my head hurt slightly.


If you like we can also say that posh should support all and only
POSIX specified features plus "echo -n".  However, that is already
the idea behind posh.


> As a compromise, I suggest that we say that scripts *must* be
> compatible with our real, working shells, bash and dash, and that
> further, they *should* be compatible with any reasonable
> POSIX-compliant shell.


The problem is that the "should" part is ill-defined.  What is a
"reasonable" POSIX-compliant shell?  That is exactly the question
that needs to be answered by giving an explicit list.

I think it would be simplest to require compatibility with bash,
dash and posh but for the RMs to ignore posh-compatibility bugs until
the next release.

--
Thomas Hood






Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #70 received at 267142@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Chris Waters <xtifr@debian.org>, 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Thu, 9 Sep 2004 13:36:42 +0200
On Thu, Sep 09, 2004 at 01:59:04AM -0700, Chris Waters wrote:
> On Thu, Sep 09, 2004 at 09:44:16AM +0200, Thomas Hood wrote:
> 
> > One reason to require posh compatibility is that this increases the
> > chances that other shells can be added to the list in the future.
> 
> I'm not sure that's true (although I'm not sure it's not).  But the
> immediate problem (the one we're trying to solve right now) has to do
> with shell builtins that override our more featureful non-builtin
> utilities.  I don't think posh has any issues in this area, so adding
> posh to the required list is not necessary to fix the current bug.

Wrong, posh has a built-in 'test' command which is crippled. That is what
this whole thread is about. This 'test' built-in override /usr/bin/test
which support more options such as -a and -o that are commonly used.

(sorry for snipping I just wanted to make the above clear).

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #75 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>, 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Thu, 9 Sep 2004 14:55:44 -0400
> If you look at bugs #260092 and #264176, you'll see that the complaint
> is that the script is using -o and -a as arguments to "test".  It is
> true that -o and -a are not specified by Posix "test".  But--and this
> is absolutely crucial--Posix "test" is not part of the Posix shell
> specification.  As far as Posix is concerned, "test" is simply one
> more program.

What are you talking about?  What do you mean by "Posix shell
specification" if not the XCU volume of IEEE 1003.1?



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #80 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, 267142@bugs.debian.org
Cc: Thomas Bushnell BSG <tb@becket.net>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Thu, 9 Sep 2004 15:01:28 -0400
> More generally shells that provide built-in with name conflicting 
> with others basic programms in Debian should not be allowed for /bin/sh.
> For example a shell with a 'ls' built-in.

Are you opposed to all shell builtins?



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #85 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, 267142@bugs.debian.org
Cc: Chris Waters <xtifr@debian.org>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Thu, 9 Sep 2004 15:05:52 -0400
> Wrong, posh has a built-in 'test' command which is crippled. That is what
> this whole thread is about. This 'test' built-in override /usr/bin/test
> which support more options such as -a and -o that are commonly used.

And #!/bin/sh scripts using "-a" and "-o" as binary operators to test
are violating policy whether or not posh would tolerate it.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Chris Waters <xtifr@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #90 received at 267142@bugs.debian.org (full text, mbox):

From: Chris Waters <xtifr@debian.org>
To: Bill Allombert <allomber@math.u-bordeaux.fr>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Thu, 9 Sep 2004 12:16:49 -0700
On Thu, Sep 09, 2004 at 01:36:42PM +0200, Bill Allombert wrote:
> On Thu, Sep 09, 2004 at 01:59:04AM -0700, Chris Waters wrote:

> > [...] I don't think posh has any issues in this area [...]
> > posh to the required list is not necessary to fix the current bug.

> Wrong, posh has a built-in 'test' command which is crippled.

Ah, you're right.  I was misremembering.  I thought it was dash that
had the built-in test.

Well, that clinches it.  Adding posh-compatibility as a requirement to
policy would make an unknown number of packages suddenly have RC
bugs.  Therefore, I'm strongly opposed to the suggestion.

On the other hand, my suggestion (make bash- and dash-compatibility a
"must" and general POSIX-shell compatibility a "should") would mean an
unknown number of bugs appear, but at least they'd just be normal
bugs, not RC.  Which I think is a reasonable compromise.

-- 
Chris Waters           |  Pneumonoultra-        osis is too long
xtifr@debian.org       |  microscopicsilico-    to fit into a single
or xtifr@speakeasy.net |  volcaniconi-          standalone haiku



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Chris Waters <xtifr@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #95 received at 267142@bugs.debian.org (full text, mbox):

From: Chris Waters <xtifr@debian.org>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Thu, 9 Sep 2004 12:28:14 -0700
On Thu, Sep 09, 2004 at 03:05:52PM -0400, Clint Adams wrote:

> And #!/bin/sh scripts using "-a" and "-o" as binary operators to test
> are violating policy whether or not posh would tolerate it.

Highly debatable.  Policy only mentions POSIX with respect to standard
shell features, and test(1) is not a standard shell feature, it's a
standard utility program.

OTOH, my proposal (bash and dash are "must", works with POSIX-shell is
"should") would make this a normal bug, not a RC bug, which seems
appropriate to me, since it doesn't break anything useful or
important, but it would (I agree) be nice to fix.

-- 
Chris Waters           |  Pneumonoultra-        osis is too long
xtifr@debian.org       |  microscopicsilico-    to fit into a single
or xtifr@speakeasy.net |  volcaniconi-          standalone haiku



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #100 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Chris Waters <xtifr@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Thu, 9 Sep 2004 15:43:11 -0400
> Highly debatable.  Policy only mentions POSIX with respect to standard
> shell features, and test(1) is not a standard shell feature, it's a
> standard utility program.

I'm not sure what you mean by "standard" here; test is more often than
not implemented as a builtin.

Anyone who thinks a crusade against extraneous builtins is a good idea
should take a look at the list of builtins actually required by POSIX.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #105 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Chris Waters <xtifr@debian.org>, 267142@bugs.debian.org
Cc: Bill Allombert <allomber@math.u-bordeaux.fr>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Thu, 9 Sep 2004 15:47:28 -0400
> Well, that clinches it.  Adding posh-compatibility as a requirement to
> policy would make an unknown number of packages suddenly have RC
> bugs.  Therefore, I'm strongly opposed to the suggestion.

An unknown number of packages already have RC bugs, and their release-
criticality has been ignored for the release of sarge.  This includes
test "-a"/"-o" as well as other issues, which some people are happy to
fix.

> On the other hand, my suggestion (make bash- and dash-compatibility a
> "must" and general POSIX-shell compatibility a "should") would mean an
> unknown number of bugs appear, but at least they'd just be normal
> bugs, not RC.  Which I think is a reasonable compromise.

And then it's the responsibility of all maintainer scripts to work
around bugs in both bash and dash.  I'm strongly opposed to the
suggestion of a list of shells in policy rather than a list of rules
that we actually intend to follow.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marco d'Itri <md@Linux.IT>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #110 received at 267142@bugs.debian.org (full text, mbox):

From: Marco d'Itri <md@Linux.IT>
Cc: debian-policy@lists.debian.org, 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 10 Sep 2004 11:36:29 +0200
[Message part 1 (text/plain, inline)]
On Sep 09, Thomas Hood <jdthood@yahoo.co.uk> wrote:

> One reason to require posh compatibility is that this increases the
> chances that other shells can be added to the list in the future.  A shell
> can only be added to the list if it implements all the behaviors that are
> common to all the shells already in the list.  (These are the behaviors
> upon which 10.4-compliant /bin/sh-using scripts are, or may be, relying.)
> Including posh in the list decreases the number of behaviors that are
> common to all shells on the list, thus decreasing the number of behaviors
> that an additional shell has to implement in exactly the same way.
It's not obvious at all that rejecting useful features like test -a is
justified by prospective support for these mythical other shells.

-- 
ciao, |
Marco | [7914 inQdDvmJXj/rw]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marco d'Itri <md@Linux.IT>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #115 received at 267142@bugs.debian.org (full text, mbox):

From: Marco d'Itri <md@Linux.IT>
To: Thomas Hood <jdthood@yahoo.co.uk>
Cc: debian-policy@lists.debian.org, 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 10 Sep 2004 14:10:35 +0200
[Message part 1 (text/plain, inline)]
On Sep 10, Thomas Hood <jdthood@yahoo.co.uk> wrote:

> On Fri, 10 Sep 2004 11:40:24 +0200, Marco d'Itri wrote:
> > It's not obvious at all that rejecting useful features like test -a is
> > justified by prospective support for these mythical other shells.
> Keep in mind that the useful features in question are not rejected
> outright.  They are just prohibited for scripts that use #!/bin/sh.
Same thing. If a script cannot be used with /bin/sh then it could as
well use every bashism available.

-- 
ciao, |
Marco | [7919 tr9wiWTgmKWI2]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #120 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 16:34:05 -0700
Clint Adams <schizo@debian.org> writes:

> > If you look at bugs #260092 and #264176, you'll see that the complaint
> > is that the script is using -o and -a as arguments to "test".  It is
> > true that -o and -a are not specified by Posix "test".  But--and this
> > is absolutely crucial--Posix "test" is not part of the Posix shell
> > specification.  As far as Posix is concerned, "test" is simply one
> > more program.
> 
> What are you talking about?  What do you mean by "Posix shell
> specification" if not the XCU volume of IEEE 1003.1?

The Posix shell specification is the Posix specification of the "sh"
command, not of everything in the XCU spec.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #125 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: Bill Allombert <allomber@math.u-bordeaux.fr>, 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 16:34:35 -0700
Clint Adams <schizo@debian.org> writes:

> > More generally shells that provide built-in with name conflicting 
> > with others basic programms in Debian should not be allowed for /bin/sh.
> > For example a shell with a 'ls' built-in.
> 
> Are you opposed to all shell builtins?

I don't think the question is about being "opposed to" or "in favor
of" builtins.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #130 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 10 Sep 2004 19:43:05 -0400
> The Posix shell specification is the Posix specification of the "sh"
> command, not of everything in the XCU spec.

You mean this, which is a recent addition?
http://www.opengroup.org/onlinepubs/009695399/utilities/sh.html



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #135 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 16:58:49 -0700
Clint Adams <schizo@debian.org> writes:

> > The Posix shell specification is the Posix specification of the "sh"
> > command, not of everything in the XCU spec.
> 
> You mean this, which is a recent addition?
> http://www.opengroup.org/onlinepubs/009695399/utilities/sh.html

That and the referenced Shell Command Language.

This has always been part of Posix.1 IIRC.

Can you please carry on this conversation on the mailing list, rather
than in private?





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #140 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org, Chris Waters <xtifr@debian.org>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 17:04:46 -0700
Clint Adams <schizo@debian.org> writes:

> > Highly debatable.  Policy only mentions POSIX with respect to standard
> > shell features, and test(1) is not a standard shell feature, it's a
> > standard utility program.
> 
> I'm not sure what you mean by "standard" here; test is more often than
> not implemented as a builtin.

We're talking about what the Debian Policy Manual requires.  It says
you must restrict yourself to Posix-specified shell features, but you
do *not* have to restrict yourself in the use of other Debian
programs.

> Anyone who thinks a crusade against extraneous builtins is a good idea
> should take a look at the list of builtins actually required by POSIX.

Nobody is starting a "crusade against extraneous builtins". 





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #145 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 10 Sep 2004 20:05:29 -0400
> That and the referenced Shell Command Language.
> 
> This has always been part of Posix.1 IIRC.

And those parts of the Shell Command Language which reference builtins?

> Can you please carry on this conversation on the mailing list, rather
> than in private?

This is on the mailing list, and not in private.  Or do you not want to
be in the To: field?



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #150 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 17:19:38 -0700
Clint Adams <schizo@debian.org> writes:

> > That and the referenced Shell Command Language.
> > 
> > This has always been part of Posix.1 IIRC.
> 
> And those parts of the Shell Command Language which reference builtins?

Yes.  Have you read my original bug report, which goes into
considerable detail?  I'm not interested in rehearsing the whole thing
in response to one-liner questions.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #155 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org, Chris Waters <xtifr@debian.org>, Bill Allombert <allomber@math.u-bordeaux.fr>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 17:22:15 -0700
Clint Adams <schizo@debian.org> writes:

> > On the other hand, my suggestion (make bash- and dash-compatibility a
> > "must" and general POSIX-shell compatibility a "should") would mean an
> > unknown number of bugs appear, but at least they'd just be normal
> > bugs, not RC.  Which I think is a reasonable compromise.
> 
> And then it's the responsibility of all maintainer scripts to work
> around bugs in both bash and dash.  I'm strongly opposed to the
> suggestion of a list of shells in policy rather than a list of rules
> that we actually intend to follow.

This would require simply changing the exact way that we specify the
requirement.  Right now the requirement is actually incoherent; a
requirement that referred to "only use the features of bash and dash"
seems fine, because the bugs in bash and dash are not features.

If a maintainer finds a big in dash, and it's a pain to work around,
it's a simple matter to just #!/bin/bash and be done with it.

thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #160 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org, Bill Allombert <allomber@math.u-bordeaux.fr>, Chris Waters <xtifr@debian.org>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 17:24:14 -0700
Clint Adams <schizo@debian.org> writes:

> > Wrong, posh has a built-in 'test' command which is crippled. That is what
> > this whole thread is about. This 'test' built-in override /usr/bin/test
> > which support more options such as -a and -o that are commonly used.
> 
> And #!/bin/sh scripts using "-a" and "-o" as binary operators to test
> are violating policy whether or not posh would tolerate it.

This is incorrect.

Policy requires restriction to Posix-specified shell features.  "test"
is not a shell feature according to Posix.

On the other hand, if you say "Posix allows test to be builtin,
therefore it is a shell feature", then the consequences are horrible,
because Posix allows *anything whatsoever* to be builtin, including
say "debconf", and for a command like "debconf" the builtin could do
*anything whatsoever*.

So that second interpretation is clearly not correct.  Thus the former
one is.

Thomas





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #165 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 10 Sep 2004 20:43:54 -0400
> Yes.  Have you read my original bug report, which goes into
> considerable detail?  I'm not interested in rehearsing the whole thing
> in response to one-liner questions.

Yes.  You may note that I replied directly to your original bug report.

> If a maintainer finds a big in dash, and it's a pain to work around,
> it's a simple matter to just #!/bin/bash and be done with it.

Actually, what usually happens is that a bug is filed against dash and
Herbert fixes it.

> This is incorrect.

No.

> Policy requires restriction to Posix-specified shell features.  "test"
> is not a shell feature according to Posix.

POSIX mentions "test" both as a Korn shell builtin and as a Bourne shell
builtin.

> On the other hand, if you say "Posix allows test to be builtin,
> therefore it is a shell feature", then the consequences are horrible,
> because Posix allows *anything whatsoever* to be builtin, including
> say "debconf", and for a command like "debconf" the builtin could do
> *anything whatsoever*.
>
> So that second interpretation is clearly not correct.  Thus the former
> one is.

This is incorrect.

"debconf" is not specified by POSIX.  A #!/bin/sh maintainer script
calling "debconf" does not suddenly violate policy if bash implements a
"debconf" builtin.  Nor does bash violate policy by doing so.  

How does one interpret policy to make any of the preceding three
statements untrue?



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #170 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 17:47:57 -0700
Clint Adams <schizo@debian.org> writes:

> > Policy requires restriction to Posix-specified shell features.  "test"
> > is not a shell feature according to Posix.
> 
> POSIX mentions "test" both as a Korn shell builtin and as a Bourne shell
> builtin.

What it mentions for the Korn shell of course doesn't matter here.
Can you give me a reference to the latter?  I looked carefully, and I
only found it mentioned as a utility.

> "debconf" is not specified by POSIX.  A #!/bin/sh maintainer script
> calling "debconf" does not suddenly violate policy if bash implements a
> "debconf" builtin.  Nor does bash violate policy by doing so.  

Policy does not say that you must restrict yourself to Posix features
in general; it only says rather that you must restrict yourself to
Posix features in the shell.  Posix, AFAICT, does not describe "test"
as a shell thing at all, any more than "ls".

But you seem to indicate above that I may have missed something; can
you show me the section where Posix describes "test" as a shell
builtin?




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #175 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: schizo@debian.org
Cc: 267142@bugs.debian.org
Subject: huh?
Date: 10 Sep 2004 18:01:32 -0700
> You may note that I replied directly to your original bug report.

I have just reviewed bugs.debian.org/267142, and AFAICT, this is
incorrect.  Your messages listed there have only been in response to
other people's statements, and seem to be mistaken in taking Debian
Policy to require restriction to the entire Posix.1 spec.

Incidentally, you are also incorrect when you say:

> "debconf" is not specified by POSIX.  A #!/bin/sh maintainer script
> calling "debconf" does not suddenly violate policy if bash implements a
> "debconf" builtin.  Nor does bash violate policy by doing so.  

Policy 10.4 says that /bin/sh can be "a symbolic link to any POSIX
compatible shell..."  

A shell with a crazy debconf builtin is still a POSIX compatible
shell, and so the "should" advice in Policy 10.4 kicks in, and one
should not use debconf (or use it through a complete path name).

Strictly speaking, section 10.4 prohibits the use of a non-Posix
feature in any Posix-specified program, and prohibits the use of
non-Posix-specified programs entirely (or rather, if one does not use
a full pathname for the command in question).

But this is clearly not the intention of the section.  The section is
intending only to restrict the use of Posix features *of the shell
command interpreter*.  The problem is that "whether such-and-such is a
feature of the shell" is itself an issue that shell disagree about,
and moreover.

Note that test -a *will* work on a truly Posix minimal shell, because
a truly Posix minimal shell won't implement that as a builtin, and so
/usr/bin/test will be executed, which on Debian does support -a.

So the problem is that Policy 10.4 has a technical bug.  My preferred
fix is to list which shells' features one can use, by listing the
shells.  I am happy to see posh on that list, or not; it doesn't
matter much to me one way or the other.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #180 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 10 Sep 2004 21:04:06 -0400
> What it mentions for the Korn shell of course doesn't matter here.

Is it?  I was under the impression that a majority of the spec was based
on Korn behaviors.

> Can you give me a reference to the latter?  I looked carefully, and I
> only found it mentioned as a utility.

In the informative RATIONALE section of the description of the "test"
utility: 

 Some additional primaries newly invented or from the KornShell appeared
 in an early proposal as part of the conditional command ( [[]]): s1 >
 s2, s1 < s2, str = pattern, str != pattern, f1 -nt f2, f1 -ot f2, and f1
 -ef f2. They were not carried forward into the test utility when the
 conditional command was removed from the shell because they have not
 been included in the test utility built into historical implementations
 of the sh utility.


> Policy does not say that you must restrict yourself to Posix features
> in general; it only says rather that you must restrict yourself to
> Posix features in the shell.  Posix, AFAICT, does not describe "test"
> as a shell thing at all, any more than "ls".

It's possible for a shell to implement "ls" as a builtin.  It's also
possible for a sysadmin to implement "ls" as a shell function or alias.
In fact, people tend to clamor about their need to have this ability
when it is suggested that a full path to a program be used in a
maintainer script.

I suspect that as time goes on, some people will want to use "ls" from
various *BSD userlands rather than the GNU coreutils version, and many
flamewars will ensue.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #185 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 18:09:22 -0700
Clint Adams <schizo@debian.org> writes:

> > What it mentions for the Korn shell of course doesn't matter here.
> 
> Is it?  I was under the impression that a majority of the spec was based
> on Korn behaviors.

This is of historical interest; it is not of interest to what the
standard requires for the sh command interpreter.

> > Can you give me a reference to the latter?  I looked carefully, and I
> > only found it mentioned as a utility.
> 
> In the informative RATIONALE section of the description of the "test"
> utility: 
> 
>  Some additional primaries newly invented or from the KornShell appeared
>  in an early proposal as part of the conditional command ( [[]]): s1 >
>  s2, s1 < s2, str = pattern, str != pattern, f1 -nt f2, f1 -ot f2, and f1
>  -ef f2. They were not carried forward into the test utility when the
>  conditional command was removed from the shell because they have not
>  been included in the test utility built into historical implementations
>  of the sh utility.

RATIONALE is not part of the standard, nor does this does not require
the test utility to be built in.  It notes that building in test is
common, which is undisputed.  The question is not what is common; the
question is what is required and what is permitted from a Posix
shell.  

Debian Policy could say "don't rely on non-Posix behavior of utilities
which are commonly builtin to shells", but the problem with that is
the vagueness about "which are commonly builtin."

POSIX does not mandate building in test; "test", from the standpoint
of Posix, is just another utility.

And, like any utility, a shell may build it in if it wishes.

> It's possible for a shell to implement "ls" as a builtin.  It's also
> possible for a sysadmin to implement "ls" as a shell function or alias.
> In fact, people tend to clamor about their need to have this ability
> when it is suggested that a full path to a program be used in a
> maintainer script.

Exactly.  It's possibly for "defconf" to be that too.  This is exactly
why the current language of the Policy manual fails.

> I suspect that as time goes on, some people will want to use "ls" from
> various *BSD userlands rather than the GNU coreutils version, and many
> flamewars will ensue.

But not here, because Policy says that if you are using something in
the Build-Essential set, you can rely on it being installed, and that
currently includes GNU coreutils.  If you want something not in the
Build-Essential set, then you can get it if you include a
Build-Depends, and that's that.

So the problem here only happens with respect to the extremely broad
permission from Posix to buildin any or all utilities.  This is not a
mistake in Posix, but it was a mistake for the Debian Policy Manual to
rely on Posix as it currently does, to be specifying a
"Posix-compatible shell".  Which is why my original bug report says
"Posix doesn't say what you think it does".

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #190 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: Fri, 10 Sep 2004 21:17:35 -0400
> I have just reviewed bugs.debian.org/267142, and AFAICT, this is
> incorrect.  Your messages listed there have only been in response to

Look for a message from me with "E1ByFzV-0005yk-00@kempis" in the
References: header.

> other people's statements, and seem to be mistaken in taking Debian
> Policy to require restriction to the entire Posix.1 spec.

Amusing.

> A shell with a crazy debconf builtin is still a POSIX compatible
> shell, and so the "should" advice in Policy 10.4 kicks in, and one
> should not use debconf (or use it through a complete path name).

What?

> Strictly speaking, section 10.4 prohibits the use of a non-Posix
> feature in any Posix-specified program, and prohibits the use of
> non-Posix-specified programs entirely (or rather, if one does not use
> a full pathname for the command in question).
> 
> But this is clearly not the intention of the section.  The section is
> intending only to restrict the use of Posix features *of the shell
> command interpreter*.  The problem is that "whether such-and-such is a
> feature of the shell" is itself an issue that shell disagree about,
> and moreover.

I agree that the wording is lacking.

> Note that test -a *will* work on a truly Posix minimal shell, because
> a truly Posix minimal shell won't implement that as a builtin, and so
> /usr/bin/test will be executed, which on Debian does support -a.

Also agreed.

> So the problem is that Policy 10.4 has a technical bug.  My preferred
> fix is to list which shells' features one can use, by listing the
> shells.  I am happy to see posh on that list, or not; it doesn't
> matter much to me one way or the other.

This was suggested years ago, and I thought it was a bad idea then
too.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #195 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: 10 Sep 2004 18:24:16 -0700
Clint Adams <schizo@debian.org> writes:

> > A shell with a crazy debconf builtin is still a POSIX compatible
> > shell, and so the "should" advice in Policy 10.4 kicks in, and one
> > should not use debconf (or use it through a complete path name).
> 
> What?

A shell with a crazy debconf builtin [that is, a shell with a builtin
called "debconf" that does something very different from the Debian
"debconf"] is still a POSIX compatible shell [that is, provided it
otherwise is, such a builtin is allowed for a POSIX compatible shell],
and so the "should" advice in Policy 10.4 kicks in [that is, the
requirement that one's scripts should work on any POSIX compatible
shell], and one should not use debconf [expecting to get the Debian
behavior, because a POSIX compatible shell can have a debconf builtin
that does something wildly different] (or use it through a complete
path name) [because of course this will avoid any builtin, though is
itself contrary to policy 6.1].

I'd be happy to explain in more detail, but you'll have to say which
part you didn't understand. 

I find your oneliner replies very annoying; if you would spend the
time to give your thoughts more completely it would vastly speed up
the discussion and make it far less difficult for me.

> > So the problem is that Policy 10.4 has a technical bug.  My preferred
> > fix is to list which shells' features one can use, by listing the
> > shells.  I am happy to see posh on that list, or not; it doesn't
> > matter much to me one way or the other.
> 
> This was suggested years ago, and I thought it was a bad idea then
> too.

Do you have an alternative way to specify what features a maintainer
script may rely on?  I proposed several in my original report that
would all do the job.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #200 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 10 Sep 2004 21:29:36 -0400
> common, which is undisputed.  The question is not what is common; the
> question is what is required and what is permitted from a Posix
> shell.  

Ah, I see.  I thought that that was covered with the lists of builtins
in bug#270868.

> Exactly.  It's possibly for "defconf" to be that too.  This is exactly
> why the current language of the Policy manual fails.

Only if you claim that policy prohibits you from running "debconf".
Otherwise it's irrelevant.

> So the problem here only happens with respect to the extremely broad
> permission from Posix to buildin any or all utilities.  This is not a
> mistake in Posix, but it was a mistake for the Debian Policy Manual to
> rely on Posix as it currently does, to be specifying a
> "Posix-compatible shell".  Which is why my original bug report says
> "Posix doesn't say what you think it does".

Is there an actual practical problem here?



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #205 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 18:38:36 -0700
Clint Adams <schizo@debian.org> writes:

> > common, which is undisputed.  The question is not what is common; the
> > question is what is required and what is permitted from a Posix
> > shell.  
> 
> Ah, I see.  I thought that that was covered with the lists of builtins
> in bug#270868.

Not quite.  That gives a list of builtins which is required (and which
does not include test, btw); more importantly Posix allows anything to
be a builtin.

As it happens, I think bug 270868 is crazy; there is no bug that posh
has a test builtin.  It is the case that posh has a test builtin which
is inconsistent with the Debian version of "test", but we have no rule
about whether Debian shells should remain consistent with the rest of
Debian, and I'm not interested in proposing one.

So don't associate bug 267142 with 270868; the latter is nutso.

> > Exactly.  It's possibly for "defconf" to be that too.  This is exactly
> > why the current language of the Policy manual fails.
> 
> Only if you claim that policy prohibits you from running "debconf".
> Otherwise it's irrelevant.

See below.

> > So the problem here only happens with respect to the extremely broad
> > permission from Posix to buildin any or all utilities.  This is not a
> > mistake in Posix, but it was a mistake for the Debian Policy Manual to
> > rely on Posix as it currently does, to be specifying a
> > "Posix-compatible shell".  Which is why my original bug report says
> > "Posix doesn't say what you think it does".
> 
> Is there an actual practical problem here?

Yes.  There are two possible interpretations of Policy here.

One interpretation would prohibit the use of test -a; but would also
prohibit the use of "debconf" and many many other things.

The other interpretation (mine, in fact) would allow test -a, in which
case there are people running around filing bogus bug reports.  But
this interpretation does not serve the important goals of Policy
section 10.4, which is why I filed bug 267142, to attempt to find a
way to satisfy the goals of 10.4 cleanly.

Someone else thought this meant that posh shouldn't buildin test,
which in my opinion is entirely irrelevant.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #210 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: Fri, 10 Sep 2004 21:42:11 -0400
> A shell with a crazy debconf builtin [that is, a shell with a builtin
> called "debconf" that does something very different from the Debian
> "debconf"] is still a POSIX compatible shell [that is, provided it
> otherwise is, such a builtin is allowed for a POSIX compatible shell],
> and so the "should" advice in Policy 10.4 kicks in [that is, the
> requirement that one's scripts should work on any POSIX compatible
> shell], and one should not use debconf [expecting to get the Debian
> behavior, because a POSIX compatible shell can have a debconf builtin
> that does something wildly different] (or use it through a complete
> path name) [because of course this will avoid any builtin, though is
> itself contrary to policy 6.1].
> 
> I'd be happy to explain in more detail, but you'll have to say which
> part you didn't understand. 

No, that was better.  I don't think it's accurate to consider "debconf"
a non-POSIX shell feature upon which maintainer scripts rely unless such
maintainer scripts rely on the enhancements present in the pdksh-specific
"debconf" builtin.

> I find your oneliner replies very annoying; if you would spend the
> time to give your thoughts more completely it would vastly speed up
> the discussion and make it far less difficult for me.

Hmm.

> Do you have an alternative way to specify what features a maintainer
> script may rely on?  I proposed several in my original report that
> would all do the job.

I would be more specific about what "POSIX" means in 10.4, but I don't
think that would solve your problem.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #215 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: 10 Sep 2004 18:49:47 -0700
Clint Adams <schizo@debian.org> writes:

> No, that was better.  I don't think it's accurate to consider "debconf"
> a non-POSIX shell feature upon which maintainer scripts rely unless such
> maintainer scripts rely on the enhancements present in the pdksh-specific
> "debconf" builtin.

I didn't say that "debconf" is a non-POSIX shell feature.  Policy 10.4
doesn't say that anyway.  It says your script should work with any
Posix-compliant shell.  A script that says "debconf" doesn't.

Or, under my interpretation, it says that you don't need to worry
about whether a shell supports a command as a builtin or not (though
obviously you cannot *rely* on it being builtin), in which case
"debconf" and "test -a" are both fine.  But then policy 10.4 is not
achieving its goals.

> > Do you have an alternative way to specify what features a maintainer
> > script may rely on?  I proposed several in my original report that
> > would all do the job.
> 
> I would be more specific about what "POSIX" means in 10.4, but I don't
> think that would solve your problem.

Well then if you don't like the list-of-shells approach, but you can't
think of anything better, then that leaves list-of-shells as the most
popular alternative.  (And I don't have any preferences about which
shells are in that list, provided bash is.)

I agree that it might also be a good idea to be more exact about what
"Posix shell" means in 10.4, and I'll do my best to have that
reflected in any redrafting of the section. 

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #220 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 10 Sep 2004 21:52:43 -0400
> One interpretation would prohibit the use of test -a; but would also
> prohibit the use of "debconf" and many many other things.
> 
> The other interpretation (mine, in fact) would allow test -a, in which
> case there are people running around filing bogus bug reports.  But
> this interpretation does not serve the important goals of Policy
> section 10.4, which is why I filed bug 267142, to attempt to find a
> way to satisfy the goals of 10.4 cleanly.
> 
> Someone else thought this meant that posh shouldn't buildin test,
> which in my opinion is entirely irrelevant.

I wouldn't mind if Debian prevented you from using "test -a" altogether,
but you are not thusly prevented, and I don't argue that you should be
prevented.

I do think it's a violation of 10.4 for you to use in a #!/bin/sh script
"test -a" without a path prepended.

I think you would be exercising poor judgment either by changing your
shebang line to specify a specific shell with a "test" builtin or by
prepending a path to "test" in order to use "test -a".

So I don't see a practical problem here.  Brace expansion is greatly
more useful than "test -a".



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #225 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: Fri, 10 Sep 2004 21:57:44 -0400
> I didn't say that "debconf" is a non-POSIX shell feature.  Policy 10.4
> doesn't say that anyway.  It says your script should work with any
> Posix-compliant shell.  A script that says "debconf" doesn't.

Apparently I didn't actually understand.  Does it say that explicitly
or are you inferring that somehow?

> Well then if you don't like the list-of-shells approach, but you can't
> think of anything better, then that leaves list-of-shells as the most
> popular alternative.  (And I don't have any preferences about which
> shells are in that list, provided bash is.)

I think the current wording is better, though far from perfect.
Part of the point of 10.4 is that the list of shells is irrelevant.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #230 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 18:58:30 -0700
Clint Adams <schizo@debian.org> writes:

> I wouldn't mind if Debian prevented you from using "test -a" altogether,
> but you are not thusly prevented, and I don't argue that you should be
> prevented.
>
> I do think it's a violation of 10.4 for you to use in a #!/bin/sh script
> "test -a" without a path prepended.

Why?  Section 10.4 restricts my use of the shell; but "test" is a
Debian command, and not part of the shell specification at all.  And
if you say "but test is a builtin", then I respond, "but so debconf
might be, and that's clearly allowed."

But you can stick to your guns and say "debconf isn't allowed either".

Either way, section 10.4 is broken.
 
> I think you would be exercising poor judgment either by changing your
> shebang line to specify a specific shell with a "test" builtin or by
> prepending a path to "test" in order to use "test -a".

Well, I don't want to exercise poor judgment, so I won't do either;
I'll leave my package as is.  :)

The question however is not about "test -a"; it's a broader question,
which is why I 1) did not change my package when someone complained
about test -a, and 2) filed bug 267142 so that the situation can be
clarified.

Once it's clarified, I will of course fix my package to comply.  For
example, if we go with the list-of-shell method, and posh is in the
list, then of course I'll drop test -a.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #235 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: 10 Sep 2004 19:01:46 -0700
Clint Adams <schizo@debian.org> writes:

> > I didn't say that "debconf" is a non-POSIX shell feature.  Policy 10.4
> > doesn't say that anyway.  It says your script should work with any
> > Posix-compliant shell.  A script that says "debconf" doesn't.
> 
> Apparently I didn't actually understand.  Does it say that explicitly
> or are you inferring that somehow?

It refers to requiring "non-POSIX features".  In this case, it
requires the "doesn't buildin debconf" feature, which is non-POSIX.  

> > Well then if you don't like the list-of-shells approach, but you can't
> > think of anything better, then that leaves list-of-shells as the most
> > popular alternative.  (And I don't have any preferences about which
> > shells are in that list, provided bash is.)
> 
> I think the current wording is better, though far from perfect.
> Part of the point of 10.4 is that the list of shells is irrelevant.

The current wording however implies that test -a is fine.  

But alas, you haven't explained your interpertation.  I'm going to
disregard the rest of your posts unless you will take the time to do
more than one-liners, and perhaps give your understanding of the
section and how to determine when one may rely on something being
not-built-in and when one may not.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #240 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 10 Sep 2004 22:25:32 -0400
> Why?  Section 10.4 restricts my use of the shell; but "test" is a
> Debian command, and not part of the shell specification at all.  And
> if you say "but test is a builtin", then I respond, "but so debconf
> might be, and that's clearly allowed."
> 
> But you can stick to your guns and say "debconf isn't allowed either".
> 
> Either way, section 10.4 is broken.

I'll try saying this a different way.  Expecting "debconf" to not be a
shell builtin is not "relying on a shell feature".

> The question however is not about "test -a"; it's a broader question,
> which is why I 1) did not change my package when someone complained
> about test -a, and 2) filed bug 267142 so that the situation can be
> clarified.

Yes, I realize that.  I would be ignoring you otherwise.

> Once it's clarified, I will of course fix my package to comply.  For
> example, if we go with the list-of-shell method, and posh is in the
> list, then of course I'll drop test -a.

Since you keep bringing it up, I'll bite.

If you have a list of shells, you need a decision-making process each
time you want to add or remove an entry from that list.  If you happen
to add an entry, you risk making an indeterminate number of packages
instantly buggy.  If a shell on the list changes behavior, it is still
on the list, and you risk making an indeterminate number of packages
instantly buggy.  In this scenario, a shell on the list can do any
ridiculous thing and it will not be buggy; other packages will be.
Even now, if a #!/bin/bash script fails to run on bash 3, it isn't
necessarily clear where the bug lies.

Conversely, under current practice (even if this isn't exactly what 10.4
says), if you use brace expansions in a #!/bin/sh script, someone will
file a bug against your package saying "bashism! this doesn't work with
dash".  Because brace expansions aren't POSIX, the onus is on you to fix
it.  If your package fails because someone's using a SYSV-type "echo"
and you are relying on BSD-style "echo -n" functionality, your package
is not buggy because you are conforming to Debian policy, even though
the user in question may have a fully-POSIX-conformant setup.

I attach no importance to whether or not this hypothetical "echo" is a
shell builtin or a standalone utility, and I don't think 10.4 cares
either.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #245 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: Fri, 10 Sep 2004 22:33:38 -0400
> It refers to requiring "non-POSIX features".  In this case, it
> requires the "doesn't buildin debconf" feature, which is non-POSIX.  

I think calling that a feature is a bit of a stretch.

> The current wording however implies that test -a is fine.  

If it doesn't guarantee that you can rely on a POSIX-conformant "test",
I don't see how it guarantees anything at all about "test".

> But alas, you haven't explained your interpertation.  I'm going to
> disregard the rest of your posts unless you will take the time to do
> more than one-liners, and perhaps give your understanding of the
> section and how to determine when one may rely on something being
> not-built-in and when one may not.

Suit yourself.

I don't think that "built-in-ness" is any concern of #!/bin/sh scripts,
and I don't think that it should be any more than it knows whether
its commands are shell functions or aliases.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #250 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 19:38:09 -0700
Clint Adams <schizo@debian.org> writes:

> I'll try saying this a different way.  Expecting "debconf" to not be a
> shell builtin is not "relying on a shell feature".

Ok.  But then likewise, expecting "test" to not be a shell builtin is
not "relying on a shell feature".  

My package expects test not to be a builtin, and restricts itself to
the features of Debian /usr/bin/test.  It happens to work as well if
the shell implements a consistent builtin, but it certainly does not
rely on this.  What it relies on is the disjunction "test is either
not builtin, or is builtin compatably with /usr/bin/test."

Which is just the same as "debconf is either not builtin, or is
builtin compatably with /usr/bin/debconf."

> If you have a list of shells, you need a decision-making process each
> time you want to add or remove an entry from that list.  If you happen
> to add an entry, you risk making an indeterminate number of packages
> instantly buggy.  If a shell on the list changes behavior, it is still
> on the list, and you risk making an indeterminate number of packages
> instantly buggy.  In this scenario, a shell on the list can do any
> ridiculous thing and it will not be buggy; other packages will be.
> Even now, if a #!/bin/bash script fails to run on bash 3, it isn't
> necessarily clear where the bug lies.

Quite right; this is the downside of the list-of-shells approach.

But consider: Suppose the bash maintainer decides to add a builtin
called "scsh", which turns on a special "screen shell" mode.  

And suddenly, any package that uses the scsh program will fail!  There
is a bug here somewhere; either in the package or in bash.  But the
current policy 10.4 makes entirely unclear what to do.

It is this problem which my bug report is intended to address.  The
list-of-shells approach clarifies, but other approaches would as
well.  "Just ignore it" doesn't clarify.

Nor is it clear, because, for example, it doesn't specify how to
understand the test -a situation!

Thomas





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #255 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: 10 Sep 2004 19:40:32 -0700
Clint Adams <schizo@debian.org> writes:

> If it doesn't guarantee that you can rely on a POSIX-conformant "test",
> I don't see how it guarantees anything at all about "test".

You can rely on a POSIX-conformant test, certainly.  Posix-conformant
does not mean that the "test" program doesn't have any additional
options or features.  GNU test, which supports -a and is the Debian
standard implementation of the "test" command, is Posix-conformant.

> I don't think that "built-in-ness" is any concern of #!/bin/sh scripts,
> and I don't think that it should be any more than it knows whether
> its commands are shell functions or aliases.

Really?  Because when I run "debconf" I expect to have it either be
not builtin, or be builtin compatibly with /usr/bin/debconf.  I expect
the very same thing for every command.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #260 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 10 Sep 2004 23:09:57 -0400
> My package expects test not to be a builtin, and restricts itself to
> the features of Debian /usr/bin/test.  It happens to work as well if
> the shell implements a consistent builtin, but it certainly does not
> rely on this.  What it relies on is the disjunction "test is either
> not builtin, or is builtin compatably with /usr/bin/test."

The "builtin" is a red herring.  Your package will be none the wiser if
a shell implements a "test" conforming to the de facto coreutils spec in
the form of a builtin, a shell function, or something else.

> Which is just the same as "debconf is either not builtin, or is
> builtin compatably with /usr/bin/debconf."

Right.  What you really want is to rely on the established debconf
interface.

> Quite right; this is the downside of the list-of-shells approach.
> 
> But consider: Suppose the bash maintainer decides to add a builtin
> called "scsh", which turns on a special "screen shell" mode.  
> 
> And suddenly, any package that uses the scsh program will fail!  There
> is a bug here somewhere; either in the package or in bash.  But the
> current policy 10.4 makes entirely unclear what to do.

Agreed.  However, it is likely that someone will be able to qualify this
bug without the aid of 10.4.

> It is this problem which my bug report is intended to address.  The
> list-of-shells approach clarifies, but other approaches would as
> well.  "Just ignore it" doesn't clarify.
> 
> Nor is it clear, because, for example, it doesn't specify how to
> understand the test -a situation!

If it is correct for 10.4 to address these problems, then 10.4 should be
clarified.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #265 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: Fri, 10 Sep 2004 23:14:45 -0400
> You can rely on a POSIX-conformant test, certainly.  Posix-conformant
> does not mean that the "test" program doesn't have any additional
> options or features.  GNU test, which supports -a and is the Debian
> standard implementation of the "test" command, is Posix-conformant.

Hold on.  If tbsh, a POSIX-conformant sh (according to your
exclusion of "utilities"), implements a "test" builtin that isn't
POSIX-conformant, does 10.4 apply or not?  If it doesn't, how can you
rely on a POSIX-conformant test?

> Really?  Because when I run "debconf" I expect to have it either be
> not builtin, or be builtin compatibly with /usr/bin/debconf.  I expect
> the very same thing for every command.

Even in the case of alternatives and diversions and conflicting packages
providing the same-named binaries, in the presence or absence of actual
standards describing those commands?



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #270 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 20:19:00 -0700
Clint Adams <schizo@debian.org> writes:

> The "builtin" is a red herring.  Your package will be none the wiser if
> a shell implements a "test" conforming to the de facto coreutils spec in
> the form of a builtin, a shell function, or something else.

Quite right, but the exact same is true of debconf.

My point here is that debconf and test are on exactly the same
footing.

Having specified them in Build-Depends (or relied on the list of build
essential packages), I am allowed to expect the Debian behavior of the
program.

Which means that "test -a" is currently allowed.

So, doesn't this mean that "posh" has a bug, since (I'm told; perhaps
I'm incorrect) it implements a "test" which does NOT conform to the de
facto coreutils spec?

That suggests a new option for solving the bug I reported, one which
is not one of my original four:

  Require any shell that implements /bin/sh to be required to build in
  commands (that exist as programs in the filesystem also) only in
  ways which are indistinguishable in practice from the normal Debian
  versions.

I would be as happy with this as with the list-of-shells approach, but
I think I overlooked it at first because I assumed that an option
which restricted the behavior of shells would be looked unfavorably
upon.

But this is indeed another option we could consider.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #275 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: 10 Sep 2004 20:26:53 -0700
Clint Adams <schizo@debian.org> writes:

> > You can rely on a POSIX-conformant test, certainly.  Posix-conformant
> > does not mean that the "test" program doesn't have any additional
> > options or features.  GNU test, which supports -a and is the Debian
> > standard implementation of the "test" command, is Posix-conformant.
> 
> Hold on.  If tbsh, a POSIX-conformant sh (according to your
> exclusion of "utilities"), implements a "test" builtin that isn't
> POSIX-conformant, does 10.4 apply or not?  If it doesn't, how can you
> rely on a POSIX-conformant test?

"Posix-conformant" does not fully specify the behavior of programs.
For example, a posix conformant test might, or might not, implement
-a. 

If I rely on GNU test, I am still relying on a POSIX conformant test.  

So there is certainly a POSIX rule that a builtin test must implement
at least the POSIX "test" spec; but that's not enough in practice.
POSIX assumes that builtins will work exactly the same as the programs
in the filesystem, but never actually requires this, and that's the
root of the situation.  Shells like posh (IIUC) implement builtins
like "test" in a way which is different from with the Debian versions.

> > Really?  Because when I run "debconf" I expect to have it either be
> > not builtin, or be builtin compatibly with /usr/bin/debconf.  I expect
> > the very same thing for every command.
> 
> Even in the case of alternatives and diversions and conflicting packages
> providing the same-named binaries, in the presence or absence of actual
> standards describing those commands?

Yes.  If I depend on a package, I am allowed to assume that the Debian
version of that package's files is installed, and rely on it having
exactly the behavior of the Debian version.  But I must either depend
on the package; or it can be an essential package (which doesn't
require a dependency).  In the common case here, "coreutils" is an
essential package, and I am allowed to assume that /usr/bin/test is
exactly that program.

Alternatives need in general to be specified, in terms of what is the
standard interface that must be supported by all the various
alternatives.  In practice, that specification can be ad hoc, where
individual features either get declared "not standard", or the various
versions coerced to implement the same behavior.

/bin/sh in Debian has not normally been treated this way; treating it
that way would be like my OPTION 3, in which there is a specified
interface for /bin/sh.  (Because the instant problem is that
"Posix-compliant shell" is not actually an adequate specification of
the interface of /bin/sh.)

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, debian-policy@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@stanford.edu>:
Extra info received and forwarded to list. Copy sent to debian-policy@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #280 received at 267142@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@stanford.edu>
To: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Fri, 10 Sep 2004 20:28:44 -0700
(I hope I got the addressing right on this.)

I probably should not jump into this, as this thread is already quite long
and I'm not sure I'm going to remember everything that was previously
raised, but it feels like something's being missed a little.

In linux.debian.policy, Thomas Bushnell BSG <tb@becket.net> writes:

> My package expects test not to be a builtin, and restricts itself to the
> features of Debian /usr/bin/test.  It happens to work as well if the
> shell implements a consistent builtin, but it certainly does not rely on
> this.  What it relies on is the disjunction "test is either not builtin,
> or is builtin compatably with /usr/bin/test."

I would say instead that your package doesn't care whether test is a
builtin or not, but relies on test having a certain set of features.
Wouldn't that be an easier way of phrasing the limitation in policy?

In other words, what about saying something like:

    Any /bin/sh script must work with a minimal POSIX-compliant shell with
    no builtins other than the required ones.  /bin/sh scripts must also
    work with any POSIX-compliant implementations of the following basic
    utilities:  echo, test, (whatever else we want to list).
    Exceptionally, /bin/sh scripts may assume that echo -n works to
    suppress the output of a newline.

    All other basic shell utilities may be assumed to be compatible with
    the binaries provided as part of a base Debian system, meaning that if
    shells implement them as built-ins, they must provide functionality
    equivalent to the standard utilities.

That's very, very rough and will require some rewording, but I hope you
get the idea.

This all came up in the first place, as far as I can tell, because Policy
doesn't draw a clear line between shell behavior and the behavior of
commands that are sometimes built-ins and sometimes not.  So separate the
two cases, by redoing the shell requirement so that it doesn't directly
address optional built-ins, and then explicitly add in those utilities
where a shell can get away with implementing a purely POSIX-compatible
built-in rather than invoking the respective utility.

Please note that I am completely ambivalent on whether test -a and test -o
should be supported.  I just think that if they are allowed, they should
be called out separately just like echo -n is now, and I think the above
wording would accomplish that.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #285 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Russ Allbery <rra@stanford.edu>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 20:41:33 -0700
Russ Allbery <rra@stanford.edu> writes:

> I would say instead that your package doesn't care whether test is a
> builtin or not, but relies on test having a certain set of features.
> Wouldn't that be an easier way of phrasing the limitation in policy?

Yes indeed.  

>     Any /bin/sh script must work with a minimal POSIX-compliant shell with
>     no builtins other than the required ones.  /bin/sh scripts must also
>     work with any POSIX-compliant implementations of the following basic
>     utilities:  echo, test, (whatever else we want to list).
>     Exceptionally, /bin/sh scripts may assume that echo -n works to
>     suppress the output of a newline.

This is OPTION 3 in my original bug report.  It does indeed solve the
problem.   

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #290 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 11 Sep 2004 00:07:04 -0400
> Having specified them in Build-Depends (or relied on the list of build
> essential packages), I am allowed to expect the Debian behavior of the
> program.

Well, that's certainly an interesting idea.

> So, doesn't this mean that "posh" has a bug, since (I'm told; perhaps
> I'm incorrect) it implements a "test" which does NOT conform to the de
> facto coreutils spec?

It doesn't.  posh's "test" does not currently mirror the behavior of
anything listed below.

coreutils 5.2.1-2
Unary: -[bcdefghknprstuwxzGLOS]
Binary: -nt -ot -ef = != -eq -ne -lt -le -gt -ge -a -o
Other: ! ( )

bash 2.05b-15
Unary: -[abcdefghknoprstuwxzGLNOS]
Binary: -nt -ot -ef = == != < > -eq -ne -lt -le -gt -ge -a -o
Other: ! ( )

dash 0.5.1-3
Unary: -[bcdefghknprstuwxzGLOS]
Binary: -nt -ot -ef = != < > -eq -ne -lt -le -gt -ge -a -o
Other: ! ( )

pdksh 5.2.14-12
Unary: -[abcdefghknoprstuwxzGHLOS]
Binary: -nt -ot -ef = == != -eq -ne -lt -le -gt -ge -a -o
Other: ! ( )

zsh 4.2.1-3
Unary: -[abcdefghknoprstuwxzGLNOS]
Binary: -nt -ot -ef = == != < > -eq -ne -lt -le -gt -ge -a -o || &&
Other: ! ( )

POSIX
Unary: -[bcdefghnprstuwxzLS]
Binary: = != -eq -ne -lt -le -gt -ge



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #295 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 21:09:19 -0700
Clint Adams <schizo@debian.org> writes:

> > Having specified them in Build-Depends (or relied on the list of build
> > essential packages), I am allowed to expect the Debian behavior of the
> > program.
> 
> Well, that's certainly an interesting idea.

Again, your habit of the one-liner leaves me entirely unsure of what
you mean.  Are you being sarcastic, or hinting at some other bug, or
saying that I'm incorrect, or what?




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #300 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: Sat, 11 Sep 2004 00:11:16 -0400
> So there is certainly a POSIX rule that a builtin test must implement

Is that rule germane to 10.4?

> root of the situation.  Shells like posh (IIUC) implement builtins
> like "test" in a way which is different from with the Debian versions.

All shells I mentioned in the previous message implement builtins like
"test" in a way which is different.

> Yes.  If I depend on a package, I am allowed to assume that the Debian
> version of that package's files is installed, and rely on it having
> exactly the behavior of the Debian version.  But I must either depend
> on the package; or it can be an essential package (which doesn't
> require a dependency).  In the common case here, "coreutils" is an
> essential package, and I am allowed to assume that /usr/bin/test is
> exactly that program.

But you are not calling /usr/bin/test, and the likelihood that you
will get /usr/bin/test without using a full path is somewhere between
infinitesimal and nil.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #305 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: 10 Sep 2004 21:17:52 -0700
Clint Adams <schizo@debian.org> writes:

> > So there is certainly a POSIX rule that a builtin test must implement
> 
> Is that rule germane to 10.4?

Yes, because 10.4 says that you can assume that /bin/sh conforms to
Posix, so you can assume that any builtin which is Posix-specified, is
compatible with the spec.

> > Yes.  If I depend on a package, I am allowed to assume that the Debian
> > version of that package's files is installed, and rely on it having
> > exactly the behavior of the Debian version.  But I must either depend
> > on the package; or it can be an essential package (which doesn't
> > require a dependency).  In the common case here, "coreutils" is an
> > essential package, and I am allowed to assume that /usr/bin/test is
> > exactly that program.
> 
> But you are not calling /usr/bin/test, and the likelihood that you
> will get /usr/bin/test without using a full path is somewhere between
> infinitesimal and nil.

Actually, that's not true.  Perhaps you haven't read much on what
guarantees Policy makes about maintainer scripts.

In any case, if you really mean what you say here, then you must be
supporting OPTION 4.  If *that's* what you mean, why didn't you say
so? 

Regardless, can you please decide what you would prefer first, and
only then post?  This incessant dancing around, refusing to actually
state *your* opinion about the best course of action, only makes the
process more frustrating.  It may be entertaining for you, but it's a
PITA for me.

Can you please try and just say what you think the world should look
like?  I feel as if you got in this only because someone filed a
foolish bug against posh.  If that's true, then you can please stop
kvetching about the present case, unless you truly have something
concrete to contribute instead of repeatedly rehashing things?

Most of what you have brought up has already been considered in my
original bug report.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #310 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 11 Sep 2004 00:29:49 -0400
> Again, your habit of the one-liner leaves me entirely unsure of what
> you mean.  Are you being sarcastic, or hinting at some other bug, or
> saying that I'm incorrect, or what?

After thinking about this some more I may prefer something like

  OPTION #: Clarify 10.4 to explicitly proscribe reliance on features
  not required by POSIX not only for the shell and its command language,
  but for all utilities required by XCU unless said scripts ensure that
  they invoke the specific utilities providing such features.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #315 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 10 Sep 2004 21:32:05 -0700
Clint Adams <schizo@debian.org> writes:

> After thinking about this some more I may prefer something like
> 
>   OPTION #: Clarify 10.4 to explicitly proscribe reliance on features
>   not required by POSIX not only for the shell and its command language,
>   but for all utilities required by XCU unless said scripts ensure that
>   they invoke the specific utilities providing such features.

Ok, that's OPTION 3, but with a very big list of programs specified.

I think the problem with that is that the list of programs is way too
big, and includes programs which nobody in practice will ever build
in.  

Debian does *not* promise--and should not promise--that you can
substitute any old Posix ls in place of ls.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Clint Adams <schizo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #320 received at 267142@bugs.debian.org (full text, mbox):

From: Clint Adams <schizo@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: Sat, 11 Sep 2004 00:44:41 -0400
> > But you are not calling /usr/bin/test, and the likelihood that you
> > will get /usr/bin/test without using a full path is somewhere between
> > infinitesimal and nil.
> 
> Actually, that's not true.  Perhaps you haven't read much on what
> guarantees Policy makes about maintainer scripts.
> 
> In any case, if you really mean what you say here, then you must be
> supporting OPTION 4.  If *that's* what you mean, why didn't you say
> so? 

Perhaps I worded that poorly.  I'll try again.

But you are not calling /usr/bin/test, and the likelihood that you
will get the GNU coreutils test without using a full path is extremely
low.

> Regardless, can you please decide what you would prefer first, and
> only then post?  This incessant dancing around, refusing to actually
> state *your* opinion about the best course of action, only makes the
> process more frustrating.  It may be entertaining for you, but it's a
> PITA for me.

If you mean with regard to changing policy, I may have articulated that.
Otherwise, I think the best course of action is for everyone to convert
their #!/bin/bash scripts to #!/bin/sh scripts, make their #!/bin/sh
scripts happily portable to the degree that the people who have been
filing 10.4 sane bugs want them to be, drop the Essentialness of bash,
and then everyone will have an easier time installing a system on a 16MB
flash card.

> Can you please try and just say what you think the world should look
> like?  I feel as if you got in this only because someone filed a
> foolish bug against posh.  If that's true, then you can please stop
> kvetching about the present case, unless you truly have something
> concrete to contribute instead of repeatedly rehashing things?

I will refrain from kvetching or contributing further until an
unspecified time in the future.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #325 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org
Subject: Re: huh?
Date: 10 Sep 2004 21:49:34 -0700
Clint Adams <schizo@debian.org> writes:

> But you are not calling /usr/bin/test, and the likelihood that you
> will get the GNU coreutils test without using a full path is extremely
> low.

I'm not terribly interested in "probabilities".  I'm interested in
making the policy as good as possible, and no more restrictive than
necessary.

In fact, one is allowed in Debian maintainer scripts to assume that
the PATH is set appropriately, and to assume that packages you depend
on are properly installed.

FWIW, policy says not to call /usr/bin/test.  Review the original bug
report.

> If you mean with regard to changing policy, I may have articulated that.
> Otherwise, I think the best course of action is for everyone to convert
> their #!/bin/bash scripts to #!/bin/sh scripts, make their #!/bin/sh
> scripts happily portable to the degree that the people who have been
> filing 10.4 sane bugs want them to be, drop the Essentialness of bash,
> and then everyone will have an easier time installing a system on a 16MB
> flash card.

Frankly, I don't give a damn about 16MB flash cards, and Policy says I
don't have to.  Making Debian support 16MB flash cards may be a good
idea, but it requires a lot of work, and I don't think miscfiles is
the place to begin that work.

But my first reaction to the issue here is to simply depend on bash.
If I were to fix the bug in question, I would not alter my use of test
to comply with some foolish idea about what "looks better".  To me, -a
looks better, because -a is typical for command arguments and "&&" is
not.  "&&" looks like a freaky backgrounding command to me.  And in
Version 7 Unix, -a was the only option, so it's really "&&" that is
the freaky novelty.  To my eye, at least.

So my reaction would be to say that bash is a required package anyway,
so I can simply use /bin/bash.

But I'm not going to do that so long as policy (under my reading)
allows test -a in a /bin/sh script.  

However, this makes many people unhappy, which is why the present bug
is being discussed.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #330 received at 267142@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>, 267142@bugs.debian.org
Cc: Clint Adams <schizo@debian.org>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 11 Sep 2004 09:47:42 +0100
On Fri, Sep 10, 2004 at 08:19:00PM -0700, Thomas Bushnell BSG wrote:
> Clint Adams <schizo@debian.org> writes:
> > The "builtin" is a red herring.  Your package will be none the wiser if
> > a shell implements a "test" conforming to the de facto coreutils spec in
> > the form of a builtin, a shell function, or something else.
> 
> Quite right, but the exact same is true of debconf.
> 
> My point here is that debconf and test are on exactly the same
> footing.
> 
> Having specified them in Build-Depends (or relied on the list of build
> essential packages), I am allowed to expect the Debian behavior of the
> program.
> 
> Which means that "test -a" is currently allowed.
> 
> So, doesn't this mean that "posh" has a bug, since (I'm told; perhaps
> I'm incorrect) it implements a "test" which does NOT conform to the de
> facto coreutils spec?
> 
> That suggests a new option for solving the bug I reported, one which
> is not one of my original four:
> 
>   Require any shell that implements /bin/sh to be required to build in
>   commands (that exist as programs in the filesystem also) only in
>   ways which are indistinguishable in practice from the normal Debian
>   versions.

Why not forget about doing this in 10.4, and simply invoke 10.1?

  Two different packages must not install programs with different
  functionality but with the same filenames. (The case of two programs
  having the same functionality but different implementations is handled
  via "alternatives" or the "Conflicts" mechanism. See Maintainer
  Scripts, Section 3.10 and Conflicting binary packages - Conflicts,
  Section 7.3 respectively.) If this case happens, one of the programs
  must be renamed. The maintainers should report this to the
  debian-devel mailing list and try to find a consensus about which
  program will have to be renamed. If a consensus cannot be reached,
  both programs must be renamed.

While it says "install programs", it's clearly in practice irrelevant
whether this is by means of installing an executable file in /usr/bin or
by implementing a new built-in. A shell implementing a 'debconf' command
would be buggy (policy "must", and release-critically since something
similar is also in the release policy) if it did not have the same
functionality as the existing one, to whatever degree of accuracy is
appropriate for the case at hand.

You have to assume a grandfather clause for variation between existing
built-ins in shells to make this sane, but that seems perfectly in line
with the mention of alternatives in 10.1. In addition, shell built-ins
might reasonably be held to a very high standard of accuracy when
clashing with programs on the filesystem, since they effectively replace
programs on the filesystem for scripts interpreted by that shell without
the presence of a Conflicts:. However, all of that is essentially a
matter of interpretation of policy.

In the case of 'test', we are at liberty to choose the desired
interpretation. Since very substantial numbers of existing /bin/sh
scripts in Debian use the -a and -o primaries (including scripts on
users' machines, so we wouldn't want to delete this functionality from
existing shells either), forbidding them straight away is not a good
idea, but they could easily be declared deprecated in /bin/sh scripts.

I think my view is that the simplest approach is to rely on 10.1 to
dispose of the worst clashes and then explicitly specify deviations from
POSIX in controversial cases. This also happens to be in line with the
current approach taken by policy for echo(1).

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #335 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Colin Watson <cjwatson@debian.org>
Cc: 267142@bugs.debian.org, Clint Adams <schizo@debian.org>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 11 Sep 2004 02:01:48 -0700
Colin Watson <cjwatson@debian.org> writes:

> Why not forget about doing this in 10.4, and simply invoke 10.1?

I think you're on the right track here in identifying perhaps another
solution to the problem.  This might produce an option which is a
hybrid of ones on my list; something like the following.  Let me
rehearse it just to make sure I understand correctly.  We would say
somethnig like:

"Except for the following shell builtins, a Debian shell installed in
/bin/sh may not buildin any commands provided by packages of priority
Optional or higher, unless it does so in a way which is functionally
equivalent to the normal version."

And then we would list the historically relevant exceptions, like
test; that's the grandfather clause you describe.  Those would be
required to implement the Posix behavior, but would not be required to
implement additional behavior.

Now this is fine for the problem of shells which could override
arbitrary things; because this is a restriction on the shells in
/bin/sh, scripts are allowed to assume that the restriction is being
followed.  I also think it cuts the right line, which is not between
Posix utilities and other utilities, but rather between those we
choose to grandfather and those we do not.

This doesn't quite solve the whole problem however, because it allows
for variations in the grandfathered commands, and it doesn't say what
a script is allowed to assume there.  So we'll still need something
like a statement that a script may not rely on Posix extensions to any
of the commands where a shell can have a variant builtin. 

> In the case of 'test', we are at liberty to choose the desired
> interpretation. Since very substantial numbers of existing /bin/sh
> scripts in Debian use the -a and -o primaries (including scripts on
> users' machines, so we wouldn't want to delete this functionality from
> existing shells either), forbidding them straight away is not a good
> idea, but they could easily be declared deprecated in /bin/sh scripts.

The way to do this is to forbid them right away, but to make
compliance not release critical for a while.

> I think my view is that the simplest approach is to rely on 10.1 to
> dispose of the worst clashes and then explicitly specify deviations from
> POSIX in controversial cases. This also happens to be in line with the
> current approach taken by policy for echo(1).

I think this is an excellent proposal, the more I think about it.  Let
me sleep on it a bit, and if people have objections or see problems,
please let me know.  I think it eases up on the justifiable concerns
that many have with the list-of-shells approach; I preferred that only
because I didn't see any solution I like better, and I think I really
like this one.

So let me sleep on it a bit, and then I'll try writing exact text for
an amendment to Policy that will encapsulate this idea.

Some research is needed here too, to enumerate the list of builtins
that need to be grandfathered.  Can someone volunteer?

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #340 received at 267142@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>, 267142@bugs.debian.org
Cc: Clint Adams <schizo@debian.org>
Subject: Re: Bug#267142: huh?
Date: Sat, 11 Sep 2004 10:07:42 +0100
On Fri, Sep 10, 2004 at 09:49:34PM -0700, Thomas Bushnell BSG wrote:
> But my first reaction to the issue here is to simply depend on bash.
> If I were to fix the bug in question, I would not alter my use of test
> to comply with some foolish idea about what "looks better".  To me, -a
> looks better, because -a is typical for command arguments and "&&" is
> not.  "&&" looks like a freaky backgrounding command to me.  And in
> Version 7 Unix, -a was the only option, so it's really "&&" that is
> the freaky novelty.  To my eye, at least.

&& was perfectly well-supported in the v7 Unix shell. Of course it isn't
typical for command arguments; that's because it isn't a command
argument, but an operator for joining two pipelines together.

  $ unix-v7
  
  PDP-11 simulator V3.2-2
  Disabling XQ
  @boot
  New Boot, known devices are hp ht rk rl rp tm vt
  : rl(0,0)rl2unix
  mem = 177856
  # test -d bin; echo $?
  0
  # test -d nonexistent; echo $?
  1
  # test -d usr; echo $?
  0
  # test -d bin -a -d usr; echo $?
  0
  # test -d bin && test -d usr; echo $?
  0
  # test -d bin -a -d nonexistent; echo $?
  1
  # test -d bin && test -d nonexistent; echo $?
  1
  #

The Autoconf manual refers (Portable Shell / Limitations of Builtins) to
precedence problems on System V as the rationale for avoiding -a and -o.
I don't see how you can logically use the behaviour of Version 7 Unix as
justification for anything while overlooking System V.

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #345 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Colin Watson <cjwatson@debian.org>
Cc: 267142@bugs.debian.org, Clint Adams <schizo@debian.org>
Subject: Re: Bug#267142: huh?
Date: 11 Sep 2004 02:10:56 -0700
Colin Watson <cjwatson@debian.org> writes:

> && was perfectly well-supported in the v7 Unix shell. Of course it isn't
> typical for command arguments; that's because it isn't a command
> argument, but an operator for joining two pipelines together.

Um, but that's a totally different syntax.

<test foo && test bar> is not the same as <test foo "&&" bar>

They often behave the same, but they are still different expressions.

> The Autoconf manual refers (Portable Shell / Limitations of Builtins) to
> precedence problems on System V as the rationale for avoiding -a and -o.
> I don't see how you can logically use the behaviour of Version 7 Unix as
> justification for anything while overlooking System V.

Huh?  Version 7 is the basis for BSD; System V is not.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #350 received at 267142@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org, Clint Adams <schizo@debian.org>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 11 Sep 2004 10:32:02 +0100
On Sat, Sep 11, 2004 at 02:01:48AM -0700, Thomas Bushnell BSG wrote:
> Colin Watson <cjwatson@debian.org> writes:
> > Why not forget about doing this in 10.4, and simply invoke 10.1?
> 
> I think you're on the right track here in identifying perhaps another
> solution to the problem.  This might produce an option which is a
> hybrid of ones on my list; something like the following.  Let me
> rehearse it just to make sure I understand correctly.  We would say
> somethnig like:
> 
> "Except for the following shell builtins, a Debian shell installed in
> /bin/sh may not buildin any commands provided by packages of priority
> Optional or higher, unless it does so in a way which is functionally
> equivalent to the normal version."

I think I'd be inclined to avoid mentioning package priority at all
here; of late it's been quite weak, and I don't think we'd want bash
providing, say, scsh (which is extra) without some kind of notice.

Yes, this means that introducing new shell built-ins is difficult. It
doesn't mean that they can't be done, only that, per the language of
10.1, the shell maintainer has to go and talk to the maintainer of the
other package and to debian-devel and decide which one gets to keep the
name. I think that's exactly the behaviour we want.

I think the right language is something like:

  Except for the following shell builtins, additional commands provided
  by a Debian shell installed in /bin/sh shall be considered to have the
  same status as executables in the filesystem for the purpose of name
  conflicts with other packages. As a result, they must either provide
  the same functionality as the other program or else discuss with the
  other maintainer and debian-devel which one should be renamed.

> > In the case of 'test', we are at liberty to choose the desired
> > interpretation. Since very substantial numbers of existing /bin/sh
> > scripts in Debian use the -a and -o primaries (including scripts on
> > users' machines, so we wouldn't want to delete this functionality from
> > existing shells either), forbidding them straight away is not a good
> > idea, but they could easily be declared deprecated in /bin/sh scripts.
> 
> The way to do this is to forbid them right away, but to make
> compliance not release critical for a while.

test -a/-o isn't release-critical at the moment anyway.
Release-criticality is determined by the release managers, not the
policy manual, and this issue clearly isn't mature or agreed-upon yet
among developers nor does it cause widespread breakage for most users.

It is not "release-critical but ignored for sarge" either, as Clint
suggested. That status is reserved for a very limited class of bugs; the
only thing that comes to mind is DFSG-freeness of things other than
code, and that status implies that the issue will become
release-critical in the next release. test -a/-o is simply not
release-critical at all. Issues of shell policy will only become
release-critical when there's general agreement on the correct policy
decision and a clear strategy for fixing most of the conformance bugs in
a reasonable time. At that point, they will be documented in the release
policy.

The maintainers of the policy manual have always taken a similar
attitude, so forbidding it right away wouldn't happen; rather, it would
be a "should not" for the moment until general conformance is sorted
out.

> > I think my view is that the simplest approach is to rely on 10.1 to
> > dispose of the worst clashes and then explicitly specify deviations from
> > POSIX in controversial cases. This also happens to be in line with the
> > current approach taken by policy for echo(1).
> 
> I think this is an excellent proposal, the more I think about it.  Let
> me sleep on it a bit, and if people have objections or see problems,
> please let me know.  I think it eases up on the justifiable concerns
> that many have with the list-of-shells approach; I preferred that only
> because I didn't see any solution I like better, and I think I really
> like this one.

OK, glad it made sense. Early morning suggestions from me aren't always
coherent ...

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #355 received at 267142@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Thomas Bushnell BSG <tb@becket.net>
Cc: 267142@bugs.debian.org, Clint Adams <schizo@debian.org>
Subject: Re: Bug#267142: huh?
Date: Sat, 11 Sep 2004 10:37:04 +0100
On Sat, Sep 11, 2004 at 02:10:56AM -0700, Thomas Bushnell BSG wrote:
> Colin Watson <cjwatson@debian.org> writes:
> > && was perfectly well-supported in the v7 Unix shell. Of course it isn't
> > typical for command arguments; that's because it isn't a command
> > argument, but an operator for joining two pipelines together.
> 
> Um, but that's a totally different syntax.

Yes. I don't think Clint ever suggested that it wasn't ...

The binary 'and' and 'or' primitives available in test(1) aren't
portable, so using the alternatives provided natively in the shell is
common practice. While the syntax is different, it's not generally so
different that adapting existing scripts is painful.

> > The Autoconf manual refers (Portable Shell / Limitations of Builtins) to
> > precedence problems on System V as the rationale for avoiding -a and -o.
> > I don't see how you can logically use the behaviour of Version 7 Unix as
> > justification for anything while overlooking System V.
> 
> Huh?  Version 7 is the basis for BSD; System V is not.

Quite, but they're both about as relevant to the modern Debian system!
:-) (Take that as you will. Variants of both continue to exist in
production systems, and I'm pretty sure that there are still current
branches of Unix with the broken precedence of test's -a and -o
primaries. On the other hand, to a Debian-only purist neither matters.)

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #360 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Colin Watson <cjwatson@debian.org>
Cc: 267142@bugs.debian.org, Clint Adams <schizo@debian.org>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 11 Sep 2004 02:39:09 -0700
Colin Watson <cjwatson@debian.org> writes:

> I think I'd be inclined to avoid mentioning package priority at all
> here; of late it's been quite weak, and I don't think we'd want bash
> providing, say, scsh (which is extra) without some kind of notice.

Well, priority is our rule for this case.  

However, maybe I agree.  If you have two packages that provide the
same binary, you get notice when you try and install them.  But if
it's this kind of case with a builtin, then that isn't so.  So perhaps
you're right.

> Yes, this means that introducing new shell built-ins is difficult. It
> doesn't mean that they can't be done, only that, per the language of
> 10.1, the shell maintainer has to go and talk to the maintainer of the
> other package and to debian-devel and decide which one gets to keep the
> name. I think that's exactly the behaviour we want.

Agreed completely.

> test -a/-o isn't release-critical at the moment anyway.
> Release-criticality is determined by the release managers, not the
> policy manual, and this issue clearly isn't mature or agreed-upon yet
> among developers nor does it cause widespread breakage for most users.

Right.  My point is that policy doesn't need to say "this is
deprecated", it can just go ahead and prohibit it; bugs can be
appropriately filed (or not); and release managers can mandate
compliance with a given version of Policy or various sections at their
option.  Release-critical decisions of this sort should be made by
release managers, not by policy.

But that means that we don't need to worry about "deprecated" status
at all. :)

> The maintainers of the policy manual have always taken a similar
> attitude, so forbidding it right away wouldn't happen; rather, it would
> be a "should not" for the moment until general conformance is sorted
> out.

Yes, I'm happy to have "should not" rather than "must not" here; my
concern is to have the current situation fixed.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #365 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Colin Watson <cjwatson@debian.org>
Cc: 267142@bugs.debian.org, Clint Adams <schizo@debian.org>
Subject: Re: Bug#267142: huh?
Date: 11 Sep 2004 02:42:48 -0700
Colin Watson <cjwatson@debian.org> writes:

> (Take that as you will. Variants of both continue to exist in
> production systems, and I'm pretty sure that there are still current
> branches of Unix with the broken precedence of test's -a and -o
> primaries. On the other hand, to a Debian-only purist neither matters.)

I admit, I've never understood quite why the precedence is "broken"
here.

Perhaps I just use parentheses anyway with complex logical
expressions.

I find the shell syntax very broken, because it's weirdly right
associative, so I find using shell && and || freaky.  And then using
parens is nasty, because they create subshells and slow things down.
All this means that I have always hated shell && and || syntax.

And, concomitantly, I like the test syntax, because it maps exactly to
my model of the logical connectives.

As a philosopher, I insist that there is no natural precedence between
AND and OR, because each equally distributes over the other.  So an
expression like "p OR q AND r" is simply ambiguous.  So I always use
parens.

Thomas




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #370 received at 267142@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: debian-policy@lists.debian.org
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 11 Sep 2004 11:53:16 -0500
On Sat, 11 Sep 2004 09:47:42 +0100, Colin Watson <cjwatson@debian.org> said: 

> Why not forget about doing this in 10.4, and simply invoke 10.1?

>   Two different packages must not install programs with different
>   functionality but with the same filenames. (The case of two
>   programs having the same functionality but different
>   implementations is handled via "alternatives" or the "Conflicts"
>   mechanism. See Maintainer Scripts, Section 3.10 and Conflicting
>   binary packages - Conflicts, Section 7.3 respectively.) If this
>   case happens, one of the programs must be renamed. The maintainers
>   should report this to the debian-devel mailing list and try to
>   find a consensus about which program will have to be renamed. If a
>   consensus cannot be reached, both programs must be renamed.

> While it says "install programs", it's clearly in practice
> irrelevant whether this is by means of installing an executable file
> in /usr/bin or by implementing a new built-in. A shell implementing
> a 'debconf' command would be buggy (policy "must", and
> release-critically since something similar is also in the release
> policy) if it did not have the same functionality as the existing
> one, to whatever degree of accuracy is appropriate for the case at
> hand.

> You have to assume a grandfather clause for variation between
> existing built-ins in shells to make this sane, but that seems
> perfectly in line with the mention of alternatives in 10.1. In
> addition, shell built-ins might reasonably be held to a very high
> standard of accuracy when clashing with programs on the filesystem,
> since they effectively replace programs on the filesystem for
> scripts interpreted by that shell without the presence of a
> Conflicts:. However, all of that is essentially a matter of
> interpretation of policy.

> In the case of 'test', we are at liberty to choose the desired
> interpretation. Since very substantial numbers of existing /bin/sh
> scripts in Debian use the -a and -o primaries (including scripts on
> users' machines, so we wouldn't want to delete this functionality
> from existing shells either), forbidding them straight away is not a
> good idea, but they could easily be declared deprecated in /bin/sh
> scripts.

	I also think that this language supplied by Colin is the best
 bet so far. It does not require policy to specify and maintain a list
 of acceptable shells, it  does not require any new candidate to be
 bug-for-bug compatible with current lists of shells (as would have
 been needed for option 2). And, unlike option 1, it would still be
 possible for new candidates to be added to the system (requiring
 #!/bin/some-shell to be hard-coded in all scripts would make it
 impossible for a sysadmin to substitute a new shell, even if it would
 have otherwise worked).
----------------------------------------------------------------------
 10.1

  Except for the following shell builtins, additional commands provided
  by a Debian shell installed in /bin/sh shall be considered to have the
  same status as executables in the filesystem for the purpose of name
  conflicts with other packages. As a result, they must either provide
  the same functionality as the other program or else discuss with the
  other maintainer and debian-devel which one should be renamed.


Note:
A Posix-conformant shell is allowed to build in *anything*, and if
it's not a Posix-specified utility that's being built in, then it can
have *any behavior whatsoever*.  The presence of two commands with
conflicting behaviour adds an unacceptable uncertainty when scripts
are executed, and this has to be resolved.
----------------------------------------------------------------------

	If we have a rough consensus on this view, we can move ahead.

	manoj
-- 
"I got rid of my husband.  The cat was allergic."
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #375 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: debian-policy@lists.debian.org
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: 11 Sep 2004 10:00:53 -0700
Manoj Srivastava <srivasta@debian.org> writes:

> 	I also think that this language supplied by Colin is the best
>  bet so far. 

I'm glad to hear you agree.  Colin has done us all proud!

And I want to thank those who bore with me through all this
discussion; it seems to have produced a good result at the end, which
was what I hoped for all along.

> 	If we have a rough consensus on this view, we can move ahead.

What we do still need is the list of grandfathered builtins.

(Of course, if we get that list wrong, it's no disaster, because it's
easy to adjust it as necessary.)

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #380 received at 267142@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: debian-policy@lists.debian.org
Cc: 267142@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 11 Sep 2004 20:40:41 +0200
* Manoj Srivastava (srivasta@debian.org) [040911 19:10]:
> On Sat, 11 Sep 2004 09:47:42 +0100, Colin Watson <cjwatson@debian.org> said: 
> > Why not forget about doing this in 10.4, and simply invoke 10.1?
[...]
> 	If we have a rough consensus on this view, we can move ahead.

I think that's the best way to do it.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #385 received at 267142@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Clint Adams <schizo@debian.org>
Cc: 267142@bugs.debian.org, Thomas Bushnell BSG <tb@becket.net>
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 11 Sep 2004 15:23:55 +0200
On Thu, Sep 09, 2004 at 03:01:28PM -0400, Clint Adams wrote:
> > More generally shells that provide built-in with name conflicting 
> > with others basic programms in Debian should not be allowed for /bin/sh.
> > For example a shell with a 'ls' built-in.
> 
> Are you opposed to all shell builtins?

I am opposed to /bin/sh built-in whose name conflicting with programms
provided by Essential packages. /usr/bin/test is such a program, part
of coreutils.

When you explicitly call /bin/bash, you should know what built-in bash
provides and write your scripts accordingly. You would not be able to do
that for /bin/sh scripts.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information stored:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Hood <jdthood@aglu.demon.nl>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #390 received at 267142-quiet@bugs.debian.org (full text, mbox):

From: Thomas Hood <jdthood@aglu.demon.nl>
To: debian-policy@lists.debian.org
Cc: 267142-quiet@bugs.debian.org
Subject: Re: Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
Date: Sat, 30 Oct 2004 13:51:27 +0200
Thomas Bushnell writes:
> I find the shell syntax very broken, because it's weirdly right
> associative, so I find using shell && and || freaky.  And then using
> parens is nasty, because they create subshells and slow things down.


My understanding is that you can use braces to enforce scopes without
creating subshells.  Thus if you are worried about how the following
will behave:

   x && y || z

then you can do one of the following instead:

  { x && y ; } || z          x && { y || z ; }

-- 
Thomas Hood




Information stored:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Hood <jdthood@aglu.demon.nl>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #395 received at 267142-quiet@bugs.debian.org (full text, mbox):

From: Thomas Hood <jdthood@aglu.demon.nl>
To: debian-devel@lists.debian.org
Cc: 267142-quiet@bugs.debian.org
Subject: So will test be grandfathered?
Date: Sat, 30 Oct 2004 14:05:35 +0200
Manoj suggested this language for 10.1:
> ----------------------------------------------------------------------
>  10.1
> 
>   Except for the following shell builtins, additional commands provided
>   by a Debian shell installed in /bin/sh shall be considered to have the
>   same status as executables in the filesystem for the purpose of name
>   conflicts with other packages. As a result, they must either provide
>   the same functionality as the other program or else discuss with the
>   other maintainer and debian-devel which one should be renamed.
> 
> 
> Note:
> A Posix-conformant shell is allowed to build in *anything*, and if
> it's not a Posix-specified utility that's being built in, then it can
> have *any behavior whatsoever*.  The presence of two commands with
> conflicting behaviour adds an unacceptable uncertainty when scripts
> are executed, and this has to be resolved.
> ----------------------------------------------------------------------


Thomas Bushnell BSG <tb@becket.net> wrote:
> What we do still need is the list of grandfathered builtins.


While we wait for the official list, can we at least assume that "test"
will be grandfathered, and consequently that "-a" and "-o" should be
avoided?

-- 
Thomas Hood




Information stored:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Hood <jdthood@aglu.demon.nl>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #400 received at 267142-quiet@bugs.debian.org (full text, mbox):

From: Thomas Hood <jdthood@aglu.demon.nl>
To: debian-policy@lists.debian.org
Cc: 267142-quiet@bugs.debian.org
Subject: Re: So will test be grandfathered?
Date: Mon, 01 Nov 2004 08:57:26 +0100
On Mon, 2004-11-01 at 01:09, Thomas Bushnell BSG wrote:
> Rather, what we need is someone (do I hear you volunteering?) to
> prepare a good list of builtins that should be grandfathered.


OK, I'll start it.

    List of builtins exempt from ramified 10.1
    ------------------------------------------
    test   

The reason for putting "test" on the list is that "test" is implemented
differently in different shells.  It was alleged that different "test"
builtins have different precedence rules for their logical connectives,
although I have seen no demonstration of this for the shells that Debian
ships.  Also, posh's "test" builtin lacks "-a" and "-o" entirely.  (It
was suggested that posh's "test" builtin either be changed to support
"-a" and "-o" or be eliminated entirely; however posh's maintainer
rejected this idea and it was described by someone else as "nutso".)

-- 
Thomas Hood




Information stored:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Bushnell BSG <tb@becket.net>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #405 received at 267142-quiet@bugs.debian.org (full text, mbox):

From: Thomas Bushnell BSG <tb@becket.net>
To: Thomas Hood <jdthood@aglu.demon.nl>
Cc: debian-policy@lists.debian.org, 267142-quiet@bugs.debian.org
Subject: Re: So will test be grandfathered?
Date: 01 Nov 2004 14:01:33 -0800
Thomas Hood <jdthood@aglu.demon.nl> writes:

> OK, I'll start it.

Um, well, I mean the hard work, which means looking through the shells
we care about (and making some judgment about which ones we care
about), seeing what they build in, and seeing whether they disagree
with the standard binaries in Debian.

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#267142; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Thomas Hood <jdthood@aglu.demon.nl>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #410 received at 267142@bugs.debian.org (full text, mbox):

From: Thomas Hood <jdthood@aglu.demon.nl>
To: 267142@bugs.debian.org
Subject: posh not a /bin/sh candidate
Date: Mon, 01 Aug 2005 10:28:03 +0200
Several DDs have said that they plan to continue to use "test -a"
and "test -o" in /bin/sh scripts.  Given this fact, it is necessary
for reliability that all shells that are /bin/sh candidates either
refrain from implementing a "test" builtin or else implement a
"test" builtin compatible with /usr/bin/test.

In other words, "test" cannot be "grandfathered" --- it cannot be
treated as an exception to the rule that shells should implement
builtins in mutually compatible ways.  (Such exceptions have to be
dealt with by scripts not using the options that behave differently
among shells, and/or by specifying a particular shell in the shebang.)

The only shell I know of that implements "test" incompatibly
with /usr/bin/test is posh.  (It has been alleged that different
shells have different precedence rules for the logical connective
options of "test", but no one has yet shown that any of the Debian
shells is different from the others.)  The maintainer of posh
refuses to consider his shell's deviance as a bug; so the conclusion
must be drawn that "posh" is not a practical /bin/sh candidate.
-- 
Thomas Hood



Severity set to `wishlist'. Request was from Manoj Srivastava <srivasta@golden-gryphon.com> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Manoj Srivastava <srivasta@golden-gryphon.com> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title to `Specify allowable behavior for /bin/sh shell builtins' from `[DISCUSS] Sections 10.4 and 6.1 are inconsistent'. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Mon, 17 Mar 2008 05:24:18 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 15:20:46 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.