On Thu, Oct 21, 1999 at 08:50:42PM +0200, Joost Kooij wrote:
> On Fri, 22 Oct 1999, Anthony Towns wrote:
> > Then the Single Unix Specification is broken, and we shouldn't follow
> > it. Seriously, -e and -n are expected features of echo on GNU/Linux
> > systems, no matter what the Single Unix Spec might or might not say.
> In any case we need some standardisation on "echo" behaviour.
> - should echo understand options?
> - should echo default to interpret escaped characters?
> - what escape characters are there and what is their interpretation?
First, for general portability, you can't rely on echo doing anything
at all sane with options (some support no options, some support some
options, some even support long options: /bin/echo --help; and echo
--help give markedly different results, eg) or escape codes (GNU echo
(/bin/echo on Debian) always interprets escapes unless you specify -E,
bash only does them if you specify -e, and so on).
So we're not going to make shell scripts more portable by conforming to
either way, really. echo is all over the place.
However, for GNU/Linux systems, echo usually does support -e and -n, and
while it varies whether you'll get escape codes interpreted without -e,
you'll always get them with -e, and -n always works.
> > Dropping them shortly before freeze seems an insane thing to do too,
> > fwiw.
> Can achieving consistency across all echo implementations be harmful to
> the pending release?
Depends which consistency we achieve. Consider:
[aj@azure ~]$ grep -l 'echo -[en]' /var/lib/dpkg/info/*.{pre,post}{inst,rm} | wc -l
81
[aj@azure ~]$ grep -l 'echo -[en]' /etc/init.d/* | wc -l
48
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP 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
Attachment:
pgpjIq1ily71d.pgp
Description: PGP signature