Debian Bug report logs - #48247
[AMMENDMENT 29/10/99] /bin/sh needs echo -n

Toggle useless messages

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

From: Raul Miller <moth@debian.org>

To: submit@bugs.debian.org

Subject: echo -n

Date: Sun, 24 Oct 1999 23:51:20 -0400

Package: debian-policy
Version: 3.0.1.1
Severity: wishlist

I'm tired of defending the current situation where debian policy specifies
POSIX behavior for /bin/sh, but echo -n has widespread use in the Linux
community (including especially debian policy, the linux kernel source,
many debian scripts, etc.).  This echo -n mechanism is valid but not
required under POSIX, and rather than change the world I think it's
easier to change policy.

*** policy.sgml.orig	Sun Oct 24 23:38:33 1999
--- policy.sgml	Sun Oct 24 23:48:16 1999
***************
*** 2218,2224 ****
  	    
  	  <p>
  	    The standard shell interpreter `<tt>/bin/sh</tt>' may be a
! 	    symbolic link to any POSIX compatible shell. Thus, shell
  	    scripts specifying `<tt>/bin/sh</tt>' as interpreter may
  	    only use POSIX features. If a script requires non-POSIX
  	    features from the shell interpreter, the appropriate shell
--- 2218,2225 ----
  	    
  	  <p>
  	    The standard shell interpreter `<tt>/bin/sh</tt>' may be a
! 	    symbolic link to any POSIX compatible shell, if <tt>echo
! 	    -n</tt> does not generate a newline. Thus, shell
  	    scripts specifying `<tt>/bin/sh</tt>' as interpreter may
  	    only use POSIX features. If a script requires non-POSIX
  	    features from the shell interpreter, the appropriate shell



-- 
Raul

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

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Raul Miller <moth@debian.org>, 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 14:31:42 +1000

Raul Miller <moth@debian.org> wrote:
> Package: debian-policy
> Version: 3.0.1.1
> Severity: wishlist

> I'm tired of defending the current situation where debian policy specifies
> POSIX behavior for /bin/sh, but echo -n has widespread use in the Linux
> community (including especially debian policy, the linux kernel source,
> many debian scripts, etc.).  This echo -n mechanism is valid but not
> required under POSIX, and rather than change the world I think it's
> easier to change policy.

What about escape codes, do we require them or do we forbid them?
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

From: Raul Miller <moth@debian.org>

To: Herbert Xu <herbert@gondor.apana.org.au>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 00:50:56 -0400

On Mon, Oct 25, 1999 at 02:31:42PM +1000, Herbert Xu wrote:
> What about escape codes, do we require them or do we forbid them?

I think it would be a bad idea to make any recommendations on 
escape codes in debian policy:

(1) We don't use them.
(2) In almost all examples we don't care if they're supported or not.
(3) POSIX already says enough about escape codes.

As it happens, neither bash nor ash support them, while zsh does.
Both variants are reasonable.

-- 
Raul

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

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Raul Miller <moth@debian.org>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 14:54:00 +1000

On Mon, Oct 25, 1999 at 12:50:56AM -0400, Raul Miller wrote:
> On Mon, Oct 25, 1999 at 02:31:42PM +1000, Herbert Xu wrote:
> > What about escape codes, do we require them or do we forbid them?
> 
> I think it would be a bad idea to make any recommendations on 
> escape codes in debian policy:
> 
> (1) We don't use them.
> (2) In almost all examples we don't care if they're supported or not.
> (3) POSIX already says enough about escape codes.
> 
> As it happens, neither bash nor ash support them, while zsh does.
> Both variants are reasonable.

When I said escape codes, I really meant the scripts that currently
use them with/without -e.  So with your current modification to the
policy, escape codes are no longer allowed in any #!/bin/sh script.
Remember the kernel source uses -e in just as many places as it
uses -n.

Currently bash and ash supports -e in violation to POSIX.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

From: Raul Miller <moth@debian.org>

To: Herbert Xu <herbert@gondor.apana.org.au>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 01:27:16 -0400

On Mon, Oct 25, 1999 at 02:54:00PM +1000, Herbert Xu wrote:
> When I said escape codes, I really meant the scripts that currently
> use them with/without -e.  So with your current modification to the
> policy, escape codes are no longer allowed in any #!/bin/sh script.
> Remember the kernel source uses -e in just as many places as it
> uses -n.

Argh, so it does.

> Currently bash and ash supports -e in violation to POSIX.

Yup, so we have a legacy issue.

Happy happy joy joy.

-- 
Raul

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

From: Raul Miller <moth@debian.org>

To: Herbert Xu <herbert@gondor.apana.org.au>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 01:36:26 -0400

On Mon, Oct 25, 1999 at 02:54:00PM +1000, Herbert Xu wrote:
> Currently bash and ash supports -e in violation to POSIX.

Rereading my copy of chapter 4.19 of the POSIX 1003.2 draft:

<quote>
 4.19.3  Options

 The echo utility shall not recognize the -- argument in the manner
 specified by utility syntax guideline 10 in 2.10.2; -- shall be
 recognized as a string operand.

 Implementations need not support any options.
</quote>

I see nothing here that forbids supporting -e

So I recommend that any shells which have historically supported -e
continue to do so, but that debian policy make no explicit mention
of this issue.

If you see any text in the published standard which contradicts the above,
please quote it.

Thanks,

-- 
Raul

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

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Raul Miller <moth@debian.org>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 15:48:03 +1000

On Mon, Oct 25, 1999 at 01:36:26AM -0400, Raul Miller wrote:
> 
> Rereading my copy of chapter 4.19 of the POSIX 1003.2 draft:
> 
> <quote>
>  4.19.3  Options
> 
>  The echo utility shall not recognize the -- argument in the manner
>  specified by utility syntax guideline 10 in 2.10.2; -- shall be
>  recognized as a string operand.
> 
>  Implementations need not support any options.
> </quote>
> 
> I see nothing here that forbids supporting -e

OK, POSIX actually sanctions the use of -e *if* the string to echo
contains back slashes.  But it is not because of the above bit,
since it is overridden by this:

 4.19.4  Operands

 The following operands shall be supported by the implementation:

    string      A string to be written to standard output.  If the first
                operand is "-n" or if any of the operands contain a
                backslash (\) character, the results are implementation
                defined.

So echo -e '\007' is allowed to just beep, but echo -e 'hello' must
produce

-e hello

In this respect, both ash and bash are still in violation.

> So I recommend that any shells which have historically supported -e
> continue to do so, but that debian policy make no explicit mention
> of this issue.

If the policy is to make no further mention of -e and escape codes,
then we need to start fixing all shell scripts using them.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

From: Raul Miller <moth@debian.org>

To: Herbert Xu <herbert@gondor.apana.org.au>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 02:44:57 -0400

On Mon, Oct 25, 1999 at 01:36:26AM -0400, Raul Miller wrote:
> > Rereading my copy of chapter 4.19 of the POSIX 1003.2 draft:
> > 
> > <quote>
> >  4.19.3  Options
> > 
> >  The echo utility shall not recognize the -- argument in the manner
> >  specified by utility syntax guideline 10 in 2.10.2; -- shall be
> >  recognized as a string operand.
> > 
> >  Implementations need not support any options.
> > </quote>
> > 
> > I see nothing here that forbids supporting -e

On Mon, Oct 25, 1999 at 03:48:03PM +1000, Herbert Xu wrote:
> OK, POSIX actually sanctions the use of -e *if* the string to echo
> contains back slashes.  But it is not because of the above bit,
> since it is overridden by this:
...

None of the text you quoted forbids supporting -e without backslashes.


There's a very big difference between what POSIX says: 

	"Implementations need not support any options"

and what you're saying, which seems to be something along the lines of:

	"any option not ennumerated by POSIX must not be implemented"

-- 
Raul

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

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Raul Miller <moth@debian.org>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 16:51:42 +1000

On Mon, Oct 25, 1999 at 02:44:57AM -0400, Raul Miller wrote:
> 
> None of the text you quoted forbids supporting -e without backslashes.

IMHO it does.  Firstly it's clear from the wording that all "options"
come under the operands category.  So unless you've got -n as the very first
operand or you've got baskslashes, echo must print the operands verbatim.

Anyway, this is all moot as unless you change our policy to list the exception
about -e and escape codes, we'll still have to change all #!/bin/sh scripts
that use them.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

From: Raul Miller <moth@debian.org>

To: Herbert Xu <herbert@gondor.apana.org.au>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 03:03:34 -0400

On Mon, Oct 25, 1999 at 04:51:42PM +1000, Herbert Xu wrote:
> IMHO it does. Firstly it's clear from the wording that all "options"
> come under the operands category.

It's clear from the wording that only for the -- option is this behavior
guaranteed.

-- 
Raul

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

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Raul Miller <moth@debian.org>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 21:08:51 +1000

On Mon, Oct 25, 1999 at 03:03:34AM -0400, Raul Miller wrote:
> On Mon, Oct 25, 1999 at 04:51:42PM +1000, Herbert Xu wrote:
> > IMHO it does. Firstly it's clear from the wording that all "options"
> > come under the operands category.
> 
> It's clear from the wording that only for the -- option is this behavior
> guaranteed.

Let me quote it again:

 4.19.1  Synopsis

 echo  [string ...]

<...deleted...>

 4.19.4  Operands

 The following operands shall be supported by the implementation:

    string      A string to be written to standard output.  If the first
                operand is "-n" or if any of the operands contain a
                backslash (\) character, the results are implementation
                defined.

 4.19.6.1  Standard Output

 The echo utility arguments shall be separated by single <space>s and a
 <newline> character shall follow the last argument.

So, unless the first operand is -n, or if the string contains backslash
characters, the operands are to be written to the standard output verbatim
separated by sngle spaces with a new line at the end.  If the first operand
is -n, or if there are backslash characters, anything can happen.

Applying this to the case

echo -e hello

the first operand is not -n and there are no backslashes, so the output must
be

-e hello
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

From: Raul Miller <moth@debian.org>

To: Herbert Xu <herbert@gondor.apana.org.au>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 07:24:59 -0400

On Mon, Oct 25, 1999 at 09:08:51PM +1000, Herbert Xu wrote:
> So, unless the first operand is -n, or if the string contains backslash
> characters, the operands are to be written to the standard output verbatim
> separated by sngle spaces with a new line at the end.  If the first operand
> is -n, or if there are backslash characters, anything can happen.
> 
> Applying this to the case
> 
> echo -e hello
> 
> the first operand is not -n and there are no backslashes, so the output must
> be
> 
> -e hello

Except you elected to not quote what posix said about options:

<quote>
 4.19.3  Options

 The echo utility shall not recognize the -- argument in the manner
 specified by utility syntax guideline 10 in 2.10.2; -- shall be
 recognized as a string operand.

 Implementations need not support any options.
</quote>

So the interpretation you're suggesting is *legal* for a POSIX
implementation of /bin/sh, but it's fairly clear that it's not
*required* for a POSIX implementation of /bin/sh

It's fairly clear from 2.10.1 that options are not operands.  [Also note
the parts of 2.10.2 which were not explicitly superceeded in 4.19.]

If options are forbidden by posix it's reasonable to expect that
the command must support their treatment as operands.  However
when they're merely not required it's reasonable for that to vary
from one system to another.

-- 
Raul

Message #65 received at 48247@bugs.debian.org (full text, mbox, reply):

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Raul Miller <moth@debian.org>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 22:06:24 +1000

Let me state once again, this has no bearing whatsoever over the proposed
change in policy and my question about whether escape codes/-e are to be
mentioned or not.  It is for purely pendantic value.

On Mon, Oct 25, 1999 at 07:24:59AM -0400, Raul Miller wrote:
> Except you elected to not quote what posix said about options:
> 
> <quote>
>  4.19.3  Options
> 
>  The echo utility shall not recognize the -- argument in the manner
>  specified by utility syntax guideline 10 in 2.10.2; -- shall be
>  recognized as a string operand.
> 
>  Implementations need not support any options.
> </quote>

The last line is a big vague, but I don't see how this allows options:

Firstly the synopsis:

 echo  [string ...]

2.10.1 says that this means that everything that comes after echo are
operands, no options at all.

Then if you go down to the rationale of echo, the fact that the line in the
Options section does not imply that options that change the behaviour of
echo are permitted becomes a lot clearer:

 The echo utility does not support utility syntax guideline 10 because
 existing applications depend on echo to echo all of its arguments, except
 for the -n option in the BSD version.

So that means the intent here is to enforce all conforming implementations of
echo to echo all its arguments unless the first operand is -n.  This is
exactly what the Operands section says.

> So the interpretation you're suggesting is *legal* for a POSIX
> implementation of /bin/sh, but it's fairly clear that it's not
> *required* for a POSIX implementation of /bin/sh

I believe it's required.  Please check with the relevant authorities.

> It's fairly clear from 2.10.1 that options are not operands.  [Also note
> the parts of 2.10.2 which were not explicitly superceeded in 4.19.]

The synopsis and the Operands section indicate otherwise.  The guidelines
certainly does not imply that options are permitted in this case.  In any
case, the guidelines only have "should" and not "shall" unless the utility
claims conformance to those guidelines, which echo does not.

> If options are forbidden by posix it's reasonable to expect that
> the command must support their treatment as operands.  However
> when they're merely not required it's reasonable for that to vary
> from one system to another.

My reading of it is that options are forbidden.  However, if the first operand
is -n or there are backslashes, anything can occur.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

From: Raul Miller <moth@debian.org>

To: Herbert Xu <herbert@gondor.apana.org.au>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 20:09:13 -0400

On Mon, Oct 25, 1999 at 10:06:24PM +1000, Herbert Xu wrote:
> Let me state once again, this has no bearing whatsoever over the proposed
> change in policy and my question about whether escape codes/-e are to be
> mentioned or not.  It is for purely pendantic value.

I think it's an important point, because getting it wrong would have
all sorts of nasty implications.

> Firstly the synopsis:
> 
>  echo  [string ...]
> 
> 2.10.1 says that this means that everything that comes after echo are
> operands, no options at all.

Not precisely -- it means that there are no options required
by POSIX.

If we went with your interpretation, it would violate POSIX to
provide any options for a command which weren't present in the
POSIX synopsis.

Thus, for example, bash could not be an implementation of a 
POSIX shell unless it discards support for -b, -h, -k, -m,
-o, -p, -t, -B, -H, and -P

-- 
Raul

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

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Raul Miller <moth@debian.org>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Tue, 26 Oct 1999 10:11:50 +1000

On Mon, Oct 25, 1999 at 08:09:13PM -0400, Raul Miller wrote:
> On Mon, Oct 25, 1999 at 10:06:24PM +1000, Herbert Xu wrote:
> > Let me state once again, this has no bearing whatsoever over the proposed
> > change in policy and my question about whether escape codes/-e are to be
> > mentioned or not.  It is for purely pendantic value.
> 
> I think it's an important point, because getting it wrong would have
> all sorts of nasty implications.

But do you agree that with your current proposal, you still have to fix all
scripts that use -e/escape codes?

> Not precisely -- it means that there are no options required
> by POSIX.
> 
> If we went with your interpretation, it would violate POSIX to
> provide any options for a command which weren't present in the
> POSIX synopsis.

I would agree with you on this point for anything but echo.  I don't think
this reasoning applies here given what's in the Operands section and what
the rationale is.  It seems to be clear to me that the intention was to not
allow any options, i.e., to make sure that all implementations of echo echo
all of its arguments unless the first operand was -n.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Message #78 received at 48247-submitter@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: 43529-submitter@bugs.debian.org, 26995-submitter@bugs.debian.org, 33076-submitter@bugs.debian.org, 34610-submitter@bugs.debian.org, 35510-submitter@bugs.debian.org, 37254-submitter@bugs.debian.org, 39831-submitter@bugs.debian.org, 41829-submitter@bugs.debian.org, 41902-submitter@bugs.debian.org, 42052-submitter@bugs.debian.org, 42358-submitter@bugs.debian.org, 42477-submitter@bugs.debian.org, 42907-submitter@bugs.debian.org, 43483-submitter@bugs.debian.org, 43651-submitter@bugs.debian.org, 43724-submitter@bugs.debian.org, 43757-submitter@bugs.debian.org, 43928-submitter@bugs.debian.org, 44922-submitter@bugs.debian.org, 45318-submitter@bugs.debian.org, 46516-submitter@bugs.debian.org, 46522-submitter@bugs.debian.org, 47438-submitter@bugs.debian.org, 48045-submitter@bugs.debian.org, 13353-submitter@bugs.debian.org, 32263-submitter@bugs.debian.org, 37999-submitter@bugs.debian.org, 38703-submitter@bugs.debian.org, 39299-submitter@bugs.debian.org, 39398-submitter@bugs.debian.org, 39830-submitter@bugs.debian.org, 40742-submitter@bugs.debian.org, 40766-submitter@bugs.debian.org, 40767-submitter@bugs.debian.org, 40934-submitter@bugs.debian.org, 41113-submitter@bugs.debian.org, 41121-submitter@bugs.debian.org, 41729-submitter@bugs.debian.org, 42554-submitter@bugs.debian.org, 42870-submitter@bugs.debian.org, 43077-submitter@bugs.debian.org, 45307-submitter@bugs.debian.org, 45406-submitter@bugs.debian.org, 45561-submitter@bugs.debian.org, 48247-submitter@bugs.debian.org

Subject: Your policy proposal

Date: Tue, 26 Oct 1999 01:33:10 +0100 (BST)

You have submitted a proposed modification to the Debian Policy.  I
would be most grateful if you could check on the status of your
proposal (at http://www.debian.org/Bugs/db/pa/ldebian-policy.html) and
change the title/severity/forwarded status to indicate its present
status, in anticipation of a forthcoming policy revision.

Instructions on the scheme used can be found in
/usr/doc/debian-policy/proposal.text.gz if you are using a new policy
package, and if not, then check out
http://www.debian.org/~srivasta/policy/.

To change the status of a report in the BTS, email
control@bugs.debian.org with one or more lines like the following:
retitle 12345 [ACCEPTED 10/10/99] Allow foobar in section 9.9.9
forwarded 12345 debian-policy@lists.debian.org
severity 12345 normal

You can finish the list of commands with the line:
thanks

Thanks for the help!

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg

Message #83 received at 48247@bugs.debian.org (full text, mbox, reply):

From: Raul Miller <moth@debian.org>

To: Herbert Xu <herbert@gondor.apana.org.au>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Mon, 25 Oct 1999 22:12:03 -0400

On Mon, Oct 25, 1999 at 10:06:24PM +1000, Herbert Xu wrote:
> > > Let me state once again, this has no bearing whatsoever over the proposed
> > > change in policy and my question about whether escape codes/-e are to be
> > > mentioned or not.  It is for purely pendantic value.

On Mon, Oct 25, 1999 at 08:09:13PM -0400, Raul Miller wrote:
> > I think it's an important point, because getting it wrong would have
> > all sorts of nasty implications.

On Tue, Oct 26, 1999 at 10:11:50AM +1000, Herbert Xu wrote:
> But do you agree that with your current proposal, you still have to fix all
> scripts that use -e/escape codes?

Like I said before, I don't think this issue is relevant to debian
policy.  People can fix them, or not, depending on circumstances.

> > Not precisely -- it means that there are no options required
> > by POSIX.
> > 
> > If we went with your interpretation, it would violate POSIX to
> > provide any options for a command which weren't present in the
> > POSIX synopsis.
> 
> I would agree with you on this point for anything but echo.  I don't think
> this reasoning applies here given what's in the Operands section and what
> the rationale is.  It seems to be clear to me that the intention was to not
> allow any options, i.e., to make sure that all implementations of echo echo
> all of its arguments unless the first operand was -n.

I would agree with you on this point except that's not what POSIX says.

-- 
Raul

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

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Raul Miller <moth@debian.org>

Cc: 48247@bugs.debian.org

Subject: Re: Bug#48247: echo -n

Date: Tue, 26 Oct 1999 12:19:18 +1000

On Mon, Oct 25, 1999 at 10:12:03PM -0400, Raul Miller wrote:
> 
> On Tue, Oct 26, 1999 at 10:11:50AM +1000, Herbert Xu wrote:
> > But do you agree that with your current proposal, you still have to fix all
> > scripts that use -e/escape codes?
> 
> Like I said before, I don't think this issue is relevant to debian
> policy.  People can fix them, or not, depending on circumstances.

OK, so basically what you're saying is you won't object to me filing reports
against packages that use echo -e/escape codes in #!/bin/sh scripts.  In that
case, I hope that by the time we do the next release after potato, we will
have got rid of all -e/escape codes in Debian.

PS Here are a few packages that use -e/escape codes in #!/bin/sh scripts:
bison, debianutils, dpkg, kbd, libc6, login, util-linux.  I found these just
by grepping pre*/post* scripts.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

From: Alexander Koch <efraim@argh.org>

To: 48247@bugs.debian.org

Subject: echo -n things

Date: Wed, 27 Oct 1999 07:41:52 +0000

I second that proposal. About the escape codes I do not
know what to do (you have to sort it out), but the echo -n
is used too often and Herbert Xu wanted either a policy
change or put it out after potato is released, iirc.

So for such arghful things, I second this proposal.

scnr,
Alexander

-- 
Alexander Koch - <>< - WWJD - aka Efraim - PGP 0xE7694969 - ARGH-RIPE

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

From: Joost Kooij <joost@pc47.mpn.cp.philips.com>

To: Eric Weigel <ericw@bestnet.org>

Cc: 48247@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: [PATCH] latest ash has broken 'echo' command

Date: Wed, 27 Oct 1999 16:30:07 +0200 (CEST)

Hi,

On Tue, 26 Oct 1999, Eric Weigel wrote:

> >From Debian Policy Manual, version 3.0.1.1, 1999-08-16:
> 
> 4.4 Scripts
> 
>  ...
> 
>  The standard shell interpreter `/bin/sh' may be a symbolic link to any
>  POSIX compatible shell. Thus, shell scripts specifying `/bin/sh' as
>  interpreter may only use POSIX features. 
                            ^^^^^^^^^^^^^^
Policy has unclear wording here.  It should either mention:
                "system features mandated by POSIX"
or
                "system features allowed by POSIX"

>                                           If a script requires
>  non-POSIX features from the shell interpreter, the appropriate shell
   ^^^^^^^^^^^^^^^^^^
The same here:  
  "system features disallowed by POSIX"
or
  "system features not mandated by POSIX"

>  has to be specified in the first line of the script (e.g.,
>  `#!/bin/bash') and the package has to depend on the package providing
>  the shell (unless the shell package is marked `Essential', e.g., in
>  the case of bash).
> 
>  Restrict your script to POSIX features when possible so that it may
                           ^^^^^^^^^^^^^^
The same here:  
                 "system features mandated by POSIX"
or
                 "system features allowed by POSIX"

>  use /bin/sh as its interpreter. If your script works with ash, it's
>  probably POSIX compliant, but if you are in doubt, use /bin/bash.

This is unnecessarily vague too.  Ash is not the criterium here, POSIX
is.  

Also, if in doubt, don't resort to bash immediately, check POSIX first.
Generally it is better to remove bashisms from #!/bin/sh scripts if you
can, than to shoot a flea with the #!/bin/bash cannon.
 
> Now, I haven't read Posix, but it's pretty clear the intent of Debian
> Policy is that /bin/sh should support echo -n, because otherwise all of
> the Policy examples are wrong, as is /etc/init.d/skeleton (it uses echo
> -n), and who knows how many other scripts on the system will break.

Well, maybe all the examples are just wrong..

> I punched in a command to search my system for /bin/sh scripts which
> use echo -n, and what package they come from:
 
At a glance, I estimate more than 2/3 of these to be Debian native
scripts! (and you did not even include /var/lib/dpkg/info in the search.)

Maybe it would not be so unreasonable after all for Debian to become more
strict in the adaptation of POSIX definitions.

Cheers,


Joost

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

From: Raul Miller <moth@debian.org>

To: Joost Kooij <joost@pc47.mpn.cp.philips.com>

Cc: Eric Weigel <ericw@bestnet.org>, 48247@bugs.debian.org

Subject: Re: [PATCH] latest ash has broken 'echo' command

Date: Wed, 27 Oct 1999 11:50:41 -0400

[I've chosen to Bcc: debian-devel because the debian-devel side of
this thread is getting out of hand.]

On Wed, Oct 27, 1999 at 04:30:07PM +0200, Joost Kooij wrote:
> >                                           If a script requires
> >  non-POSIX features from the shell interpreter, the appropriate shell
>    ^^^^^^^^^^^^^^^^^^
> The same here:  
>   "system features disallowed by POSIX"
> or
>   "system features not mandated by POSIX"

Note that some POSIX allowed features conflict with other POSIX
allowed features.  So addressing the core issue is not quite this easy.

Personally, I think the proposed policy change (Bug #48247) adequately
solves the immediate problem.

-- 
Raul

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

From: Joseph Carter <knghtbrd@debian.org>

To: Raul Miller <moth@debian.org>

Cc: 48247@bugs.debian.org

Subject: Re: second on echo -n?

Date: Fri, 29 Oct 1999 07:24:22 -0700

[Message part 1 (text/plain, inline)]

On Fri, Oct 29, 1999 at 09:13:35AM -0400, Raul Miller wrote:
> I thought I remembered seeing a second from you on the echo -n policy
> proposal.
> 
> However, looking at http://www.debian.org/Bugs/db/48/48247.html,
> I don't see it.
> 
> If you meant to second this proposal, could I get you to email
> it to 48247@bugs.debian.org?

Consider this it.  =>

-- 
- Joseph Carter         GnuPG public key:   1024D/DCF9DAB3, 2048g/3F9C2A43
- knghtbrd@debian.org   20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
--------------------------------------------------------------------------
0 7     * * *   echo "...Linux is just a fad" | mail billg@microsoft.com -s "And remember..."

[Message part 2 (application/pgp-signature, inline)]

Message #117 received at 48247@bugs.debian.org (full text, mbox, reply):

From: Anthony Towns <aj@azure.humbug.org.au>

To: debian-policy@lists.debian.org

Cc: 48247@bugs.debian.org

Subject: Re: weekly policy summary

Date: Wed, 8 Dec 1999 20:59:58 +1000

[Message part 1 (text/plain, inline)]

On Fri, Dec 03, 1999 at 08:36:51PM -0800, Joseph Carter wrote:
> > Echo -n (#48247)
> >   * Under discussion.
> >   * Proposed by Raul Miller; seconded by Joseph Carter.
> >   * Amend policy to say /bin/sh must be a POSIX shell, but with the
> >     addition that "echo -n" must not generate a newline.
> This needs more seconds.  We already do require -n, we just don't say we
> do.  Since this proposal documents existing behavior, it probably should
> get into policy.  Does nobody else agree with me?

LSB will be mandating this, so if we want to be LSB compliant, we'll
do it. Adding it to -policy seems a bit redundant.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

[Message part 2 (application/pgp-signature, inline)]

Message #124 received at 48247-done@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: 46522-done@bugs.debian.org, 48247-done@bugs.debian.org, 50832-done@bugs.debian.org, 53759-done@bugs.debian.org, 58759-done@bugs.debian.org, 61308-done@bugs.debian.org, 62668-done@bugs.debian.org, 62946-done@bugs.debian.org, 62947-done@bugs.debian.org, 62948-done@bugs.debian.org, 64004-done@bugs.debian.org, 64006-done@bugs.debian.org, 64437-done@bugs.debian.org, 64516-done@bugs.debian.org, 69031-done@bugs.debian.org, 69424-done@bugs.debian.org, 69426-done@bugs.debian.org, 69487-done@bugs.debian.org, 69670-done@bugs.debian.org

Cc: Manoj Srivastava <srivasta@debian.org>

Subject: Closed in debian-policy 3.2.1.0

Date: Mon, 28 Aug 2000 12:28:04 +0100

Thanks to Manoj for closing all of these bugs in debian-policy version
3.2.1.0.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Send a report that this bug log contains spam.