Re: dash bug which is affecting release goal
John H. Robinson, IV writes (Re: dash bug which is affecting release goal):
Pierre Habouzit wrote:
echo() { /bin/echo $@ }
echo() { /bin/echo ${1+$@}; }
I believe you mean.
Why ?!
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
John H. Robinson, IV writes (Re: dash bug which is affecting release goal):
Pierre Habouzit wrote:
echo() { /bin/echo $@ }
echo() { /bin/echo ${1+$@}; }
I believe you mean.
Why ?!
Because stand-alone $@ is undefined when used in this case. By using ${1
+$@}, it is ensured that $@ always starts with $1.
What a load of POSIX.
William
signature.asc
Description: This is a digitally signed message part
Re: dash bug which is affecting release goal
On Sun, 2008-02-24 at 08:30 -0600, William Pitcock wrote:
On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
John H. Robinson, IV writes (Re: dash bug which is affecting release
goal):
Pierre Habouzit wrote:
echo() { /bin/echo $@ }
echo() { /bin/echo ${1+$@}; }
I believe you mean.
Why ?!
Because stand-alone $@ is undefined when used in this case. By using ${1
+$@}, it is ensured that $@ always starts with $1.
What a load of POSIX.
William
Oops, I mean Because the behaviour of stand-alone $@ is undefined.
William
signature.asc
Description: This is a digitally signed message part
Re: dash bug which is affecting release goal
On 2/24/08, William Pitcock [EMAIL PROTECTED] wrote:
On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
John H. Robinson, IV writes (Re: dash bug which is affecting release
goal):
Pierre Habouzit wrote:
echo() { /bin/echo $@ }
echo() { /bin/echo ${1+$@}; }
I believe you mean.
Why ?!
Because stand-alone $@ is undefined when used in this case. By using ${1
+$@}, it is ensured that $@ always starts with $1.
Expression ${1+$@} means if $1 exists use $@, otherwise nothing.
It's a workaround for a bug in some old bash version which erroneously
converted $@ in case of empty command line into a single empty
argument. I think in new releases it isn't necessary to account for
this.
--
Sergei Golovan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
* William Pitcock:
On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
John H. Robinson, IV writes (Re: dash bug which is affecting release goal):
Pierre Habouzit wrote:
echo() { /bin/echo $@ }
echo() { /bin/echo ${1+$@}; }
I believe you mean.
Why ?!
Because stand-alone $@ is undefined when used in this case. By using ${1
+$@}, it is ensured that $@ always starts with $1.
What a load of POSIX.
| If there are no positional parameters, the expansion of '@' shall
| generate zero fields, even when '@' is double-quoted.
Given that requirement, Sergei's explanation as an ancient bash bug
makes more sense.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Pierre Habouzit wrote:
echo() { /bin/echo $@ }
echo() { /bin/echo ${1+$@}; }
I believe you mean.
--
John H. Robinson, IV [EMAIL PROTECTED]
http
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type. spiders.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: dash bug which is affecting release goal
On 11/02/2008, Mike Bird wrote: Debian should ensure that millions of Debian users around the world who have written and tested millions of tiny shell scripts with no thought to the possibility that /bin/sh may one day become not-bash will not suffer millions of hours of down time (or worse - bad data) due to a Debian change. If those users are running unstable or testing, that's their job to track such changes. If they are running stable, that's where Release Notes can be used. On *production* Debian systems, saving 30 seconds in a boot which may occur once a year for a kernel security update is not worth a single broken script, nor a single failed backup, nor a single lost data bit. Since you're talking about *production* systems, “stable” case above, so “not a problem”. Cheers, -- Cyril Brulebois pgpgIoQn5TCta.pgp Description: PGP signature
Re: dash bug which is affecting release goal
On ma, 2008-02-11 at 09:41 -0800, Mike Bird wrote: On Mon February 11 2008 09:08:24 Russ Allbery wrote: So switch your /bin/sh back to bash when the Release Notes tell you about the change and move on with your life. That's why it's configurable. Why force millions of Debian users to do this? Furthermore, some will ignore the release notes or misread them or misunderstand them and data loss will result. I think you greatly overestimate the number of people hurt by this. Why inflict all this pain - all of which will reflect in bad karma for Debian - when it's so easy for Debian to do the right thing - use #!/bin/sh.minimal for Debian scripts and not change what users have come to expect of /bin/sh. Nobody else in the world uses /bin/sh.minimal, so this would mean scripts would have to be changed to work on Debian. That's extra, unnecessary work for package maintainers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: dash bug which is affecting release goal
Thomas Bushnell BSG wrote: Release Notes do not magically fix millions of tiny shell scripts. Thomas Setting /bin/sh back to bash does Cheers, Raphael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Mike Bird [EMAIL PROTECTED] writes: Release notes do not offset the millions of person-hours needed to review and maybe-rewrite and retest the millions of tiny shell scripts that have been written and tested by millions of Debian users with no thought to the possible consequences of subsequent changes to /bin/sh. So switch your /bin/sh back to bash when the Release Notes tell you about the change and move on with your life. That's why it's configurable. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Mon, Feb 11, 2008 at 03:39:29PM +0100, Florian Weimer wrote: * Andreas Bombe: How many million person-hours does it really need to substitute #!/bin/sh by #!/bin/bash once per script? That's even easily scriptable, and I don't see the need for any amount of reviewing and testing for such simple a bug fix. /bin/sh behaves differently than /bin/bash, even if both are implemented by bash. So this change needs some review, too. Right. #!/bin/bash --posix might give the same behavior. If it doesn't, mkdir /kludge, ln -s /bin/bash /kludge/sh, and #!/kludge/sh then, and you wouldn't have to meddle with the default /bin/sh. -- Andreas Bombe [EMAIL PROTECTED]GPG key 0x04880A44 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
* Andreas Bombe: How many million person-hours does it really need to substitute #!/bin/sh by #!/bin/bash once per script? That's even easily scriptable, and I don't see the need for any amount of reviewing and testing for such simple a bug fix. /bin/sh behaves differently than /bin/bash, even if both are implemented by bash. So this change needs some review, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: dash bug which is affecting release goal
On Mon, 2008-02-11 at 11:20 +0100, Cyril Brulebois wrote: On 11/02/2008, Mike Bird wrote: Debian should ensure that millions of Debian users around the world who have written and tested millions of tiny shell scripts with no thought to the possibility that /bin/sh may one day become not-bash will not suffer millions of hours of down time (or worse - bad data) due to a Debian change. If those users are running unstable or testing, that's their job to track such changes. If they are running stable, that's where Release Notes can be used. Release Notes do not magically fix millions of tiny shell scripts. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Mon, 2008-02-11 at 01:54 -0600, William Pitcock wrote: It's possible for programs to completely change between versions. There really is no difference in reality between switching from program A to program B and switching from program A 1.1 to 1.2. The risk of problems is exactly the same. That's ludicrous. Most developers try to help users with backward compatibility. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Mike Bird wrote: On Mon February 11 2008 02:20:26 Cyril Brulebois wrote: On 11/02/2008, Mike Bird wrote: On *production* Debian systems, saving 30 seconds in a boot which may occur once a year for a kernel security update is not worth a single broken script, nor a single failed backup, nor a single lost data bit. Since you're talking about *production* systems, “stable” case above, so “not a problem”. Release notes do not offset the millions of person-hours needed to review and maybe-rewrite and retest the millions of tiny shell scripts that have been written and tested by millions of Debian users with no thought to the possible consequences of subsequent changes to /bin/sh. Why do you believe it is better for Debian to harm millions of Debian users rather than simply using #!/bin/sh.minimal within Debian scripts? Users don't have to upgrade if they don't want to or they could just change bin/sh to bin/bash in their scripts and be done with it. So no need to rewrite or invest time except for a simple script to change bin/sh to bin/bash. Like you said, it's production, so there is no need to upgrade at all... Any decent argument left? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
[No need to Cc me; I'm subscribed. Please respect my M-F-T.] On Sun, Feb 10, 2008 at 08:39:45PM -0600, William Pitcock wrote: On Sun, 2008-02-10 at 22:11 +, brian m. carlson wrote: As far as I can tell, /usr/bin/test and /usr/bin/[ are completely useless, because none of bash, dash, posh, or zsh use them. Maybe pdksh does, but that's pretty much the list of shells that could be coerced into being /bin/sh. I propose we remove those executables from coreutils if it turns out that they are never executed. As far as I know, test and [ are infact required to be executables. POSIX says so. I'm .. beyond words right now at this paragraph. You are correct; I checked. And POSIX does provide a good rationale for it, so I withdraw my proposal. I didn't consider the fact that they might be used by programs such as /usr/bin/env. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: dash bug which is affecting release goal
On Mon February 11 2008 04:19:25 Frans Pop wrote: Hmmm. To be honest up till now I was assuming that the change of the default would only affect _new_ installs and that existing systems being upgraded from Etch to Lenny would be unaffected. This is certainly good news. If I overlooked a clear announcement that this was the intention then I apologize. However, it does exarcerbate another problem that we already face on on many new Debian installations. Because different Debian stables differently initialize various defaults which are preserved across upgrades, incompatibilities frequently arise between otherwise equivalent systems with different ancestries. A single example to illustrate: I had been aware for a long time that some older boxes have /boot/boot/grub where most newer boxes use /boot/grub. This had not been worth the effort to change the older boxes as everything just worked and grub changes carry a slight but significant risk of boot failure and downtime. However a round of grub install '(hd0)' (after a grub upgrade) worked on the newer boxes but failed to find menu.lst on the older /boot/boot/grub boxes. Even if I still had a copy of Potato I doubt it would support the latest hardware so installing an ancient version and dist-upgrading to the latest stable is not a practical solution and instead when we install a new copy of Debian we have to resort to lots of diffs and trying to figure out which differences are significant. I would therefore ask DDs to keep this issue in mind and to please minimize defaults changes between releases. Returning at last to our sheep, it would be preferable if the default /bin/sh were to remain bash and if Debian scripts were to use #!/bin/sh.minimal. This does not preclude Debian making it easy for /bin/sh to be changed by those Debian users who wish to make such a change, possibly even during D-I. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Am Montag, 11. Februar 2008 16:12:04 schrieb Mike Bird: On Mon February 11 2008 06:53:43 Adam Borowski wrote: On Mon, Feb 11, 2008 at 01:33:54AM -0800, Mike Bird wrote: On *production* Debian systems, saving 30 seconds in a boot which may occur once a year for a kernel security update is not worth a single broken script, nor a single failed backup, nor a single lost data bit. And what about Debian desktops, booted up once per day? What about home machines? They can achieve exactly the same speedup if Debian were to adopt #/bin/sh.minimal and without any wanton breakage of Debian user scripts. As I've written in a previous email a switch from debian from bash - dash won't break scripts on existing installations. If you do there a dist-upgrade sh should still point to bash.. This switch would only affect new installation. And if there is a sysmaint who installs a new system and copy over his existing scripts without testing, ... sorry but this is a case we shouldn't care about. Just my 2c. Greetings Winnie -- .''`. Patrick Winnertz [EMAIL PROTECTED] : :' : GNU/Linux Debian Developer `. `'` http://www.der-winnie.de http://people.skolelinux.org/~winnie `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part.
Re: dash bug which is affecting release goal
On Mon February 11 2008 06:53:43 Adam Borowski wrote: On Mon, Feb 11, 2008 at 01:33:54AM -0800, Mike Bird wrote: On *production* Debian systems, saving 30 seconds in a boot which may occur once a year for a kernel security update is not worth a single broken script, nor a single failed backup, nor a single lost data bit. And what about Debian desktops, booted up once per day? What about home machines? They can achieve exactly the same speedup if Debian were to adopt #/bin/sh.minimal and without any wanton breakage of Debian user scripts. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Mon, Feb 11, 2008 at 01:33:54AM -0800, Mike Bird wrote: On Sun, 10 Feb 2008 21:40:14 Raphael Geissert wrote: I've already changed my /bin/sh and I've found very very few broken/missbehaving scripts. And as a great pro my boot time is more than 50% faster now, not to mention that the overall /bin/sh scripts run faster now. On *production* Debian systems, saving 30 seconds in a boot which may occur once a year for a kernel security update is not worth a single broken script, nor a single failed backup, nor a single lost data bit. And what about Debian desktops, booted up once per day? What about home machines? What about every single shell script? A glance at /usr/bin: shell 171 perl182 python 15 ELF 658 That's a sizeable percentage. Depending on your workload, you can get a noticeable speedup. This won't matter for number crunching, but for e.g. compilation, you'll often see speedups of over 10% -- mostly due to configure and make. That's not something to shake a stick at. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Am Montag, 11. Februar 2008 13:19:25 schrieb Frans Pop: Mike Bird wrote: Debian should ensure that millions of Debian users around the world who have written and tested millions of tiny shell scripts with no thought to the possibility that /bin/sh may one day become not-bash will not suffer millions of hours of down time (or worse - bad data) due to a Debian change. Hmmm. To be honest up till now I was assuming that the change of the default would only affect _new_ installs and that existing systems being upgraded from Etch to Lenny would be unaffected. Was that an incorrect assumption? This was also my assumption. I think existing installations (with dist-upgrade) will use /bin/bash as default.. so I do miss the point for the real long discussion here. The people are right: It would be not very good to break millions of administration scripts.. but if a server with an existing installation is upgraded /bin/sh shouldn't be touched. So only people are affected who install a completly new server and migrate everything from there... but if this is done without testing the I think this is the fault of the administrator and not ours. Just my 2c. Greetings winnie -- .''`. Patrick Winnertz [EMAIL PROTECTED] : :' : GNU/Linux Debian Developer `. `'` http://www.der-winnie.de http://people.skolelinux.org/~winnie `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part.
Re: dash bug which is affecting release goal
On Mon, Feb 11, 2008 at 02:48:33AM -0800, Mike Bird wrote: Release notes do not offset the millions of person-hours needed to review and maybe-rewrite and retest the millions of tiny shell scripts that have been written and tested by millions of Debian users with no thought to the possible consequences of subsequent changes to /bin/sh. How many million person-hours does it really need to substitute #!/bin/sh by #!/bin/bash once per script? That's even easily scriptable, and I don't see the need for any amount of reviewing and testing for such simple a bug fix. -- Andreas Bombe [EMAIL PROTECTED]GPG key 0x04880A44 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Mon February 11 2008 03:39:06 Bas Wijnen wrote: Why do you believe it is better for Debian to harm millions of Debian users rather than simply using #!/bin/sh.minimal within Debian scripts? Because that's what Debian does: we fix things, even when they work while they are broken. A script which says #!/bin/sh, but which really needs bash, is a bug. Debian doesn't want those bugs. This means a transition which is some work, but we'll do it. Admins who wrote their own shellscripts may also need to check if they still work. If they don't trust it, then they should just set their shell to bash again. Admins who maintain a system that cannot afford some downtime, and who refuse to read the release notes when upgrading... well, they deserve what they get, I think. Debian has a policy which allows it to inflict this change on DD's, but it is perfectly reasonable for Debian users to have determined that /bin/sh was linked to bash and for Debian users to assume that /bin/sh will not be changed for no good reason. Furthermore, many tiny shell scripts are written by marginally technical people, perhaps by copying and adapting something from a book or web page, and they have no conception of the existence of different shell dialects and would not think kindly of a distro that broke their little jewels for no good reason. DD's are welcome to spend as much effort as they choose in fixing this non-bug in their own scripts, but sabotaging the millions of tiny scripts written by Debian users is counter-productive, can only harm Debian's reputation, and has no upside whatsoever. Debian should use #!/bin/sh.minimal for its own scripts and not wantonly break users' scripts; should not wantonly waste users' time in reviewing, repairing, and retesting working scripts; and should not wantonly cause outages, data loss, and data corruption - all of which are guaranteed in large numbers because even the best of programmers make some mistakes and a lot of tiny shell scripts in the big wide world are written by people who are not the best of programmers. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Mon, Feb 11, 2008 at 02:48:33AM -0800, Mike Bird wrote: On Mon February 11 2008 02:20:26 Cyril Brulebois wrote: On 11/02/2008, Mike Bird wrote: On *production* Debian systems, saving 30 seconds in a boot which may occur once a year for a kernel security update is not worth a single broken script, nor a single failed backup, nor a single lost data bit. Since you're talking about *production* systems, “stable” case above, so “not a problem”. Release notes do not offset the millions of person-hours needed to review and maybe-rewrite and retest the millions of tiny shell scripts that have been written and tested by millions of Debian users with no thought to the possible consequences of subsequent changes to /bin/sh. Why do you believe it is better for Debian to harm millions of Debian users rather than simply using #!/bin/sh.minimal within Debian scripts? Because that's what Debian does: we fix things, even when they work while they are broken. A script which says #!/bin/sh, but which really needs bash, is a bug. Debian doesn't want those bugs. This means a transition which is some work, but we'll do it. Admins who wrote their own shellscripts may also need to check if they still work. If they don't trust it, then they should just set their shell to bash again. Admins who maintain a system that cannot afford some downtime, and who refuse to read the release notes when upgrading... well, they deserve what they get, I think. This fix requires quite some work on our part (not that I'm personally working on it, but I see it being done ;-) ). A corporation would likely follow your approach and leave things buggy (but working). Debian aims to build the perfect OS. That means no bugs at all. We may not reach that goal, but we'll get as close to it as we can. When we see a bug, we try to fix it. This is a bug, even if it doesn't hurt much. So we will fix it. I think you're overestimating the damage this does to users. Most users don't install things with scripts from outside of Debian. For those users, we do the testing, and everything will continue to work. For the users who do install external (home-made, for example) scripts, there are two categories: Sensitive systems, where the admin should not accept the change; those admins can be expected to read the release notes and do what they should. And other systems, where the admin can notice that things don't work anymore, and fix it when that happens. This last category of users is the one which have the problems you fear. I think this is a small group, and they should be able to handle it. I am in that group myself, and that sort of problems is what I expect when I upgrade my server (running stable) to the next release. For newly installed systems, there is no problem at all. They will test their new scripts on their new system and tweak them so they will work on them. Which means less bugs. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Re: dash bug which is affecting release goal
On Sun, 10 Feb 2008 21:40:14 Raphael Geissert wrote: I've already changed my /bin/sh and I've found very very few broken/missbehaving scripts. And as a great pro my boot time is more than 50% faster now, not to mention that the overall /bin/sh scripts run faster now. Debian should ensure that millions of Debian users around the world who have written and tested millions of tiny shell scripts with no thought to the possibility that /bin/sh may one day become not-bash will not suffer millions of hours of down time (or worse - bad data) due to a Debian change. I'm an old software engineer whose experience spans toggling programs into the front-panel of an 18-bit PDP-7 through to bleeding edge AI research. Despite years of endeavoring to design software that is correct, maintainable, reliable, and secure there is no way I could swear that all the little shell scripts I've ever generated will work with a shell other than that they were tested on. On *production* Debian systems, saving 30 seconds in a boot which may occur once a year for a kernel security update is not worth a single broken script, nor a single failed backup, nor a single lost data bit. I see no problem in allowing users to knowingly change their /bin/sh and suffer the consequences of their action if that be their choice. Nor do I contest that forcing a change of /bin/sh is legal within Debian's framework of rules, but I do assert that hurting millions of Debian users through such a change would be extremely detrimental to both Debian users and Debian. I'd much prefer that Debian changed its own scripts to use #!/bin/sh.minimal without affecting user scripts, where /bin/sh.minimal could be linked to any shell meeting Debian's minimal criteria. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Mike Bird [EMAIL PROTECTED] writes: On Mon February 11 2008 09:08:24 Russ Allbery wrote: So switch your /bin/sh back to bash when the Release Notes tell you about the change and move on with your life. That's why it's configurable. Why force millions of Debian users to do this? I disbelieve in your statistics. Furthermore, some will ignore the release notes or misread them or misunderstand them and data loss will result. I disbelieve in your alarmism. Why inflict all this pain - all of which will reflect in bad karma for Debian - when it's so easy for Debian to do the right thing - use #!/bin/sh.minimal for Debian scripts and not change what users have come to expect of /bin/sh. I disbelieve in your definition of the right thing. Maybe it's because I came from a Solaris background originally, where anyone who thought /bin/sh was bash was laughed out of the room, but treating /bin/sh as always being bash is one of those things that is most closely associated with people who have no idea what they're doing and who have never looked at anything that isn't Linux. I don't have a tremendous personal interest in enabling that sort of short-sightedness when there are real gains to be had in using other shells, particularly when Debian has never guaranteed that /bin/sh is bash. All the world is not a VAX. When we upgrade gcc to a newer version that no longer compiles broken code, we don't cripple gcc to maintain its backward compatibility with broken code. We tell people to fix their broken code. This is similar, and we provide a *trivial* workaround for people who aren't ready to, aren't able to, or don't want to. I run Debian on hundreds of production servers for a major site, including with random vendor applications and random user shell scripts, and expect that when Debian switches default shells, we will too. If there are problems, we'll fix them. It's really not that hard. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Mon February 11 2008 09:08:24 Russ Allbery wrote: So switch your /bin/sh back to bash when the Release Notes tell you about the change and move on with your life. That's why it's configurable. Why force millions of Debian users to do this? Furthermore, some will ignore the release notes or misread them or misunderstand them and data loss will result. Why inflict all this pain - all of which will reflect in bad karma for Debian - when it's so easy for Debian to do the right thing - use #!/bin/sh.minimal for Debian scripts and not change what users have come to expect of /bin/sh. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Mon February 11 2008 10:56:38 Luk Claes wrote: Users don't have to upgrade if they don't want to or they could just change bin/sh to bin/bash in their scripts and be done with it. So no need to rewrite or invest time except for a simple script to change bin/sh to bin/bash. Like you said, it's production, so there is no need to upgrade at all... Hardware replacements. Security updates after Etch becomes unsupported. Any decent argument left? For using sh.minimal: see above, and earlier messages in this thread. For wantonly inflicting breakage on naive Debian users: none. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Mike Bird wrote: Debian should ensure that millions of Debian users around the world who have written and tested millions of tiny shell scripts with no thought to the possibility that /bin/sh may one day become not-bash will not suffer millions of hours of down time (or worse - bad data) due to a Debian change. Hmmm. To be honest up till now I was assuming that the change of the default would only affect _new_ installs and that existing systems being upgraded from Etch to Lenny would be unaffected. Was that an incorrect assumption? Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Mon February 11 2008 02:20:26 Cyril Brulebois wrote: On 11/02/2008, Mike Bird wrote: On *production* Debian systems, saving 30 seconds in a boot which may occur once a year for a kernel security update is not worth a single broken script, nor a single failed backup, nor a single lost data bit. Since you're talking about *production* systems, “stable” case above, so “not a problem”. Release notes do not offset the millions of person-hours needed to review and maybe-rewrite and retest the millions of tiny shell scripts that have been written and tested by millions of Debian users with no thought to the possible consequences of subsequent changes to /bin/sh. Why do you believe it is better for Debian to harm millions of Debian users rather than simply using #!/bin/sh.minimal within Debian scripts? --Mike Bird
Re: dash bug which is affecting release goal
Hi, On Monday 11 February 2008 11:48, Mike Bird wrote: On *production* Debian systems, saving 30 seconds in a boot which may occur once a year for a kernel security update is not worth a single broken script, nor a single failed backup, nor a single lost data bit. Since you're talking about *production* systems, “stable” case above, so “not a problem”. Release notes do not offset the millions of person-hours needed to review and maybe-rewrite and retest the millions of tiny shell scripts that have been written and tested by millions of Debian users with no thought to the possible consequences of subsequent changes to /bin/sh. That might be right (or not) but it's irrelevant here. The proposed change is to make dash the default /bin/sh for *new* installations, not to make this change on upgrades from stable etch to stable lenny. And if you bring new servers in production using a new release, without testing for breakage, well... regards, Holger pgpvK4Q042ott.pgp Description: PGP signature
Re: dash bug which is affecting release goal
Mike Bird [EMAIL PROTECTED] writes: Debian has a policy which allows it to inflict this change on DD's, but it is perfectly reasonable for Debian users to have determined that /bin/sh was linked to bash Yes. and for Debian users to assume that /bin/sh will not be changed No. Why is this assumption reasonable? for no good reason. This thread has listed many good reasons. -- \All persons, living and dead, are purely coincidental. -- | `\_Timequake_, Kurt Vonnegut | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Dash has a serious bug which is causing grief. The problem is that it overrides the system's test command (in Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is inconsistent with the Debian versions. Onlookers should see http://bugs.debian.org/267142 for the long history of the previous discussions of this. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, Feb 10, 2008 at 06:16:44PM +, Thomas Bushnell BSG wrote: Dash has a serious bug which is causing grief. [ strip whining ] Alas, dash does change the syntax of the command. [ whine whine whine ] What is that change please ? Last time I checked dash supported the proper POSIX required options, so I'm surprised. Instead of whining, actually giving a bug's reference and an example of package that is hindert by this issue would've helped. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpyM9abNOZSx.pgp Description: PGP signature
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Dash has a serious bug which is causing grief. The problem is that it overrides the system's test command (in Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is inconsistent with the Debian versions. Onlookers should see http://bugs.debian.org/267142 for the long history of the previous discussions of this. Thank you for adding that Russ; I looked and couldn't find it right away. I think we need to address this before we change /bin/sh as default. Merely papering it over is not suitable, because it means we must deal with a changing target; every new Posix shell that implements slightly different builtins will cause yet more problems. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 19:58 +0100, Pierre Habouzit wrote: On Sun, Feb 10, 2008 at 06:16:44PM +, Thomas Bushnell BSG wrote: Dash has a serious bug which is causing grief. [ strip whining ] Alas, dash does change the syntax of the command. [ whine whine whine ] What is that change please ? Last time I checked dash supported the proper POSIX required options, so I'm surprised. Instead of whining, actually giving a bug's reference and an example of package that is hindert by this issue would've helped. Dash does not implement the features of Debian /bin/test. It is not sufficient to implement only the features of Posix /bin/test. The policy requires that I adapt to other Posix shells, not other Posix implementations of test, ls, and other things. Or are you saying that it's ok for dash to override random Debian commands in incompatible ways? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Pierre Habouzit wrote: On Sun, Feb 10, 2008 at 06:16:44PM +, Thomas Bushnell BSG wrote: Dash has a serious bug which is causing grief. [ strip whining ] Alas, dash does change the syntax of the command. [ whine whine whine ] What is that change please ? Last time I checked dash supported the proper POSIX required options, so I'm surprised. Instead of whining, actually giving a bug's reference and an example of package that is hindert by this issue would've helped. I just replied to Thomas on the bug report including some information that demonstrates that his arguments on dash not implementing some (at least the one mentioned on the report) /usr/bin/test features is not valid. For further reference please see #464995, which is the bug report Thomas is talking about. Sincerely, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, Feb 10, 2008 at 06:57:51PM +, Russ Allbery wrote: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Dash has a serious bug which is causing grief. The problem is that it overrides the system's test command (in Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is inconsistent with the Debian versions. Onlookers should see http://bugs.debian.org/267142 for the long history of the previous discussions of this. $ dash -c 'test a = a -a b = b ; echo $?; [ a != a -o a = b ]; echo $?' 0 1 WTF is going on please ? -a and -o are prefectly supported (at least in the unstable's dash) And FWIW in the last POSIX copy I own, in the shell and utilities document: * test -a * test -o * test ( ) are XSI (X/Open System Interfaces) optional features, that unlike what Thomas pretend are properly documented. I agree we would like those XSI extensions to be implemented in our /bin/sh shells. But AFAICT dash complies, even for the () grouping: $ dash -c 'test \( a = a -o b = 1 \) -a c = c ; echo $?' 0 How come no-one even *bothered* to check. I have my plate full with whiners. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpK1WQLyBXsG.pgp Description: PGP signature
Re: dash bug which is affecting release goal
On Sun, Feb 10, 2008 at 07:17:58PM +, Thomas Bushnell BSG wrote: On Sun, 2008-02-10 at 19:58 +0100, Pierre Habouzit wrote: On Sun, Feb 10, 2008 at 06:16:44PM +, Thomas Bushnell BSG wrote: Dash has a serious bug which is causing grief. [ strip whining ] Alas, dash does change the syntax of the command. [ whine whine whine ] What is that change please ? Last time I checked dash supported the proper POSIX required options, so I'm surprised. Instead of whining, actually giving a bug's reference and an example of package that is hindert by this issue would've helped. Dash does not implement the features of Debian /bin/test. It is not sufficient to implement only the features of Posix /bin/test. The policy requires that I adapt to other Posix shells, not other Posix implementations of test, ls, and other things. Or are you saying that it's ok for dash to override random Debian commands in incompatible ways? Well, let's drop bash right away then ! $ bash -c 'type test'; zsh -c 'type test'; posh -c 'type test'; dash -c 'type test' test is a shell builtin test is a shell builtin posh: type: not found test is a shell builtin -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpJU8C4ScAQB.pgp Description: PGP signature
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Dash has a serious bug which is causing grief. The problem is that it overrides the system's test command (in Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is inconsistent with the Debian versions. Onlookers should see http://bugs.debian.org/267142 for the long history of the previous discussions of this. Indeed, I had forgotten that we had actually reached consensus and then stalled at the point of getting the list of allowed-to-deviate builtins settled. Colin had proposed the winning solution, IIRC. The only builtin which we identified needed to be on that list was test itself, and the problem here was that the deviations in posh's implementation of test would pose serious problems. That could be solved by saying something like test may be builtin in inconsistent ways, provided that X, Y, and Z features still are supported. That could be written (by careful choice of X, Y, and Z) to enable bash and dash to pass muster and still avoid the problems that supposedly are raised with posh. The other solution--which may be an acceptible short-term one, is to specify explicitly that shell scripts must work with Debian bash and Debian dash. I have no objection to that, and continue to think it is the simplest approach. As always, I am happy with just about any of these solutions, but the charge-blindly-ahead method is not good. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, Feb 10, 2008 at 07:29:28PM +, Pierre Habouzit wrote: How come no-one even *bothered* to check. For the google impaired, you can find the specification here: http://www.opengroup.org/onlinepubs/95399/utilities/test.html And yes, I think it'd be a reasonable thing to ask our shells to support the X/OPEN specification when they divert tools, and afaict they do. Can we move on now ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp1NjV2OR3ul.pgp Description: PGP signature
Re: dash bug which is affecting release goal
On Sun February 10 2008 10:16:44 Thomas Bushnell BSG wrote: Shells can override commands, but only if they don't play games with the syntax. Agreed. Within the Debian world, dash has redefined test rather than building in test. Therefore, within the Debian world, dash is not Posix compliant. Within the Debian world, this is a dash bug. Possible solutions include Debian-specific patches to either make dash's test compatible or to disable dash's incompatible test. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, Feb 10, 2008 at 02:34:37PM -0500, Thomas Bushnell BSG wrote: On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Dash has a serious bug which is causing grief. The problem is that it overrides the system's test command (in Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is inconsistent with the Debian versions. As far as I can tell, /usr/bin/test and /usr/bin/[ are completely useless, because none of bash, dash, posh, or zsh use them. Maybe pdksh does, but that's pretty much the list of shells that could be coerced into being /bin/sh. I propose we remove those executables from coreutils if it turns out that they are never executed. The only builtin which we identified needed to be on that list was test itself, and the problem here was that the deviations in posh's implementation of test would pose serious problems. The standard posh follows is Debian Policy. If you change Policy, I am pretty sure that posh will follow[0]. Policy currently specifies a set of features that are required above and beyond minimal POSIX standards (echo -n). Note that people often like to use local, so if that's something that people think should be implemented[1], then you might want to add that to the list as well. IMHO, all five of the shells listed above should be able to be used successfully as /bin/sh. That could be solved by saying something like test may be builtin in inconsistent ways, provided that X, Y, and Z features still are supported. That could be written (by careful choice of X, Y, and Z) to enable bash and dash to pass muster and still avoid the problems that supposedly are raised with posh. If you do not like posh's behavior, then please propose an amendment to policy to add additional features required by shells implementing /bin/sh. I am certain posh will implement those features. The other solution--which may be an acceptible short-term one, is to specify explicitly that shell scripts must work with Debian bash and Debian dash. I have no objection to that, and continue to think it is the simplest approach. I think this is ridiculous. One of the benefits of Debian is the huge amount of choice. We provide at least 10 window managers, 6 desktop environments, and some insanely large amount of music players. People should be free to choose the shell that best fits their needs, and providing an API (a list of required features) is far superior to mandating an implementation. I don't see what your problem is with posh. It serves a legitimate purpose: providing the bare minimum required by Policy. It's useful as a test of Policy-compliance, and not much more, which is fine. [0] I believe that Clint Adams said as much himself. [1] I have no opinion on this, other than that I want udev to work with posh. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 20:34 +0100, Pierre Habouzit wrote: On Sun, Feb 10, 2008 at 07:17:58PM +, Thomas Bushnell BSG wrote: Or are you saying that it's ok for dash to override random Debian commands in incompatible ways? Well, let's drop bash right away then ! $ bash -c 'type test'; zsh -c 'type test'; posh -c 'type test'; dash -c 'type test' test is a shell builtin test is a shell builtin posh: type: not found test is a shell builtin Right. The problem is that Debian policy on the question is incoherent. It was wrong of me to describe it as a dash bug. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 22:11 +, brian m. carlson wrote: On Sun, Feb 10, 2008 at 02:34:37PM -0500, Thomas Bushnell BSG wrote: On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Dash has a serious bug which is causing grief. The problem is that it overrides the system's test command (in Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is inconsistent with the Debian versions. As far as I can tell, /usr/bin/test and /usr/bin/[ are completely useless, because none of bash, dash, posh, or zsh use them. Maybe pdksh does, but that's pretty much the list of shells that could be coerced into being /bin/sh. I propose we remove those executables from coreutils if it turns out that they are never executed. There are many cases where one may well want the test program. We need them regardless. The only builtin which we identified needed to be on that list was test itself, and the problem here was that the deviations in posh's implementation of test would pose serious problems. The standard posh follows is Debian Policy. If you change Policy, I am pretty sure that posh will follow[0]. Policy currently specifies a set of features that are required above and beyond minimal POSIX standards (echo -n). I don't know what the particular issue is with posh. It was brought up as an example in the policy discussion a while ago. I don't see what your problem is with posh. It serves a legitimate purpose: providing the bare minimum required by Policy. It's useful as a test of Policy-compliance, and not much more, which is fine. I don't have a problem with posh. It was brought up in the policy discussion the last time. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
brian m. carlson [EMAIL PROTECTED] writes: The standard posh follows is Debian Policy. If you change Policy, I am pretty sure that posh will follow[0]. Policy currently specifies a set of features that are required above and beyond minimal POSIX standards (echo -n). Note that people often like to use local, so if that's something that people think should be implemented[1], then you might want to add that to the list as well. IMHO, all five of the shells listed above should be able to be used successfully as /bin/sh. Policy already says that any shell interpretor installed as /bin/sh may be assumed to support local and test -a/-o. See Policy 10.4. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 11:26 -0800, Mike Bird wrote: On Sun February 10 2008 10:16:44 Thomas Bushnell BSG wrote: Shells can override commands, but only if they don't play games with the syntax. Agreed. Within the Debian world, dash has redefined test rather than building in test. Therefore, within the Debian world, dash is not Posix compliant. Within the Debian world, this is a dash bug. Possible solutions include Debian-specific patches to either make dash's test compatible or to disable dash's incompatible test. Or to follow Colin's suggestion from the policy discussion a few years ago, and grant a special exception, carefully crafted, for particular shell builtins. I have no objection to that solution. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, Feb 10, 2008 at 11:53:35PM +, Thomas Bushnell BSG wrote:
On Sun, 2008-02-10 at 20:34 +0100, Pierre Habouzit wrote:
On Sun, Feb 10, 2008 at 07:17:58PM +, Thomas Bushnell BSG wrote:
Or are you saying that it's ok for dash to override random Debian
commands in incompatible ways?
Well, let's drop bash right away then !
$ bash -c 'type test'; zsh -c 'type test'; posh -c 'type test'; dash -c
'type test'
test is a shell builtin
test is a shell builtin
posh: type: not found
test is a shell builtin
Right. The problem is that Debian policy on the question is incoherent.
Well, policy describes usage, and usage (I think) is to assume that
/bin/sh gives you a decently recent POSIX environment (I said POSIX not
GNU) and that if you rely on GNU extensions of tools (like echo -e) you
should call those commands using their full path wich can be done using
really simple tricks like:
echo() { /bin/echo $@ }
Policy has absolutely no valid reasons to dictate to shells how they
are implemented, and it's a perfectly sane thing for an efficient enough
shell to implement echo, test, [, true, false and probably which as
shell builtins given their pervasive use in shell idioms.
If the policy mandates anything else, then the policy is definitely
bogus and should be fixed, and there is nothing like a dash bug
affecting a release goal. There are two test related dash bugs, one
is completely cornercase: `test \( ! -e \)` and the other is a bit more
serious though unlikely to generate an issue in the general case (the
problem with [ '!' != ' ' ]. And after all, there is still some months
before we release to fix them instead of talking endlessly.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpSYmTnUA9BV.pgp
Description: PGP signature
Re: dash bug which is affecting release goal
On Mon, 2008-02-11 at 01:54 +0100, Pierre Habouzit wrote:
Well, policy describes usage, and usage (I think) is to assume that
/bin/sh gives you a decently recent POSIX environment (I said POSIX not
GNU) and that if you rely on GNU extensions of tools (like echo -e) you
should call those commands using their full path wich can be done using
really simple tricks like:
echo() { /bin/echo $@ }
I believe Policy prohibits the use of full paths to specify programs in
the standard PATH.
Policy has absolutely no valid reasons to dictate to shells how they
are implemented, and it's a perfectly sane thing for an efficient enough
shell to implement echo, test, [, true, false and probably which as
shell builtins given their pervasive use in shell idioms.
Policy requires that programs which provide the same names as each other
provide equivalent functionality. No exception (currently) is made for
test. I am not at all opposed a carefully written exception for test;
that is the substance of Colin's proposal.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun February 10 2008 15:54:36 Thomas Bushnell BSG wrote: Or to follow Colin's suggestion from the policy discussion a few years ago, and grant a special exception, carefully crafted, for particular shell builtins. I have no objection to that solution. As a Debian user rather than a DD I hope that Debian will ensure that this solution has absolutely no effect on non-Debian scripts which use #!/bin/sh and (perhaps unconsciously) expect test to work as in bash. This applies to everything from tarballs of packages which are not yet in Debian to the dozens of tiny custom scripts that everyone has for backups or nagios extensions or adding users or emptying cameras etc etc. Not everyone writes scripts to the same high standards as Debian but it would still be very unfortunate if a Debian update broke them. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 22:11 +, brian m. carlson wrote: As far as I can tell, /usr/bin/test and /usr/bin/[ are completely useless, because none of bash, dash, posh, or zsh use them. Maybe pdksh does, but that's pretty much the list of shells that could be coerced into being /bin/sh. I propose we remove those executables from coreutils if it turns out that they are never executed. As far as I know, test and [ are infact required to be executables. POSIX says so. I'm .. beyond words right now at this paragraph. signature.asc Description: This is a digitally signed message part
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 18:12 -0800, Mike Bird wrote: On Sun February 10 2008 15:54:36 Thomas Bushnell BSG wrote: Or to follow Colin's suggestion from the policy discussion a few years ago, and grant a special exception, carefully crafted, for particular shell builtins. I have no objection to that solution. As a Debian user rather than a DD I hope that Debian will ensure that this solution has absolutely no effect on non-Debian scripts which use #!/bin/sh and (perhaps unconsciously) expect test to work as in bash. I'm afraid, that the problem here is just that. Debian doesn't promise that /bin/sh is bash. Scripts which need bash are supposed to specify bash. At least, that's the theory. This applies to everything from tarballs of packages which are not yet in Debian to the dozens of tiny custom scripts that everyone has for backups or nagios extensions or adding users or emptying cameras etc etc. Yes, that's right. I think the idea of making dash the default /bin/sh is sure to be a disaster. But I have no power in that regard. I can only hope I'm wrong. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Thomas Bushnell BSG wrote: On Sun, 2008-02-10 at 18:12 -0800, Mike Bird wrote: This applies to everything from tarballs of packages which are not yet in Debian to the dozens of tiny custom scripts that everyone has for backups or nagios extensions or adding users or emptying cameras etc etc. Yes, that's right. I think the idea of making dash the default /bin/sh is sure to be a disaster. But I have no power in that regard. I can only hope I'm wrong. FYI Ubuntu already made the switch some time ago and they have all of the packages from unstable + some more. By filling bug reports I try to reduce the impact of making the move that in theory should be more than safe (except for two or three known bugs on dash). Thomas Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 21:10 -0600, Raphael Geissert wrote: On Sun, 2008-02-10 at 18:12 -0800, Mike Bird wrote: This applies to everything from tarballs of packages which are not yet in Debian to the dozens of tiny custom scripts that everyone has for backups or nagios extensions or adding users or emptying cameras etc etc. Yes, that's right. I think the idea of making dash the default /bin/sh is sure to be a disaster. But I have no power in that regard. I can only hope I'm wrong. FYI Ubuntu already made the switch some time ago and they have all of the packages from unstable + some more. By filling bug reports I try to reduce the impact of making the move that in theory should be more than safe (except for two or three known bugs on dash). I think you're ignoring Mike Bird's concern. What about custom scripts, non-Debian things, user-written scripts, etc.? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Raphael Geissert [EMAIL PROTECTED] writes: I just replied to Thomas on the bug report including some information that demonstrates that his arguments on dash not implementing some (at least the one mentioned on the report) /usr/bin/test features is not valid. For further reference please see #464995, which is the bug report Thomas is talking about. So, to sum up the results of that bug, Thomas was specifically using a bash feature and this entire business of the behavior of /usr/bin/test is a red herring for the problem that started this whole discussion. The original problem would have occurred with any /bin/sh that isn't bash (or at least any /bin/sh that didn't implement bash's == extension). If we're going to have an argument about how /bin/sh should be bash, let's at least actually have that argument rather than confusing it with an argument over shell built-ins overriding binaries. If bash didn't override the /usr/bin/test binary to *add* non-standard features that the binary doesn't support, Thomas's program would never have worked in the first place. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
[Please do _only_ reply to the ML, I read it] Thomas Bushnell BSG wrote: On Sun, 2008-02-10 at 21:10 -0600, Raphael Geissert wrote: FYI Ubuntu already made the switch some time ago and they have all of the packages from unstable + some more. By filling bug reports I try to reduce the impact of making the move that in theory should be more than safe (except for two or three known bugs on dash). I think you're ignoring Mike Bird's concern. What about custom scripts, non-Debian things, user-written scripts, etc.? They should be fixed as well, remember that as long as we continue using bash as the default /bin/sh people who make the move will suffer the consequences of people writing /bin/sh scripts which should really be /bin/bash ones. By the way, don't forget you have the choice of making bash the default /bin/sh. I've already changed my /bin/sh and I've found very very few broken/missbehaving scripts. And as a great pro my boot time is more than 50% faster now, not to mention that the overall /bin/sh scripts run faster now. Thomas Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 20:39 -0800, Steve Langasek wrote: So we should also never upgrade /usr/bin/python, /usr/bin/perl, or /usr/bin/gcc to point at a new upstream version because users may have local programs that assume particular non-standard behavior from these programs, right? I think that's a different case. There is a big difference between a newer version of the same program and a totally different program with fewer features. Still, I understand the motivation for the change and I am in support of it. I'm just worried also. Perhaps I'm a needless worrywort. But all the attention does seem to have been focused on one specific case--Debian packages--and not the others. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Hi, On Sun, 2008-02-10 at 23:48 -0500, Thomas Bushnell BSG wrote: On Sun, 2008-02-10 at 20:39 -0800, Steve Langasek wrote: So we should also never upgrade /usr/bin/python, /usr/bin/perl, or /usr/bin/gcc to point at a new upstream version because users may have local programs that assume particular non-standard behavior from these programs, right? I think that's a different case. There is a big difference between a newer version of the same program and a totally different program with fewer features. It's possible for programs to completely change between versions. There really is no difference in reality between switching from program A to program B and switching from program A 1.1 to 1.2. The risk of problems is exactly the same. William signature.asc Description: This is a digitally signed message part
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 19:36 -0800, Russ Allbery wrote: Raphael Geissert [EMAIL PROTECTED] writes: I just replied to Thomas on the bug report including some information that demonstrates that his arguments on dash not implementing some (at least the one mentioned on the report) /usr/bin/test features is not valid. For further reference please see #464995, which is the bug report Thomas is talking about. So, to sum up the results of that bug, Thomas was specifically using a bash feature and this entire business of the behavior of /usr/bin/test is a red herring for the problem that started this whole discussion. Actually, it's upstream's script, a genuine shell program, not just a Debian maintainer script (the more usual case), so the right fix was to specify /bin/bash since that is obviously what upstream was expecting all along. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, Feb 10, 2008 at 10:19:15PM -0500, Thomas Bushnell BSG wrote: On Sun, 2008-02-10 at 21:10 -0600, Raphael Geissert wrote: On Sun, 2008-02-10 at 18:12 -0800, Mike Bird wrote: This applies to everything from tarballs of packages which are not yet in Debian to the dozens of tiny custom scripts that everyone has for backups or nagios extensions or adding users or emptying cameras etc etc. Yes, that's right. I think the idea of making dash the default /bin/sh is sure to be a disaster. But I have no power in that regard. I can only hope I'm wrong. FYI Ubuntu already made the switch some time ago and they have all of the packages from unstable + some more. By filling bug reports I try to reduce the impact of making the move that in theory should be more than safe (except for two or three known bugs on dash). I think you're ignoring Mike Bird's concern. What about custom scripts, non-Debian things, user-written scripts, etc.? So we should also never upgrade /usr/bin/python, /usr/bin/perl, or /usr/bin/gcc to point at a new upstream version because users may have local programs that assume particular non-standard behavior from these programs, right? Otherwise, why should we be fretting over users who assume that /bin/sh == /bin/bash, when we've never promised anything of the sort? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
