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 deployi
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.
--
Script that are using bash could be broken with th
Vote on Ubuntu Brainstorm idea #2225 if you are bothered by this.
http://brainstorm.ubuntu.com/idea/2225/
--
Script that are using bash could be broken with the new symlink
https://bugs.launchpad.net/bugs/61463
You received this bug notification because you are a member of Ubuntu
Bugs, which is s
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
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 sta
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
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
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 d
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,
"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.
--
Script that
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 ex
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 so
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-creat
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%5
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.
--
Script that are using bash could be broken with the new symlink
https://launchpad.net/bugs/61463
--
ubuntu-bugs mailing lis
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://
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
#!/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 w
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'
> 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 d
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?
--
Script that are using bash could be broken with the new symlink
https://launchpad.net/bugs/614
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.
--
Script that are using bash could be broken with the new symlink
https://launchpad.net/bugs/61463
--
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.
--
Script that are using bash could be broken with the new sym
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
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
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
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 u
@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 o
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.
--
Script that are using bash could be broken with the new symlink
https://launchpad.net/bugs/61463
--
ubuntu-bug
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.
--
Script that are using bash could be broken with the new symlink
https://launchpad.net/bugs/61463
--
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 PROTECTED]> wrote:
> No matter how many script devs you complain to,
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 soft
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
> 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 e
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
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
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
"
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 swit
> 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 suppor
On 2/16/07, Martin Buchholz <[EMAIL PROTECTED]> 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
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 softwar
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 syst
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
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 t
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
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?
--
Script that are using bash could be broken with the new symlink
https://launchpad.net/bugs/61463
--
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
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
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 ch
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
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)
--
Scri
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
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
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
On 1/24/07, Mark Constable <[EMAIL PROTECTED]> 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
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 Bugzi
@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
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 - a
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
t
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 <[EM
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
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.
--
Script that are using bash could be broken with the ne
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.
--
Script that are using bash could be brok
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
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 co
"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-upg
"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 correctnes
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-u
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
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
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
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 pr
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 c
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
o
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 m
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 PROTECTED]> wrote:
> Because getting large groups of people to fix software
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
$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.
--
Script that are using bash
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
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
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
> "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
"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,
Dash is terrible. The fact is in the majority of cases it fails
miserably. Please change the default back to bash.
--
Script that are using bash could be broken with the new symlink
https://launchpad.net/bugs/61463
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.co
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 /b
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.
** Changed in: dash (Ubuntu)
Importance: Undecided => Wishlist
Status: Confirmed =>
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 ther
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
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.
--
Script that are using bash could be broken with the new symlink
https://la
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 PROTECTED]> wrote:
>
> Suggested resolution:
>
>
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 p
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 exemp
Small beer compared with the problems above, but it also breaks
Limewire's runLime.sh
--
Script that are using bash could be broken with the new symlink
https://launchpad.net/bugs/61463
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bug
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'
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.
--
Script that are using bash could be broken with the new symlink
https://launchpad.net/bugs/61463
--
ubuntu-bugs mailing list
ubunt
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.
** Changed in: dash (Ubuntu)
Status: Unconfirmed => Confirmed
--
Script that are using bash could be broken with the new symlink
htt
96 matches
Mail list logo
