Script that are using bash could be broken with the new symlink

[Egil Hasting]

Binary package hint: dash

The scripting capability between bash and dash are not equal, which could break scripts that today relies on bash ( #!/bin/sh -> /bin/bash), i tracked down this problem with cedega on edgy, and was able to get it working again by forcing the script to use #!/bin/bash (instead of /bin/sh)

I don't know how this is going to be solved, but it could disturbe some scripts in the nair future.

[Tom Bruno (crweb)]

This is a pretty large scale problem. I'm seeing scripts breaking all over the place. and strange errors about bad interpreters and such since this change.

[Jason Straight (jason-jeetkunedomaster)]

Yeah, I agree, I even had some installation scripts fail when dash replaced bash during apt-get dist-upgrade. As well as some LSB scripts. It was an unholy mess.

[anthony baxter (anthony)]

Please reverse this change before edgy final. It's caused massive breakage for me - for instance, the intel compiler was utterly broken. It relied on 'export -n' and 'exec -a' working. I'm almost tempted to remove dash with dpkg -r and live with the apt-get complaints.

This is a huge mistake - it's broken all manner of things for me, and I suspect that it will end up being a support nightmare once edgy final is released to the world.

Yes, people shouldn't have assumed that /bin/sh was bash rather than bourne shell - but they have. I can fix my own scripts, but going through other vendor supplied scripts is going to be a complete pain.

[Graham Hawkins (grahamhawkins)]

Small beer compared with the problems above, but it also breaks Limewire's runLime.sh

[sparr (sparr0)]

Complain to the script authors who are making the mistake. Dash has been a viable provider of /bin/sh (by way of debconf on the dash package) for a long time. There are other shells that provide 'sh' functionality too. If a script really requires /bin/bash then it needs to start with #!/bin/bash.

Analogy: If I needed a square, I would not ask you for a rectangle. Although you might give me the square that I need, since that would fulfill my stated rectangle requirements, it is not guaranteed.

People who need /bin/bash should not ask for /bin/sh and hope that the result they get just happens to be /bin/bash. I have used dash as my /bin/sh for over a year now. It is insanely faster, especially for huge shell scripts such as 'configure' in large projects.

[GreenSkol (greenskol)]

A difference between dash and bash is the echo command : you can't escape characters :
"\\n" always print a newline with dash, whereas it prints "\n" with bash.

It make a huge difference in Makefiles, that default to /bin/sh shell, unless you specify the SHELL variable in the Makefile.

For exemple, glibc makefiles are broken and I couldn't compile it out of the box with Edgy :-(

[Stephen Thorne (jerub)]

Suggested resolution:

Use /bin/dash instead of /bin/sh for scripts that are desired to run fast, and revert the change.

If you like ./configure running faster, then patch the code so that ./configure has #!/bin/dash.

This change has obviously caused regressions, and should be considered a high priority bug that should be fixed, not justified.

[sparr (sparr0)]

The 'bug' is not with dash, it is with every package that dash "breaks".
They should all be fixed. *maybe* dash should not be the default until they
are fixed, but I think they would never get fixed if it wasn't.

On 10/30/06, Stephen Thorne <email address hidden> wrote:
>
> Suggested resolution:
>
> Use /bin/dash instead of /bin/sh for scripts that are desired to run
> fast, and revert the change.
>
> If you like ./configure running faster, then patch the code so that
> ./configure has #!/bin/dash.
>
> This change has obviously caused regressions, and should be considered a
> high priority bug that should be fixed, not justified.
>

[Stephen Thorne (jerub)]

Having talked to folks on IRC about this (including a canonical employee) it seems that no one who should care, cares about regressions, and this is going to stay broken.

Blarg. I guess it's a good thing dapper is LTS.

[LionsPhil (lionsphil)]

Sparr, your comments are unhelpful---there IS a problem here, and it making the distribution notably less useful. Reverting /bin/sh to point to bash will fix this until you can (quite rightly) beat people into specifying /bin/bash if they need bash.

But, for now, this is breaking stuff, and it can be easily unbroken. The high road here is not helpful to Ubuntu users, and smacks of the same kind of perfectionist arrogance which curses open source software to forever be a continual battle with your computer to make it actually work properly.

If you think this is minor, search for “dash” within the Ubuntu bug list. I've seen this break _configure scripts_, for crying out loud. You're not going to upstream fix autoconf _and_ get everyone who uses it to release new tarballs this side of 2007.

[Simon Howard (fraggle)]

I would have thought it would be preferable to have a system that works than a fast one that doesn't. Besides, is bash really that slow?

Yes, ideally shell scripts that use #!/bin/sh shouldn't rely on bash features, but the truth is that a lot of them do, because every other distribution out there uses bash for sh. You can tell people to complain to the script authors, but there is going to be another script that doesn't work. And another. And another. And a thousand more.

What I find perplexing is that Ubuntu of all distributions would make a decision like this, when from the very beginning it has always seemed to have had the goal of being easy to use and of "Just working". This is the kind of subtle and insidious difference that nobody is going to notice without hours of searching and experimentation. In the end people are going to just decide that "Ubuntu is broken" and move on.

By the way, the installer for Borland Starteam also doesn't work. Add that to the list of software that Ubuntu now no longer supports. At work my team is looking to standardise on Ubuntu as our Linux development OS, but if we can't use this then I expect we'll end up using Fedora or another system. I'll be very disappointed if this happens.

Good engineering involves making compromises. I hope you'll come to the right decision.

[Matthew Garrett (mjg59)]

bash will always be provided, and changing the target of the /bin/sh symlink is perfectly acceptable for local configuration. However, there are no plans to change the default configuration back to bash.

[Justus Pendleton (justus)]

FWIW, I initially reported this problem -- software claiming to use /bin/sh actually expecting bash -- to debian in 1997 (http://lists.debian.org/debian-devel/1997/04/msg00570.html). I was blown off and told that /bin/sh would always be /bin/bash and that people could and should just assume that /bin/sh was not merely a POSIX sh but provided all the extra bashisms.

[Jeff Schering (jeffsch)]

I suggest that the overwhelming majority of Ubuntu users are people who know nothing about the difference between bash and dash, who know nothing about shebangs and symlinks, and who know nothing about scripting. And when you tell them "changing the target of the /bin/sh symlink is perfectly acceptable for local configuration" they will have no idea what you're talking about.

If you are a developer running large projects and need configure to run insanely fast, then you are in a tiny minority of Ubuntu users. It's much more reasonable to ask a few developers to symlink /bin/sh to /bin/dash than it is to ask hundreds of thousands (if not millions) of regular users to change their symlinks from /bin/sh to /bin/bash to fix a script problem caused by a developer who should have used #!/bin/bash in the first place.

Even the use cases on https://wiki.ubuntu.com/DashAsBinSh focus on developer convenience more than the end user's experience. When you insist on keeping dash, you are asking millions of users to suffer so that a few developers can have a smaller, faster shell.

Bash is a GNU tool. It has been the de facto standard shell in GNU/Linux for a decade or so. To suddenly go to a shell which is not compatible with the standard is bad for users. At the very least, you are asking them to wait a year or more while a bunch of other developers change their script shebangs to #!/bin/bash. Most programmers are too crunched for time to make the change quickly. Most probably do not even know whether or not they are using bash-specific extensions; that's how standard bash has become.

If you think that developers the world-over should have been using #!/bin/bash instead of #!/bin/sh for the last decade, then talk to the developers; don't force your dispute on innocent bystanders.

By insisting on dash, you are effectively demanding compliance to dash's interpretation of POSIX 1003.2 compliance without warning and after having a decade's worth of non-compliant scripts floating around. In addition, it forces developers to first become intimately aware of the 1003.2 standard (as implemented by dash) and then examine their scripts to make sure that they comply. This might be okay if it didn't leave Ubuntu users out in the cold, and if it wasn't going to take so long for the script changes to be made.

Don't forget what the word "ubuntu" means. You are causing unneeded grief to your fellow humans, and so far your only response has been "screw you lusers".

Edgy and Feisty are expected to be broken in various ways, but please don't let this particular bit of breakage leak into the next LTS product.

[David Roberts (david.roberts)]

Dash is terrible. The fact is in the majority of cases it fails miserably. Please change the default back to bash.

[sparr (sparr0)]

"The fact is in the majority of cases [dash] fails miserably"

This is what polite people call a falsehood, and what I call a lie.

By my gross overestimate, dash fails while compiling less than 5% of available packages, and while installing less than 1%. The failure rate for third party software, such as cedega and commercial installers, is around 5%. This is not a majority by quite a bit.

While I somewhat sympathize with the "make it work, even if it's wrong" sentiment, I would be willing to bet that less than half of the people who have posted here have bothered to report the real bugs to their package maintainers and/or upstream. Start making efforts in the right direction.

[David Roberts (david.roberts)]

> "The fact is in the majority of cases [dash] fails miserably"
> This is what polite people call a falsehood, and what I call a lie.
Ok, fine, perhaps a slight overstatement.

I tried using dash, but it only took a few days before I started coming across broken scripts (which had previously worked before the upgrade to edgy), and it took me about an hour to figure out what was wrong. The "average" user has no hope of working this out easily.

It's easy to say that scripts should begin with #!/bin/bash, but the fact is many don't. The only advantage of dash I've read of is that it's faster. To be honest, I'd rather have scripts work rather than have them run slightly faster. If you really want a faster shell, then give dash as an option for that minority of users, but don't force it by default.

In most cases, bash is the standard, and that's the assumption most scripts are written around. I'm not going to start mailing developers saying "please add an extra two letters two your script because my distribution has an incompatible default shell." Perhaps it should be the scripts actually requiring dash to be adding the line #!/bin/dash.

[Matthew Garrett (mjg59)]

The standard, as defined by the LSB, is that /bin/sh conforms to POSIX
(with one extension related to login shells, but that's not relevant in
this case). If vendors are distributing software that expects /bin/sh to
be bash, then that software is broken. Please take it up with them.

--
Matthew Garrett | <email address hidden>

[David Roberts (david.roberts)]

May I ask why the default shell was changed to dash in the first place? From what I've seen, there doesn't seem to be any benefits apart from being faster (which IMHO isn't as important as running scripts properly). As I already said, I don't see why dash can't just be an option, and not a default. Yes, it's true that these scripts may be in the wrong - but that still doesn't stop the fact that they work almost every other distro using bash, but not in edgy. Basically, why does dash _have_ to be set as default? I'm not saying to remove it from the repositories altogether, but not to force it upon people when it obviously clashes with numerous scripts.

[Kasper Peeters (kasper-peeters)]

I would like to add my support in favour of going back to bash.

No matter what the arguments are for dash, it is very bad for ubuntu's image if software which worked out of the box until now all of a sudden fails for no obvious reason.

If there is a good reason to use dash, find a solution which "just works".

[LionsPhil (lionsphil)]

This also breaks building glibc (specifically, as part of the GP2X development kit, but it's basically a wget and make on glibc, gcc, etc. sources with flags for cross-compiling to ARM), because dash's “echo” built-in behaves differently from the GNU /bin/echo (which bash's built-in emulates more accurately), causing it to generate a syntatically incorrect version header file.

Let's re-iterate here: “average” users don't have a hope in hell of working out that things-expecting-bash-get-dash (or its built-ins) is the problem, let alone fixing it. Ubuntu is supposed to be a distribution for “average” users. Those of you who want to be pedants about standards for the excuse of feeling good about yourself, or microscopic speed gains, please go help Gentoo. This is the kind of unproductive stupidity I'd expect from them.

[Tamas Fejos (tfejos)]

Dash is also breaks install and usage of some Vmware products.
Such as Vmware server install (workaround: use "perl vmware-install.pl" instead of simply execute "vmware-install.pl").

It breaks Vmware mui's /etc/init.d/httpd.vmware file also. The install workaround is the same as above. But for proper operation the init script should be changed and it is recommended to install it with /bin/sh linked to /bin/bash.

More info: http://www.vmware.com/community/thread.jspa?messageID=538079

[probono (probono)]

Please revert to bash.

Regardless whether they are "right" or not - many script developers have silently assumed that scripts starting with #!/bin/sh is executed by bash.

An operating system such as Ubuntu is supposed to be a dependable platform for 3rd party applications to run on top of it. And since there are many (legacy) applications out there that assume that scripts starting with #!/bin/sh is executed by bash, Ubuntu "breaks" those by switching away from the "de-facto standard".

Please consider the situation of a non-technical end user who doesn't care whose fault it is that his app doesn't work as expected.

It is changes like this that make Ubuntu less likely to solve bug #1.

[sparr (sparr0)]

$10 says neither of you reported the problem to those at fault, GPH and VMWare, instead of just discussing it in forums. If people put half as much time into getting the problem fixed as they do whining about it, the vast majority of packages would already be fixed.

[LionsPhil (lionsphil)]

I /am/ working on getting the problem fixed. Unfortunately, there's this arrogant perfectionist who values standard compliance over a system /actually being useful/. Perhaps he should go and berate the Firefox developers for writing a renderer which doesn't correctly stop dead on invalid XHTML, and tells the user to complain to the webmaster to fix their site.

Because getting large groups of people to fix software/data, much of which is [now] unsupported, is /so/ much more practical than leaving alone something which Just Works.

[sparr (sparr0)]

Nothing in an Ubuntu package is unsupported. If the upstream has
abandoned it then the maintenance falls on the package maintainer. If
the package maintainer is lax then replace him yourself.

On 1/3/07, LionsPhil <email address hidden> wrote:
> Because getting large groups of people to fix software/data, much of
> which is [now] unsupported, is /so/ much more practical than leaving
> alone something which Just Works.

[probono (probono)]

sparr, it is not (only) about packages that are part of Ubuntu. It is also about software that came from the Internet or on CD-ROM from third parties. Software that (despite breaking the rules) used to work flawless, and that gives the non-technical end user errors now.

This bugreport is about a mindset: It is about not touching things that might result in other things (including the world outside Ubuntu) to break.

[hoganrobert (robert-roberthogan)]

I think the Ubuntu maintainers would do well to read http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119185 (if they haven't already). That thread is an object lesson in why being correct is not the same as being right.

Your point about compliance and decades of false assumptions by hundreds of software projects are valid. However if Ubuntu fixes something that breaks the rest of the world, then you are either being naive or disingenuous if you expect your users to fix the rest of the world for the privelege of working with Ubuntu.

[LionsPhil (lionsphil)]

Unfortunately, sparr, I don't have the time (I'm wasting quite enough on this thread, it appears), permissions, bandwidth or whatnot to fork and take over every project in the world which is broken and the devs aren't there/inclined to fix. The far, _far_ more efficient way for me to fix it is to change by /bin/sh.

In the interests of being a good little Open Source citizen, I have been adding cases to support this bug such that my peers can also enjoy the unbroken experience of having a /bin/sh which works the same as /bin/sh in virtually every other Linux distribution.

[Jeff Schering (jeffsch)]

According to the manpage for bash, when invoked with sh, bash is POSIX compliant. When you ask for /bin/sh, you get bash running in POSIX compliant mode. When you ask for /bin/bash you get bash running in its default mode.

To demonstrate, make sure your /bin/sh is symlinked to bash, then run these two scripts and compare their outputs.

script1
!#/bin/sh
kill -l

script2
!#/bin/bash
kill -l

So you can see that invoking bash with /bin/sh causes it to run in a POSIX compliant manner. (see http://www.opengroup.org/onlinepubs/009695399/utilities/kill.html which describes the kill command in POSIX systems)

One of the two documented exceptions is in the way bash handles options to the built-in echo command (see /usr/share/docs/bash/POSIX.gz, scroll down to the bottom).

The reason for this is simple. Until IEEE Std 1003.1 2004 Edition, the spec said that POSIX compliant implementations of the shell "need not" support options. It appears that the ash developers decided to *not* support options to echo, while the bash developers decided to *allow* options to echo, for whatever reason. (for the spec on echo, see http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html)

The standard was changed in 2004 to specify that echo "shall not" accept options, leaving bash in a state not only of non-compliance, but also with a long list of shell scripts that depended on the echo command being able to accept options. So today, bash still accepts options to echo even when in POSIX compliance mode.

However, bash can be configured to be in complete conformance, ignoring options to the echo command. (see the manpage)

Generally though, the echo command is a headache for POSIX compliance. To quote the standard: "It is not possible to use echo portably across all POSIX systems unless both -n (as the first argument) and escape sequences are omitted."

Perhaps because of the non-portability of echo, the standard recommends this: "New applications are encouraged to use printf instead of echo."

But if new applications are encouraged to use printf instead of echo, then why is echo not deprecated? Again, a quote from the standard: "The echo utility has not been made obsolescent because of its extremely widespread use in historical applications."

Ideally, echo should be obsolete and all scripts should use printf instead. However, the large number of scripts using echo makes it impractical.

If the ISO standards people can keep echo around because of its extremely widespread use in the past, then why can't Ubuntu people keep bash around for the same reason? Afterall, as shown above, bash is POSIX compliant when run as sh.

The only advantage that dash has is its size and speed, but these are probably irrelevant to the overwhelming majority of Ubuntu users, who would almost never notice a speed difference between the two anyway. More important to them is to have "black boxes" (that's what a shell script is to normal people) that "just work".

[sparr (sparr0)]

The overwhelming majority of Ubuntu users would almost never notice application installs running faster? I am serious. There are packages that take over a minute for post-install dpkg configuration, and dash speeds them up a LOT. It's the difference in spending 10 minutes or 30 minutes on dist-upgrade (or I guess adept probably just does upgrade).

Bash being optionally POSIX compliant, with or without exceptions, really has no bearing here. Bashisms are bad. They need to be fixed. I understand the idea of keeping Ubuntu easy for everyone to use, but you also need to understand that sometimes you have to do things the hard way to make the world a better place. Ubuntu is the first major distro to move to dash. I think we have begun down a slippery slope towards eradication of bashisms. They never would have gone away if it was just 'the right thing to do', but now if you write broken scripts you give up support for a major distro. I don't think any new bashisms will be entering the world as soon as a year from now, and I expect we can resolve any existing problems by then as well. Bite the bullet.

[anthony baxter (anthony)]

"The overwhelming majority of Ubuntu users would almost never notice application installs running faster?"

You're right, of course. Rather than taking 10 minutes or 30 minutes on dist-upgrade, instead the application installs will fail to work, because of this bizarre decision to favour correctness over something that just works.

I'm sure the users will thank you for the time they've saved.

[David Roberts (david.roberts)]

"The overwhelming majority of Ubuntu users would almost never notice application installs running faster? I am serious. There are packages that take over a minute for post-install dpkg configuration, and dash speeds them up a LOT. It's the difference in spending 10 minutes or 30 minutes on dist-upgrade (or I guess adept probably just does upgrade)."

Exactly. You know these scripts work with dash and you want them to use dash - so explicitly begin them with #!/bin/dash so that they do this. You also know that many scripts depend on /bin/sh -> /bin/bash - so leave it that way. I feel that this would be a good compromise between the speed of official Ubuntu scripts, and allowing 3rd party scripts to work.

If someone goes "Hey, I'm sick of bash taking forever and want my scripts to run faster at the risk some not working", then there's nothing stopping them from switching their symlinks. I honestly ask you, which is better:
- a minority of power users deciding to set their default to dash, or
- a majority of "normal users" spending many hours trying to determine the problem and having to work out how to reset to bash

Also, can this bug be changed from "wishlist" as I feel that it's more important than that (seeing as it affects so many other scripts).

[AndyLandy (andrew-landells)]

What about modifying dash to allow a full implementation of echo? If this really is the only bash-ism that is breaking things, then dash could work around it, that way Ubuntu can use dash as the default shell and be fast, whilst still having everything work correctly. Maybe this means it doesn't comply with the POSIX standard, but it would mean that the huge amounts of legacy code wouldn't break.

If what Jeff Schering says is true, then it suggests that the problem is *not* with the devs of bash, or the myriad of software that depends on it as /bin/sh, but is down to the POSIX standard being changed. All these scripts would have been POSIX-compliant until 2004 when the spec was changed. Maybe this should be filed as a bug in the new POSIX standard...

Just my two cents. :-)

[jharms (juergen-harms)]

Here is a nice illustration in support of arguments made in this discussion. I am a visitor, I tried Ubuntu to see whether it is worth while to consider switching to Ubuntu. I got stuck with (1) some simple scripts that use shell variable indirection and dont work in Ubuntu and (2) the vpnc library package not working in Ubuntu - I need vpnc to connect to my universities intranet.

I lost about 1/2 day to discover that sh is not sh and to figure out a work-around. And I lost nearly another 1/2 day to dig into bash manuals, Posix specifications, understanding the reasoning - and to discover the present discussion.

Lessons learned under the bottom line: (a) programmes dont run on Ubuntu that run on other distributions and (b) Ubuntu does not check whether their library packages run (reading this discussion: does not care?). I translate this - maybe too harshly put - to: unless you consider compliance to Posix as quality, Ubuntu lacks quality.

The speed argument is pure theory: how much time does an average application spend executing shell scripts, and what is the average time needed on a somewhat recent computer? And, system installation time on Ubuntu with Dash and on Mandriva without Dash is very comparable.

My conclusion: For a user who does not want to invest all that time (and has the skills to do it), but who wants to do "a little bit more than office applications" Ubuntu is not adequate.

A contribution to the technical part of this discsussion: I stumbled over the following shell constructs that run in Bash (and Sh) but not in Dash:

x=${!y} (indirection: read a variable whose name is the value of another one)

for ((i = 0 ; i < 3 ; i++ )) ; do
  ... snip ...
done
(a very simplified copy of code I extracted from the vpnc-script file from the vpn library package - vpnc-script lines 225 and on)

[devnull (sscott-westnet)]

My 2c.

I know its painful that a bunch of stuff is broken - Im suffering from problems with it at the moment (which is why Im here). However, every now and then its good to shake things up and blow assumptions away - short term pain for long term gain.

[mannheim (kronheim)]

More examples of 3rd-party software that is partly broken by dash include:

Mathematica
NX Server

Users will turn away from Ubuntu, and report: "I tried it on Fedora [or whatever], and it just worked." Things should "just work" on Ubuntu.

[Mark Constable (markc)]

What worries me about this issue is the attitude of the ubuntu developers. I no longer trust the ubuntu devs to do the right thing to help me keep the systems I make a living from up and running and am now looking at migrating everything to etch+ instead of edgy+. The overwhelming right thing to do would have been to advertise the need to change from bash to dash and put a deadline on it no less than 1/2 a year on notice, THEN make the change. Suddenly unleashing KNOWN breakage like this is unacceptable to me. Such a pity I have to forgo such a good distro in all other respects because of this stupid move by a few devs. Like I say, I no longer trust ubuntu devs not to do something like this again in the future. And yes, breaking trust is a serious bug.

[sparr (sparr0)]

I cannot disagree more. The Ubuntu devs have done a far greater good
here than with any other distro I have used in the past. Being
willing to take steps like this, instead of waiting for optional
compliance that will never happen, is exactly what we need more of.

On 1/23/07, Mark Constable <email address hidden> wrote:
> What worries me about this issue is the attitude of the ubuntu
> developers. I no longer trust the ubuntu devs to do the right thing to
> help me keep the systems I make a living from up and running and am now
> looking at migrating everything to etch+ instead of edgy+. The
> overwhelming right thing to do would have been to advertise the need to
> change from bash to dash and put a deadline on it no less than 1/2 a
> year on notice, THEN make the change. Suddenly unleashing KNOWN breakage
> like this is unacceptable to me. Such a pity I have to forgo such a good
> distro in all other respects because of this stupid move by a few devs.
> Like I say, I no longer trust ubuntu devs not to do something like this
> again in the future. And yes, breaking trust is a serious bug.
>
> --
> Script that are using bash could be broken with the new symlink
> https://launchpad.net/bugs/61463
>

[jharms (juergen-harms)]

It is normal that developers have one point of view and users have another. Somewhere there should be management to pronounce priorities and guidelines.

I trust the competence of developers, but my confidence in management of Ubuntu is severely shaken: if developers develop software, users shout that it does not run, and developers reply that this is normal, management should have something to say.

[Stephen Thorne (jerub)]

It seems that there are two sides to this very interesting debate. I'm going to reiterate a few things that have been said in the verbage above.

Bash is almost posix compliant, but will little eccentricties like options to echo functioning differently - which bash seems to be quite innocent of - as noted, the ''correct'' behaviour was only mandated in the posix spec in '04. And a few more esoteric things. Echo is my major concern, and seems to have caused the most breakage.

We have a refusal to acknowledge that breaking software is a bad thing from the developers who have admin access.

As noted, if a script needs to be fast, #!/bin/dash can be used. Boot scripts should probably do that instead of relying on #!/bin/sh. Why aren't they doing this already?

A quick summary of reported problematic pieces of software, so you don't have to trawl through the above (please comment if I miss anything):
 - limewire
 - intel compiler
 - cedega
 - glibc makefiles (!?)
 - autoconf (?)
 - vmware
 - mathematica
 - nx server

I have an honest question. Do the ubuntu pbuilder machines have /bin/sh as bash or dash? How are we building packages if autotools and makefiles are breaking?

[Mark Constable (markc)]

@sparr: "The Ubuntu devs have done a far greater good here than with any other distro I have used in the past."

Then you and the ubuntimati don't have a real world clue between you all. I manage dozens of servers with 100s of shell scripts each, some dating back 10 years, half authored by me, half not. I have a choice, do I edit all these scripts (1000s!!!), do I self maintain a hacked /bin/sh link to /bin/bash, or, do I assign my future to another distro that I can trust not to put me in this position again? I'm glad I don't manage a really large server farm currently on dapper and needing to move to apache2.2.

What really gets me is the attitude of people like you that don't care about the pain this move inflicts on however many *ubuntu* users when there is no need for it... you guys could have EASILY used #/bin/dash where YOU need it and notified the community that there was a fundamental change coming in the next release... look out, beware etc.

I, for one, am not going to let you people screw me over like this again. You've had your chance to encourage me to use your distro and you've blown it. My remastered distro won't be based on ubuntu as there is no way I would do this kind of thing to my clients and potential users!

Another point you made is almost an insult... you say that for the time some of us here have been complaining about this that we could have spent that time interacting with upstream devs to change their ways. WTF! Ubuntu is/was my upstream provider, you folks are the ones that should be doing double duty to interact with various upstream sources to bring about a change that YOU have mandated. Not "us". I'm perfectly happy with /bin/sh -> /bin/bash and have no need for your pedantic POSIXisms. I have business to run and need things to just work.

[LionsPhil (lionsphil)]

Mark: It should be noted that, according to his launchpad profile, sparr is not actually an Ubuntu dev. I think the last actual dev to comment on this thread was Matthew Garrett (mjg59), with a "no plans to fix this". Since then, the bug has been rejected (or WONTFIX, to use the more accurate Bugzilla parlance), so I suspect that any comment here is actually being ignored.

Stephen: glibc has been fixed upstream; unfortunately, the real world contains reasons to still use old versions (e.g. funky, cross-compiling build environments). Specifically, 2.3 and down contain this (partial) line in csu/Makefile:
  linux*) version=`(echo -e "#include <linux/version.h>\nUTS_RELEASE"\
Which eventually results in a compile error due to a malformed autogenerated header file. The easy, GNU-specific, fix is to change echo to /bin/echo, which supports the old POSIX flags; the fix the glibc devs have taken is to use printf.

(All "Makefile" breakages I've encountered from this are due to assuming that echo supports flags. Given that GNU echo does, shell builtins which behave differently [and this includes bash's support for "-n", actually] are unhelpfully misleading. Especially as "which echo" won't tell you that it's a builtin in either bash or dash [score one for tcsh there, which does].)

So, sorry if that was misleading. I didn't notice that it was quite such an antiquated version at the time, because the setup process for the environment is, itself, another shell script. (Hurrah. I love digging through tons of script to find out why I can't just get a working ARM compiler.)

[sparr (sparr0)]

On 1/24/07, Mark Constable <email address hidden> wrote:
> I have a choice, do
> I edit all these scripts (1000s!!!), do I self maintain a hacked /bin/sh
> link to /bin/bash, or, do I assign my future to another distro that I
> can trust not to put me in this position again?

Or do you take the simple solution and just "sudo dpkg-reconfigure
dash" and answer the single question "No". Viola, you're back to bash
as /bin/sh, and dont have to "self maintain a hacked" anything.

[LionsPhil (lionsphil)]

Hey, great idea sparr! I've come up with generalisation of that approach, which will also fix any other scripts enountered outside of the Ubuntu enclave: make /bin/sh point to /bin/bash by default, thus applying to systems other than Mark's, and persisting across any future installations. I suggest adding this innovative new feature in time for Feisty.

[David Roberts (david.roberts)]

It's all well and good to say "you don't like it, you fix it yourself" which is exactly what I did within a day of upgrading. However, we're ones who are computer literate enough to actually work out what was happening. The majority of "human beings" that Ubuntu is _meant_ to be targeting are going to have no idea what is going wrong. Let's face it, trying to run makefiles etc is confusing enough for the new user without throwing this into the mix.

[kripken (kripkenstein)]

I was unaware of this issue until just now, when some scripts (Nautilus-Subversion) failed to work (I filed a bug, of course).

Figuring out that this was the issue, with no pre-knowledge of the bash/dash situation, wasted about an hour of my time. So on the one hand I have sympathy for people who wrote comments here requesting that bash be returned as the default.

On the other hand, if indeed the LSB mandates that "sh" be POSIX-compliant, and not bash, then I feel I must support the Ubuntu decision to use dash. If Linux in general has any hope of fixing bug #1, then standards like the LSB are crucial. Short-term breakage is the cost of getting long-term stability - if we don't break things now, they will never be fixed, and the standard will be meaningless.

Just my 2c.

[David Roberts (david.roberts)]

I agree that standards are important, however I don't feel this is the right way to go about things. User's are generally going to go for the easiest solution - which is either:
- change sh to bash after several hours of googling
- give up and switch distros (or even go back to Windows)

[Jeff Schering (jeffsch)]

kripkenstein wrote:
>
> On the other hand, if indeed the LSB mandates that "sh" be POSIX-
> compliant, and not bash, then I feel I must support the Ubuntu decision
> to use dash.

Ubuntu 6.06 is LSB compliant with bash.

http://www.linux-foundation.org/en/Products

Also, from the LSB main page at
http://www.linux-foundation.org/en/LSB:
"The LSB offers a cost-effective way for application vendors to target
multiple Linux distributions while building only one software package."

This too is an interesting read:
http://www.linux-foundation.org/en/Application_Compatibility

In essence, it says that if your app runs on a LSB 3.1 compliant system,
then it will run on LSB 3.2, 4.0, etc. The use of dash might interfere
with that concept.

[kripken (kripkenstein)]

 Jeff Schering wrote:

> Ubuntu 6.06 is LSB compliant with bash.

Sorry if I wasn't clear, I didn't mean that having bash was in the way of being LSB compliant. What I meant was that if both dash and bash fulfill the LSB standard, then I support the decision to go with dash. If the LSB wants to change itself to require bash, then that is fine too, but until then, dash should work.

Although as I said, this is indeed a short-term headache, and I wouldn't roll out Edgy on any computer but my own; I'd stick to Dapper LTS in those cases.

[Dan Delaney (dan-launchpad)]

sparr wrote:
> The Ubuntu devs have done a far greater good here than with
> any other distro I have used in the past. Being willing to take
> steps like this, instead of waiting for optional compliance that will
> never happen, is exactly what we need more of.

While going on a crusade to rid the world of Bashisms is certainly a noble pursuit. It is also a futile one if it only involves one Linux distro. If ALL of the distros decided to make that a priority, then we might get somewhere. But one distro among many isn't going to force that change all by itself, and certainly not by making a sudden switch and telling people after-the-fact that they need to start hounding the developers of other applications to stop using Bashisms.

If the assumption that /bin/sh pointed to bash is a concern for the Ubuntu developers, they should figure out a way to bring it to the attention of the Linux community as a whole that won't seriously diminish the user experience of Ubuntu in the process. The developers of those many applications out there that no longer install correctly on Ubuntu (add Zimbra to that list) aren't going to feel the pain of this decision. The users of Ubuntu will.

And we're not just talking about the so-called "average" or "non-technical" users here. If a developer decides to switch to Ubuntu and then discovers that some of the software he needs to do his job is having problems installing on Ubuntu, he doesn't have time to figure out why. He's gonna come to the conclusion that Ubuntu just isn't as stable as the distro he had been using and he'll switch back to it. And the more people encounter this problem, the more Ubuntu will get a reputation of not working correctly. Somehow I don't think that's the reputation the managment of Ubuntu wants for their distro.

I can certainly sympathize with Mark's loss of faith in the Ubuntu developers for making this decision and forcing this situation upon their users. I'm planning on using Ubuntu more and more for production server and this definitely makes me a bit uneasy about that decision. I don't want to upgrade a production server at some point in the future only to find that a bunch of stuff stops working because the developers made some subtle changes and just didn't care about the fact that those changes would cause a lot of problems for their users.

Nonetheless, Ubuntu is a great distro, and despite this poor decision I for one plan to continue to use it. Luckily it has an easy fix. I hope, however, that the developers will be more careful about changes like this in the future.

--Dan

[dmchugh (d-mchugh)]

Gah!

Trying to fix the world or are we trying to get a copy of Unix running? Well I know a few good hackers and the answer is trying to fix the world damned the rest they will be better for it. Sounds like Unix to me! Ha!

Having said that can we just put the world off for a bit I'm trying to get my own little corner in order at the moment and dont quite have the time to fix the world quite yet.. Perhaps if you fire a flare over the portside and say that Ubuntu is switching to dash before you do. I remember when the virus would not actually do anything to you it just told you, bah yer broken. Companies don't understand the save the world concept they do however understand the need fer speed n the need for stability alla Unix. But as long as we are changing the world Unix is going to be sitting on the back shelf teaching script kiddies the way! At least give the script kiddie the right to know that he is being messed up ahead of time, after all he is trying to find out what the real world is, hes trying unix isnt he?

[Ulrich Lukas (ulrich-lukas)]

I just lost half a day figuring out why several configure scripts who ran perfectly under Dapper are broken in Edgy.

Why isn't there at least a warning or note indicating the changed defaults?

[sparr (sparr0)]

Because there shouldn't be one. There was no warning when the default
X switched from XFree to X.org, because non-broken programs don't know
the difference. There is no warning when upgrading gcc from 2.x to
3.x to 4.x, despite it being well known that that breaks MANY build
processes.

On 2/4/07, Ulrich Lukas <email address hidden> wrote:
> I just lost half a day figuring out why several configure scripts who
> ran perfectly under Dapper are broken in Edgy.
>
> Why isn't there at least a warning or note indicating the changed
> defaults?

[jharms (juergen-harms)]

A provactive reply to a provocative reply: in case you are short of ideas on how to create difficulties to the user who uses the programs he has always used, have you considered withdrawing support for ipv4?

How do you define a "broken program"? Do you consider that Ubuntu should only be used by those who have the knowledge (a) to recognise this kind of problem without spending hours and (b) to fix them?

This discussion creates more harm than the original (bash / dash) problem: it discredits the image of a nice distribution by creating the impression that the distribution does not care about the level of service perceived by the non-specialist user.

[Martin Buchholz (martin-xemacs)]

The use of dash also breaks the (soon-to-be GPL)
Sun Java JDK Makefiles, which have

ECHO = echo -e

(Yes, this is arguably a Sun bug)

6482201: ubuntu 6.10 does not recongnize echo -e
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6482201

The suggestion of reconfiguring /bin/sh to point back
to bash probably works today, but this is not a
reasonable suggestion for real business customers.
Rule #1 of using an operating system is

"NEVER change the operating system as supplied"

(Putting things in /usr/local is OK. Don't ever change
/bin)

Changing /bin/sh to point to a different shell is a
"warranty-voiding" action. Imagine the havoc if
/bin/sh were set to point to /bin/csh.

If the dash experiment is successful, then over time
"dashisms" will appear in various scripts. In fact, what
assurance do users have that Ubuntu developers
don't do this *deliberately*?
Users will only have the choice of having different sets of
broken scripts, depending on how they configure the
/bin/sh symlink.

sparr seems to have a very Ubuntu-centric point of
view. People write scripts and Makefiles to run
on a large variety of Unix systems. Ubuntu is one
of hundreds of such platforms. Because GNU echo,
Solaris echo, bash echo and zsh echo all allow the
"-e" option, it is quite easy for users to assume that
"-e" is standard. It is unfortunate that Unix 2003
forbids echo from having any options. Only the most
masochistic and perfectionistic of us ever consult
the Unix 2003 documentation.

[Justus Pendleton (justus)]

On Thursday 15 February 2007 11:40 am, Martin Buchholz wrote:
> The suggestion of reconfiguring /bin/sh to point back
> to bash probably works today, but this is not a
> reasonable suggestion for real business customers.
> Rule #1 of using an operating system is
>
> "NEVER change the operating system as supplied"

Actually Rule #1 of Real Business Customers is "Don't expect software to work
on platforms it doesn't support". Ubuntu 6.10 is pretty clear about what
software it supports and none of the broken software reported in this thread
claims to work on Ubuntu 6.10. /bin/sh being linked to dash is just one of
many reasons that unsupported software could fail to work on Ubuntu. It would
appear that the Ubuntu devs are content with having some segment of
unsupported software not working on their distribution for what some consider
a gratuitous change. Luckily there is no shortage of Linux distributions so
people who disagree have other options.

[Martin Buchholz (martin-xemacs)]

The change from bash to dash is an example of a
very aggressive change, very different from the
"make it just work" policy that I thought Ubuntu had.
Another example is my recent discovery that the
installed gcc 4 is a prerelease 4.1.2. OSes should
have very good reasons to ship prerelease software
components, and I suspect there is no such good reason
for gcc.

I'm OK with these changes, as long as it is made clear
to users that Ubuntu is an OS suitable for reckless hobbyists,
not real users trying to get real work done.
For example, gentoo makes their attitude pretty clear.

I will probably continue to use Ubuntu on my home machine,
since I am a bit of a reckless hobbyist there myself,
but will recommend NOT using Ubuntu at work, and
will look around for a distribution that values reliability
more for my next at-home experimental install.

[sparr (sparr0)]

On 2/16/07, Martin Buchholz <email address hidden> wrote:
> I will probably continue to use Ubuntu on my home machine,
> since I am a bit of a reckless hobbyist there myself,
> but will recommend NOT using Ubuntu at work, and
> will look around for a distribution that values reliability
> more for my next at-home experimental install.

Something like, say, Ubuntu LTS?

[kripken (kripkenstein)]

> Something like, say, Ubuntu LTS?

Well, if that is so, perhaps Ubuntu should state clearly that only LTS releases are meant to be 100% stable. As it is, Edgy is the first download on ubuntu.com, and no mention is made about it being non-stable in any way (all it says is that Dapper will be supported for longer, not that it is more stable).

[LionsPhil (lionsphil)]

More importantly, "just don't use it [Edgy], then" is /not/ a solution to "it [Edgy] is broken". It rates up there with "you have a compiler" for unhelpfully condescending open-source brush-offs.

One of the very problems with this bug is that it's a reason for people to "just not use it", and switch distros! (Dapper is not a viable alternative because "LTS" apparently means "we'll stop updating it when Edgy comes out".)

[Martin Buchholz (martin-xemacs)]

The curious thing here is that with regard to the
problematic behavior of the echo command, that
"dash" cannot claim to be taking the moral high ground here,
since dash's builtin echo is also not Unix-2003-compliant.

According to
http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html
"Implementations shall not support any options."
but dash's echo supports the (historic BSD) -n option.

There are no Unix 2003 compliant echo commands in
common use!

As that same page says,
"The two different historical versions of echo vary in fatally incompatible ways."

Note also how surprising it is to users that the standard shell's
builtin echo is not compatible with the standard /bin/echo.
The whole point of having the shell providing a builtin
command is to provide a *completely* compatible, but higher performing, replacement for the standard standalone command.
Since dash's echo is incompatible with GNU echo, dash is
not suitable for use as a standard system shell.
(Perhaps dash originated on a system where its builtin
echo was compatible with that system's /bin/echo?)

If Ubuntu persists in its present course of using dash as /bin/sh,
there will be no way to have future reliable Ubuntu LTS
versions, since dashisms will creep in. Users will
merely have the choice of different sets of bugs, depending on
whether they choose /bin/sh to point to /bin/bash or /bin/dash.

[sparr (sparr0)]

I believe that FAR less dashisms will creep in than bashisms have over
time. Just like switching web browsers... A developer who switches
from IE to Firefox has to give up all his IE-isms. He might pick up a
couple of Firefox-isms, but I am almost certain that there will be
less of them and they will be less problematic.

The solution to dashisms is to report them as bugs. Just like you did
for bashisms in the past (you did, right?).

dash *IS* Unix-2003-compliant (on this issue at least). If you read a
couple lines farther down, -n is not an option, it is an operand:
"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."

If every person who has posted to this bug report so far instead took
the time to submit a patch to one bashism-laden project, this would be
a non-problem.

On 2/17/07, Martin Buchholz <email address hidden> wrote:
> "dash" cannot claim to be taking the moral high ground here,
> since dash's builtin echo is also not Unix-2003-compliant.
>
> According to
> http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html
> "Implementations shall not support any options."
> but dash's echo supports the (historic BSD) -n option.
<
> If Ubuntu persists in its present course of using dash as /bin/sh,
> there will be no way to have future reliable Ubuntu LTS
> versions, since dashisms will creep in. Users will
> merely have the choice of different sets of bugs, depending on
> whether they choose /bin/sh to point to /bin/bash or /bin/dash.

[Martin Buchholz (martin-xemacs)]

sparr writes:

-------------------
The solution to dashisms is to report them as bugs. Just like you did
for bashisms in the past (you did, right?).

dash *IS* Unix-2003-compliant (on this issue at least). If you read a
couple lines farther down, -n is not an option, it is an operand:
"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."
-------------------

I missed that. On the other hand, further down it says

"On XSI-conformant systems, if the first operand is -n, it shall be treated as a string, not an option. "

Is Ubuntu an XSI-conformant system?
How would users know?

[Mark Constable (markc)]

> If every person who has posted to this bug report
> so far instead took the time to submit a patch to
> one bashism-laden project, this would be a non-problem.

@sparr, you live in some kind of fairy land. There are millions of bash scripts lying around on the net written over the last 10 years expecting to be used as /bin/sh. Anyone of those scripts could be problematic for an edgy+ system for many years yet to come.

Anyone reading this thread will be savvy enough to fix the problem one way or another but that excludes the 99.99% of users, that apparently this distro is aimed at, with the potential of yet another weird problem that they can't fix.

[David Roberts (david.roberts)]

No matter how many script devs you complain to, there is _always_ going to be a script that contains bashisms. If /bin/sh _absolutely_ has to point to dash, instead of refusing to run scripts with bashisms, why not do something constructive like scanning the script for bashisms, and then running it in bash? Or perhaps even patching dash to do something useful with bashisms when it comes across them, like issuing a warning, instead of just dying for reasons unknown to the user?

[Martin Buchholz (martin-xemacs)]

I agree with Mark Constable's comment above.

In sparr's view of the world, all software is actively maintained
by individuals who are deeply committed to free software
(and especialy the Ubuntu distribution),
and to pedantic adherence to standards.

In the real world.... let's look at my own software, Sun Java.
Every Makefile command is implicitly an invocation of /bin/sh.
There are on the order of 1000 "shell scripts" in Sun Java
Makefiles that invoke "echo -e" through use of a Makefile macro.
Some engineer would have to audit all of those uses to make
sure that those uses are safe with plain "echo" or convert them
to use printf(1). Since the Makefiles belong to different
components, many separate component owners need to
review and approve such a change. This is the kind of
change that engineers have a really hard time getting excited
about. I might be masochistic enough to take this on, but in
most corporate organizations such an unpalatable task will
simply be left undone, unless Ubuntu compatibility suddenly
becomes a high-visibility management issue.

On the other extreme, many projects are left in a dormant state
for many years. I remember gzip going without any releases
for a decade. Even an organization like the FSF is not going
to make all their software "Ubuntu-compatible" any time soon.

Ubuntu's change to dash sends the message
"We don't care about serious users."
Corporations are likely to respond in kind:
"We don't support hobbyist OSes with a history
of making recklessly incompatible changes every release."
which will make Ubuntu less useful for everyone.

As others have pointed out, you can speed up bootup by
making /bin/dash a required component and using /bin/dash
explicitly in the startup scripts.

[sparr (sparr0)]

I could maybe see patching dash to die with an error "This script
contains invalid syntax, try running it with /bin/bash instead of
/bin/sh" when it encounters one of various known bashisms like echo
-e.

On 2/17/07, nemti <email address hidden> wrote:
> No matter how many script devs you complain to, there is _always_ going
> to be a script that contains bashisms. If /bin/sh _absolutely_ has to
> point to dash, instead of refusing to run scripts with bashisms, why not
> do something constructive like scanning the script for bashisms, and
> then running it in bash? Or perhaps even patching dash to do something
> useful with bashisms when it comes across them, like issuing a warning,
> instead of just dying for reasons unknown to the user?
>
> --
> Script that are using bash could be broken with the new symlink
> https://launchpad.net/bugs/61463
>

[probono (probono)]

Why not change all shell scripts in ubuntu to use /bin/dash, and leave
the /bin/sh bash symlink alone? That way, you get the advantages of
dash without breaking 3rd party legacy shell scripts.

[mpts (mpts)]

Well, this BUG really was a surprise. Apparantly the main problem is in ubuntu-devs minds, so the solution is evident: Ubuntu is no more among linux distributions to be recommended.

[Mark Constable (markc)]

@probono, that would be so sensible because they have total control over the scripts that they need to speed up the boot process but no control over the scripts the rest of us use for general maintenance after bootup. Then they could announce that they will enforce such a change to /bin/dash in 6 or 12 months time. In the mean time they could lead an active public campaign to enlighten upstream devs as to the folly of their ways and provide support towards the Ubuntu goal of saving the world from bashisms so they can adopt dash as their overall primary shell.

However, if you have had any interaction with @sparr and the ubuntu devs then you'll notice a very blunt response that it's *your* fault for using bashisms on *your* systems so you need to fix *your* problem. This is the kind of mistake that a semi-closed commercial outfit can make where clean room techies are out of touch with the real world. The Debian and Fedora folks would have a very hard time mandating a change like this.

[shiechka (werchowyna)]

I can see strong arguments for using dash as the default sh, but I find the Ubuntu's devs approach wrong and triggering unnecessary pain to users and Ubuntu's image.

The switch should be a slower process. IMHO it should be initiated as probono at 2007-02-18 14:59:18 explained - ie. start it with using dash explicitely only for Ubuntu's own sh scripts, which are not dependant on any upstream.

Then a message should follow via all the Ubuntu broadcasting channels, and to all the upstreams providing any sh scripts, that bash->dash switch is planned. The message should contain the outline of benefits:

1. examples of speed gain in the first place, based on the experience from uisng dash for Ubuntu own scripts
2. followed by POSIX compliance rationale
3. then with "make the world better" argument as the last one

If possible, spread the word to other ditros and encourage them to join you.

After most upstreams are done with transition, or at least known to be in the process, make the switch. That would hurt much less. Mostly, only third party non mantained software could remain broken. However, thanks to wide promotion and community feedback, those could at least be less surprising for users.

Although I sympathize with those who find 3 and 2 are actually most important, I believe that trying to achieve the goal by "dash or death" approach was absolutely not appropriate. It fixed something, but broke another thing. While if the transition went smoother and more transparently, it could be almost all-wins process and a success story. Ubuntu's image would not worsen, correctness would prevail, less unhappy users.. Evolution istead of revolution, so to speak.

Add GRASS GIS to the list of dash incompatible software. We are working on it. Hopefully soon to be fixed. But did Ubuntu really had to do it the hard way?

[dasdda (dasdda)]

I've wasted about an hour and a half due to VMWare's MUI httpd not working -- because of the dash stupidity. 1 hour = $50 to me. To the self-righteous schmucks who want to force POSIX down everybody's throats: do you realize how much this "decision" is costing the world at large? Think millions of dollars. Yes, you and your likes have managed to reduce the world's aggregated wealth by something like that. Are you proud now?

To everyone else: there's no debate. The economic costs here far outweigh any other concerns. There's no "on the other hand".

If you don't understand simple economics, or want to suggest that somehow because Linux is free, economics don't apply -- please don't reply, go get a clue. Even if one does something as a hobby, time is never free.

[Egil Hasting (egil-hasting)]

I have already moved away from Ubuntum, stopped deploying it on server systems. I am glad this happen before i started using it on production servers here at work.

To me i feel way to unsafe about the developers and their ability to do the right thing (also their strategy)

I second what dasdda said. And find the change and attitude careless. There are other distros which have a way more serious attitude, its sad that ubuntu can't be one of them.

[Andrew Charles (andrew-charles)]

Dasdaa is right on the money - I have wasted a significant amount of time figuring out the problem, and then resolving it, so that software that installs out of the box on other distros works on Ubuntu.

I'm a new Ubuntu user - I switched to it because I need a linux distribution that makes it easy for me to focus on my work, and not on the details of my OS.

If I run into another issue like this, and it turns out to be the result of a similarly elitist decision by developers, I'll be forced to jump ship.

[john mcf (john-mcferran)]

This was a time waster here too ("buildroot" didn't), *no* other distro uses dash as default.
 - the speed issue is bogus, as previously pointed out, no problem in ubuntu scripts shebang'ing dash
 - the choice of bash as login shell and dash as system shell is going to surprise many who expect " . script.sh" and "sh script.sh" to execute similarly.

I submit that this isn't the time to take a "standards-waving" stance but rather to pragmatically accept that folk expect more than a minimally POSIX-almost-compliant shell as standard: otherwise what's next - changing the spelling of HTTP_REFERER to the dictionary-correct HTTP_REFERRER ?

[Stephen Thorne (jerub)]

There hasn't been a comment on this ticket since it was resolved as 'rejected'.

What's the best way of actually bringing the issue to the attention of someone who can resolve this problem? Commenting here isn't helping at the moment.

[Stephen Thorne (jerub)]

In my previous comment i meant, there hasn't been a comment on the ticket by someone from ubuntu's team, or canonical since the bug was rejected. I.e. these comments are falling on deaf ears.

[kripken (kripkenstein)]

Stephen Thorne, you are absolutely right. This discussion should be heard, but apparently isn't.

Perhaps posting on the Ubuntu development discussion list, ubuntu-devel-discuss, is the right venue?

[Mark Constable (markc)]

> This discussion should be heard, but apparently isn't.

They don't care.

> Perhaps posting on the Ubuntu development
> discussion list, ubuntu-devel-discuss, is the right venue?

Yes, please try. Personally, I have voted with my feet and just finished re-installing Debian (etch) on a couple of dozen servers.

[dasdda (dasdda)]

Marc Cuban needs to hear about this. You don't improve the world by holding the users hostages. Otherwise "Linux for human beings" is a joke -- or worse, a scam that cheats us into becoming pawns in someone else's battles, on our time.

This sort of thing has happened way to many times, and now it's time to stop it.

If you have a blog, please write about this topic, and maybe post a link here so we can start linking to each other and get a grassroots thing going.

We should also put together an "ubuntu-fixes" package that reverts broken defaults (coming from politically-inspired decisions, or otherwise). People can simply apt-get install ubuntu-fixes after installing Ubuntu.

If ubuntu-fixes becomes popular, creeps like sparr will be less inclined to take the userbase hostage just to make a statement -- because it won't work anymore.

[Rich Pixley (rich-pixley)]

#!/bin/bash isn't really an alternative. Bash isn't guaranteed to be installed in /bin with that name on all systems.

I agree that any script which uses /bin/sh and relies on any features not present in sysV bourne shell is broken by definition. However, changing this symlink on a global level was a very poor choice in my opinion.

People who want these script problems fixed are the ones who should be running with the non-standard link, not the majority of us. If those folks beat the bushes, expose the problems, and get them fixed, then the link could be changed at some point in the future. As is, things just fail mysteriously.

[dasdda (dasdda)]

Just a common-sense remark: if you are not affected by this bug practically, please don't join the fray to tell us what you think is right theoretically. In exchange, we promise to do the same in the future for whatever annoys the heck out of you.

"In theory, there is no difference between theory and practice. But, in practice, there is." ~ Jan L. A. van de Snepscheut/Yogi Berra

[danmb (danmbox)]

I have written an entry in my blog about this problem:

http://www.omnigia.com/news/2007/03/16/ununtu-dash-bash-controversy/

If you care about this issue, digg it here:

http://digg.com/linux_unix/Ubuntu_make_the_world_a_better_place_by_holding_the_user_base_hostage

and upvote on reddit:

http://reddit.com/info/1aws1/comments

Maybe someone at Canonic hears about this and common sense makes a come-back.

[Victor Hu (victorhu)]

Digg and the likes are useless in my opinion, they are packed with fanboys who have nothing better to do than come out and give their utmost support to the Ubuntu team.

[LionsPhil (lionsphil)]

Ahem. If we want the devs to read this, the least we could do would be to stay on topic.
Blog about how blogs suck in your blog. Let's keep the bug report full of bug information.

On that note, have a rough idea of how widespread echo abuse is:
http://www.google.com/codesearch?hl=en&lr=&q=echo%5Cs%2B-%5Ben%5D

[Martijn Koster (makuk66)]

This just bit me too. One of the xen-tools shell scripts does an "rm tty[^1]", to remove all ttys except tty1, which works in bash, but in dash the result is the opposite: tty1 is removed, and none of the others are.
This silent mis-behaviour then later means you cannot log into your newly-created server later, and you waste lots of time.

Yes, I have reported this upstream, and yes, I'll run "sudo dpkg-reconfigure dash -- No!" on my systems. But I find it ridiculous that Ubuntu is placing its users in this position.

[Matthias Niess (mniess)]

I just stumbled upon this bug report and have to leave my opinion. Especially on the server-side I havily rely on other peoples scripts working correctly. I really appreciate dash on the desktop, but on the server? I was thinking about moving my servers from Debian sarge to Ubuntu 6.06 LTS since some mission-critical software now directly supports it. But one just can't afford to use an OS on mission-critical servers whose developers make decisions like these. Break stuff to make a point. How can you not see that this drives Ubuntu away again from professional environments. BTW: I am aware that LTS still uses bash as a default.

[sparr (sparr0)]

Once again I feel the need to point out that this change is no worse
than upgrading from XFree to X.org, or from GCC2/3 to GCC3/4. Those
changes also "broke"* many existing programs, build processes, and
scripts, but we made them for the greater good.

* "broke" in this context meaning "exposed existing previously-hidden
brokenness in". The changes did not actually break anything (with few
exceptions like posix echo), they simply brought to light problems
that have always existed in those packages.

[kripken (kripkenstein)]

"Once again I feel the need to point out that this change is no worse
than upgrading from XFree to X.org, or from GCC2/3 to GCC3/4."

Well, at least those changes brought many significant benefits with them. The bash->dash switch does not have that advantage, as far as I can tell.

[Micah Cowan (micahcowan)]

AIUI, the change was effected mainly for the substantial execution-time benefits it brings, which are especially considerable for boot-time. "Making a point" was absolutely, certainly not one of the reasons for the change, and suggesting so is silly.

OTOH, I think some more extensive verification, before the switch, of dash's claims to be as POSIX-compliant as possible would have been nice. Personally, I'm miffed by dash's very poor and currently non-conformant implementation of arithmetic expansion, which doesn't handle identifiers properly, among other things. It also lacks POSIX's interactive editing (vi-mode), but that's a far lesser concern.

Regardless: developers can not and should not commit to never breaking any thing in new releases. If you are concerned about production servers, you should of course not be rolling out new software on them before testing them to your satisfaction. Obviously, things should not be "broken" without some compensating benefit, and there is obviously disagreement as to whether the benefit was, indeed, sufficiently compensatory. However, it is arrogance to claim that there /was/ no appreciable benefit, or that it is clear that the benefit was insufficient.

In any case, the decision /has/ been made, along with accompanying quite-large investments of development effort, so I don't see what point is served by complaining about it now, especially on a bug-tracker that is not intended for griping that you don't like how a particular decision had gone.

[Paul Louden (plouden2)]

I've just been bitten by this bug. Once I discovered what it was, I changed /bin/sh to bash, to get the job at hand done. Then I went to the maintainer of the script to see if they cared. Someone around changed to using printf(), which resolved the problems and allowed me to go back to the faster dash (and it makes a significant difference here). If one of them had not fixed the script, my solution would've been to fix it myself.

I think we can all agree, including the Ubuntu maintainers, that perhaps changing it without more explicit warning was not the best plan. But, the whole point of standards is that when changing while maintaining compliance you shouldn't have to expect to give warning. The whole point is that this *shouldn't* have been a problem, but it is one. It's a problem to those people who didn't test before deploying, and it's *caused* by the people who made assumptions in their code (that /bin/sh is bash). You and I both know the rule about assumptions. Ubuntu didn't make an assumption. There are rules for what /bin/sh is supposed to do, and they worked within them.

So, Ubuntu highlighted the problem, though not in the most friendly way. And you're forced to see a conflict between "how people do things" and "how things are supposed to be done." But the solution isn't to continually complain at Ubuntu: The change has been made, and to them it's 'the right thing to do' for multiple reasons.

To those of you who complain about the economics of the situation, because of time: Dash saves time. For some of us it can save many hours per week. And for people like me, who've only encountered one script that dies, fixed that script, and discovered that now it runs in ~10% of the time (a fact of significance considering that it's run quite often, and when it is, I have to wait on the results), perhaps I see the change as not so bad one. Bashims are bad, Dashims are surely bad too. Isms in general. If they'd announced it six months ago, then made the change now, you'd still be complaining because many upstream providers wouldn't have changed. SOMEONE had to take the step, to say 'standards exist, and we should follow them', because it's a battle cry Linux has been shouting at some other people for a long time, and it's pointless if it doesn't live up to it itself. So, you're not going to win them over by complaining, because honestly, your complaints boil down to a lot of whining about how you're more important than the people it *does* benefit, those people who don't know about shell scripts but gain from the speed improvement. Your half hour cost learning how to change to bash, vs the many, many more little savings here and there that *do* add up.

Just accept that the change has been made. They rejected the bug report, which means the *decision* has been made. Pestering them about it is just going to make them angry, and angry people get resentful, and are much less likely to change.

Either come up with rational arguments for doing it (rational beyond 'everybody else does it so you should to' style logic), offer up a better alternative, or accept that you don't get to make decisions about where Ubuntu goes, and get about fixing some...

[chemist109 (chemist109)]

I don't get it. If the devs want faster script execution why not just make the she-bang #!/bin/dash for their scripts? Dash isn't _sh_ any more than bash is. And, dash isn't 100% sh compatible either, is it? I don't know, it seems ridiculous to me to make this change and then just say "suck it up" when numerous things break.

[m5shiv (shiv)]

I just wasted a whole day on this issue. My customer had a number of Perl scripts with the following:

eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}'
  & eval 'exec perl -S $0 $argv:q'
  if 0;
# THE PRECEEDING STUFF EXECS perl via $PATH

These were called via /bin/sh : works fine on centos3, centos4, sles 9, sled 10 but not Ubuntu.

Does someone want to tell me why dash doesn't like this ?

[James Justin Harrell (herorev)]

Since so many people against this change have chimed in with a "me too!" comment, I'd also like to voice my opinion.

Thank you so much for making this change, and for not caving in under pressure to reverse it. Standards are extremely important to me. Anything that pushes developers to be more standards compliant is a big plus for everyone. The number of scripts that claim to only need /bin/sh but really need bash has certainly decreased greatly because of this change, and this situation will only continue to improve.

Software that tries to conform with the wild is doomed to become a festering pile of buggy spaghetti code. Tough decisions like these are needed to prevent software from degrading into an incomprehensible mess of hacks, workarounds, and maintained legacy bugs.

[stevejonasoft (stevejonasoft)]

I am an IBM business integration consultant. I tried to install WebSphere Process Server and Integration Developer on Ubuntu, and had to change /bin/sh to bash to get things to work.

So should I go back and tell IBM that their software sucks?

I can only say that I am shocked by this decision to link /bin/sh to dash. Crazy decision!

So am I now making my Ubuntu system unstable by linking to bash?

[probono (probono)]

Vote on Ubuntu Brainstorm idea #2225 if you are bothered by this.
http://brainstorm.ubuntu.com/idea/2225/

[David Masover (ninja-slaphack)]

Steve, short answer, yes, you should tell IBM that their software sucks. Or, specifically, that it's relying on a very dangerous and WRONG assumption, and that it's trivial for them to fix.

It should not be the distro's job to fix IBM's bugs.

[mugginz (mugginz1)]

Wow, I can't believe that they were prepared to break so much software and waste so many end users time in the interests of being technically correct.

This issue means I cannot wholeheartedly recommend Ubuntu to users anymore.

I've started migrating my systems away from Ubuntu and wont be deploying anymore end user systems with Ubuntu unfortunately.

It's not entirely out of the ordinary to need to install legacy software from time to time and I'm not wanting to open myself up to anymore support calls sprouting from such a silly stance.

[sparr (sparr0)]

http://z1owlxoyjtw.ezacutjupl.com