Ubuntu QA:
BlogBrainstormPackage status
Log in
Ubuntu QA
The Ubuntu community has contributed 12357 ideas, 58479 comments, 1187050 votes

Idea #2225: Make /bin/sh = bash (solves zillions of issues)



up
60
down
Written by probono the 1 Mar 08 at 16:56. Category: System.
Related to: Nothing/Others. Status: New
Description
Although not officially a standard, it has been common practice by most distributions that the /bin/sh link points to /bin/bash.

Ubuntu broke this common practice and links /bin/sh to dash.

This breaks A LOT of 3rd party apps, and causes A LOT of unneccessary trouble and support incidents.

If Ubuntu wants to promote dash, it should change all shell scripts to include a dash shebang. But it should NOT mess with the default /bin/sh link.

DON'T say "it's the script writer's fault when he uses /bin/sh and requires bash". We all know that. Nevertheless, a serious distro should not mess around with things that have become common practice even if wrongly so.

The end result of the current situation is that many things mysteriously work "everywhere but on Ubuntu".

https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/71887
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481

Examples of bugs caused by this:
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/92189
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/105634
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/71887
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/135863
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/128730

Examples of 3rd party apps that break: ATI installer, VMware, Xen, Mathematica, NX Server, MKS, NVC
Tags: (none)

Attachments
bug Bug #71887 : Make /bin/sh configurable with update-alternatives


Duplicates


Comments
probono wrote on the 1 Mar 08 at 17:07
If you vote against this, please give reasons!

Ansible wrote on the 1 Mar 08 at 17:41
I'm not voting against. But from what I understand, dash is supposed to be much faster than bash and this is why ubuntu uses it, for the performance.

probono wrote on the 1 Mar 08 at 17:43
If dash is faster, then the scripts in Ubuntu should be updated to use dash by specifying #!/bin/dash

This way, it can be ensured that scripts that have been verified to work with dash can take advantage of it, while all other legacy scripts still work as expected.

peterjs wrote on the 1 Mar 08 at 19:39
Dash is faster and more sh compliant than bash. You shouldn't be upset that it works everywhere but Ubuntu but rather that your script is broken and Ubuntu is the only distribution that bothered to tell you.

probono wrote on the 1 Mar 08 at 19:45
peterjs, i'm not interested in "who is at fault", I'd just like developers to be more sensitive in not breaking legacy stuff for no good reason. Please read the entire(!) page of bug reports linked above. It will give you a feeling for how much pain this sort of thing produces.

peterjs wrote on the 1 Mar 08 at 20:08
They didn't break legacy stuff, if it was truely legacy it would already be sh complaint. They broke the uses of non sh compatible bash extensions. People shouldn't have been using them in the first place. People got lazy wrote bad scripts, Ubuntu forced them to clean house. I feel no sympathy for them, they should have written correct scripts in the first place.

probono wrote on the 1 Mar 08 at 20:13
Lots of people waste lots of time because of this kind of blaming. Blaming doesn't solve it.

maix wrote on the 1 Mar 08 at 21:31
> If you vote against this, please give reasons!
If your program explicitly needs bash stuff, add #!/bin/bash to it, and go.

> If dash is faster, then the scripts in Ubuntu should be updated to use dash by specifying #!/bin/dash
> This way, it can be ensured that scripts that have been verified to work with dash can take advantage of it, while all other legacy scripts still work as expected.
And what if you want it to run on a system where no dash is installed?
The way it is now is just correct: /bin/sh is a sh compliant shell (either bash or dash or whatever), and if you need bash, you explicitly say it.

peterjs wrote on the 1 Mar 08 at 22:40
There isn't a problem to be solved. People wrote bad scripts, they need to fix them. I'm failing to see what Ubuntu should do about this.

josephcmiller2 wrote on the 1 Mar 08 at 23:56
I didn't even know that Ubuntu was using dash instead of bash until my programs wouldn't configure. I realize that it is MY FAULT for not knowing this and for not knowing that it would break 3rd party configures. I realize that it is MY FAULT that when instead of getting some nice configure output, all I get is some cryptic error message with partial code lines. I realize that it is MY FAULT for thinking that there should at least be some easy way to tell what is wrong or for finding some way to fix it. Next time I'll just use Linux From Scratch so I can know how EVERYTHING is set up.

Now I realize that this is not really my fault, but the fault of the software developers. But I'm the one who has to pay the price. Some resolution on this would be great.

rawsausage wrote on the 2 Mar 08 at 00:33
Ubuntu isn't first one. For instance RedHat has favored KSH for a while. Some have used ZSH.

probono wrote on the 2 Mar 08 at 13:19
> RedHat has favored KSH for a while

And came back to bash! (At least in current editions of Fedora)

aschuring wrote on the 2 Mar 08 at 14:32
I voted against, and most reasons have already been given above: if you use bashisms in your shell scripts, you should use #!/bin/bash as your interpreter.

Bash being the defacto standard on linux (gnu) systems has somewhat obscured the matter, but the issue still the same. It's similar to blaming Sun for including their own compiler, because now all code that relied on gcc-specific extensions doesn't work on Solaris.

A word of advice to scripters: if you use #!/bin/sh as your script interpreter, do not test with bash only! For my testing I use NetBSD's ash, on which dash is based if I remember correctly.

aschuring wrote on the 2 Mar 08 at 14:35
Also, I'll rewrite your last comment:

DON'T say "it's the web developer's fault when he uses IE-only extensions. We all know that. Nevertheless, a serious browser should not mess around with things that have become common practice even if wrongly so.

The end result of the current situation is that many things mysteriously work "everywhere, when on Windows".

martin_buchholz wrote on the 2 Mar 08 at 20:21
I repeat probono's suggestion of reading the many
frustrated comments at

https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463

Of course, standards are a wonderful thing, but...

The set of people who have actually read the
UNIX standard for /bin/sh

http://www.opengroup.org/onlinepubs/009695399/utilities/sh.html

is very small.

Even people such as myself who read standards as a hobby
are unlikely to read the shell standard. Almost all shell
programmers learn by trial-and-error, partly because they
are not doing "serious" programming.

Being a standards geek, I decided to take a look at
this standard.

I was surprised to find this text:

------------------------------------
Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH , ensuring that the returned pathname is an absolute pathname and not a shell built-in.

For example, to determine the location of the standard sh utility:

command -v sh

On some implementations this might return:

/usr/xpg4/bin/sh
------------------------------------

This means that a shebang line of #!/bin/sh
is NOT a standard-approved way to get a standard-conforming
shell; e.g. on Solaris the UNIX shell is
/usr/xpg4/bin/sh (or even /usr/xpg6/bin/sh !?)

There is such a thing as defacto standards.
The reality is that many programs work fine with
Linux /bin/sh (bash) and Solaris /bin/sh,
and yet fail with dash.

dash itself is not completely standard compliant either.
Switching from bash to dash simply replaces one set of
standard non-compliances with others, while causing
Ubuntu users to suffer.

madscientist wrote on the 14 Mar 08 at 17:09
I voted against. Ubuntu should stick to its guns here: it is getting large enough now that 3rd party folks are starting to pay attention, or are being forced to pay attention. We're on the cusp of turning the corner: now is the time to stay stubborn and make a stand for all things right and good! As I mentioned in the launchpad bug, this is akin to the 1980's "all the world's a VAX", or the 1990's "all integers are 32 bits". It's just not true, and it's short sighted, and the longer people bow down to it the longer it will continue and the more pain and suffering we'll have to endure in the future. It's bad enough now: let's stop it here.

A few thoughts regarding some of the other comments:

probono is right that blaming doesn't solve the problem. However, ignoring doesn't solve the problem either. Only solving the problem solves the problem. If you find a problem, you need to report it to the appropriate people (that is, the people that created the problem by writing incorrect scripts) so they know about it and can fix it. And, if they won't fix it when one person reports it, hopefully they'll fix it when lots of people report it.

josephcmiller2 doesn't give enough details to really understand what happened: configure (if he means autoconf generated configure) scripts are the most portable shell scripts existing on the planet: they will work with shells that are much older and much less POSIX compliant than anything you find running on any GNU/Linux platform. That's the whole point. If you're interested in only writing for GNU/Linux and you don't care about portability, why in the world bother with autoconf!?!? Just write it for that platform and save yourself the headaches. If you do care about portability, then you should be happy to have found a portability problem and eager to fix it, rather than blaming the messenger. If an autoconf generated script doesn't work with dash it means that the person who created the configure.ac environment used specialized scripting that doesn't follow the autoconf manual and conventions, and you should report a bug to whomever maintains that package.

martin_buchholz makes some good points but also some that aren't really relevant. Sure the number of people who have read the standard are very small, but so are the number of people who have read the ISO standards for C or C++, and yet when they write illegal code we don't cover it up by providing a compiler which is bug-for-bug compatible with whatever compiler they were using before. Every major new version of GCC emits new warnings or even causes some legacy code I work with to no longer work correctly... and it's almost invariably because of liberties that someone took with C++, which were allowed in older, weaker versions of GCC but no longer. I certainly would never dream of requesting that Ubuntu continue to ship an older compiler just so my broken code will still compile.

The same is true of many other packages: I recently faced a problem where a 3rd party tool didn't work on my Ubuntu box, because it's using a much newer version of glibc and some of the enhancements to headers in /usr/include to be more POSIXly correct broke this older tool. That's not Ubuntu's fault and I'm certainly not going to ask them to revert to less-correct content merely to satisfy this 3rd party tool: the 3rd party has to fix it.

There are plenty of places to learn about how to write portable shell scripts OTHER THAN reading the standard (which is not a tutorial but rather a reference), but even easier is to find a shell which implements POSIX only with no extensions (like dash) and use that... if it runs correctly you're 98% there already.

I do agree with and share martin_buchholtz's dismay that POSIX doesn't define /bin/sh as the canonical place to find a POSIX shell: without this it become impossible to write portable shell scripts at all. I've complained about this many times in the past. Requiring /bin/sh to be a POSIX shell is an extension to strict POSIX, but it's a far cry from requiring that /bin/sh actually be a specific shell, especially one like bash which, while I love it for interactive use, poses problems as well.

And finally, I can't imagine any shell script that "works fine with bash and Solaris /bin/sh, yet fails with dash", much less "many" scripts. Dash is (modulo bugs) POSIX, bash is a superset of POSIX, and Solaris /bin/sh is a subset of POSIX; it doesn't even provide all the features of dash, much less extra features that bash has. What capability shared by Solaris /bin/sh and bash, and omitted by dash, is so popular that "many programs" are using it and failing on Ubuntu?

unimatrix wrote on the 15 Mar 08 at 12:48
+1
A lot of things don't work with dash
Just one simple example:
Copy this to a #!/bin/sh script:
echo $PATH#/
It should print out the PATH variable without the leading slash. But it doesn't work.
When you change the script to $!/bin/bash it works like a charm.

unimatrix wrote on the 15 Mar 08 at 12:51
Well great, I can't post the correct command, because some characters get filtered out.
I really wish I could edit comments...

madscientist wrote on the 18 Mar 08 at 17:09
I don't know why you think that # modifiers in variables don't work in dash: they are POSIX and they _DO_ work. I just started /bin/sh on my Ubuntu 7.10 (Gutsy) box and ran:

echo $_PATH#/_

(replace "_" with open and close curly braces as appropriate) and it worked exactly correctly for me: it removes the leading slash.

Even if it didn't work, that's just a bug in dash; it should be reported (in launchpad, not here) and fixed. There are bugs in bash as well.

grantek wrote on the 30 Mar 08 at 07:30
Voted down:
- sh is a standard
- bash is a standard
- dash is a standard

Pick the standard you want to use, and put it in your script. If you want to use sh because it's more multi-platform (ie. not just standard on linux), then make sure your script is multi-platform.

steve196 wrote on the 7 Apr 08 at 07:27
The attitude shown in the comments above is the main reason, why Linux on the desktop is still around 1%.
If you want to be successful in the real world, you need to think with the mind of a customer, for whom "just do not write scripts like that" is simply no solution, because he is not the one, who wrote those scripts.
It is simple: If it works, then Ubuntu is among the systems that can do it, if it doesn't, then Ubuntu is among the systems, that cannot do it and another distro or Windows is the better choice.


atrick wrote on the 31 May 08 at 01:03
Those who voted this issue down have taken more time writing self-righteous rants than reading about the issues real users have faced because of this problem.

Do you realize how many Ubuntu-haters have been created for each user who takes time to report the problem on a forum such as this?

1. The users who are suffering did not write the "bad" scripts.
2. Even after "bad" scripts are reported, many users will continue to suffer with the original scripts.
3. If you think someone who tested their scripts with every default shell except dash did a poor job at compliance testing, then you are delusional. (Yes, the broken scripts work with bash and solaris /bin/sh. No, they are not bash-specific scripts) Do you test all your scripts with every shell?

Only Ubuntu maintainers have the power to ease the suffering with one small change, and are doing nothing--INSANE.

I'll be a good citizen and vote this idea up, but I will strongly dissuade others from making the mistake I made by installing Ubuntu.

mugginz1 wrote on the 22 Jun 08 at 02:41
I'd like to second atriks' comments whole-heartedly.

I can't believe that now, just when Ubuntu is gaining ground, people want to go around and start breaking packages just for the sake of technical correctness.

Well dash might be faster than bash, but I'd rather my system function that abort quickly and efficiently, and I'm sure the majority of users out there would also.

Is Ubuntu to be an OS for end users, or only programmers who are happy to debug their machines.

This will not help Ubuntu at all in the pursuit of gaining desktop adoption.

Endolith wrote on the 8 Jul 08 at 20:10
It doesn't matter who's at fault. What matters is that this breaks things that people are trying to use and makes Ubuntu look bad.

Put the user experience first.

Log an error in the system if you want, to remind people to change their scripts, but don't break them just to be obtuse.


Post your comment