Re: Bugs in bash (was: Release-critical Bugreport)
Hi,
On Sat, 29 May 1999, Edward Betts wrote:
> The other question does Debian support or advocate the changing of the
> /bin/sh link? There are still lots of scripts that need bash but say
> they need sh could break some things.
There are quite a few people who have ash as their /bin/sh and their
systems seem to be working reasonably well. My work machine has /bin/ash
for /bin/sh for months and I still have my job...
In fact, I've had more trouble from bash at times when it decided to have
a fight with libreadline, causing _major_ breakage, than the occasions
where one insignificant script had a silly bash problem (yes a "bash
problem", not an "ash problem" IMHO), which in 98% of the cases consists
of the use of the keyword "function" to declare a function.
Only few packages still show "bashist" tendencies, only very obscure and
seldom used packages and newly packaged ones. Both get bugs submitted if
a "bashism" is found and up till now all of those have been fixed swiftly
by their maintainers.
..
On Sat, 29 May 1999, Steve Greenland wrote:
> As far as I know, no one has replaced /bin/sh with something besides
> bash (ash, for example) *and* reported back sufficiently positive
> results to allow us to change the default /bin/sh to something smaller
> than bash. Given that bash must be present on the system, the only
> clear incentive to change /bin/sh to something smaller is start up
> time, which is non-trivial during the boot process.o
Please accept my affidavit then. I've been running several machines with
/bin/sh -> /etc/alternatives/sh -> /bin/ash with good results.
Bash not only takes considerable time to start up, it also takes a lot of
memory to run. I have a lowly 386sx20 that I use as a ip-masqerading
router where /bin/bash or /bin/ash makes more than something of a
difference.
> I think that's a fair summary of the bash vs. sh situation.
> Theoretically, we support non-bash /bin/sh, but I'd hardly say we
> advocate it. As a practical matter, I'm sure there are a bunch of
> standard scripts that are screwed up. I'm even more positive that on a
> true multi-user system, there are tons of user written scripts that
> assume /bin/sh is bash.
The standard scripts are _not_ screwed up. Just try it and see for
yourself. If any standard scripts ever had problems with a non-bash
/bin/sh, it has been fixed long since. Many people run systems with
non-bash /bin/sh and would notice soon enough if any standard script
broke.
I see no inherent or logical relation between a true multi-user system and
ill-found assumptions in user scripts that /bin/sh has bash capabilities.
IMHO such scripts are simply broken and in al cases fixed equally simply.
..
On Sun, 30 May 1999, Marco d'Itri wrote:
> On May 29, Thomas Quinot <thomas@Cuivre.FR.EU.ORG> wrote:
>
> > Why not manage /bin/sh using alternatives? This would seem very
> > natural.
>
> An hosed system could lose /etc.
Sure, and it could lose /bin and /sbin just as well. The particular case
of /etc going down the drain is not a very good argument IMHO.
..
On Sat, 29 May 1999, Thomas Quinot wrote:
> Why not manage /bin/sh using alternatives? This would seem very natural.
Some people would argue that since /etc/alternatives is managed by
update-alternatives, which is a perl script, the alternatives mechanism is
a long chain with too many possibly weak links to allow a vital part of
the system like /bin/sh to depend on it.
I think there is a lot of sense in this reasoning, but I can't quite agree
on the strength of the argument as long as a breaking perl stands a good
chance of wrecking a most of the system anyway. There is AFAIK no clear
policy or even consensus about standards for guaranteed operation of
various "considered critical" parts of the system. If update-alternatives
cannot be trusted because perl can't be, then there might somehow be a lot
of other vital scripts that should be scrutinized on the same grounds.
If we must have /bin/sh to be a guaranteed stable symlink, then I'd rather
like to see Debian using /bin/ash for /bin/sh.
It is my experience that this works just fine with all of the standard
scripts. Only occasionally a "bashism" bug is found in a newly introduced
package and such packages are generally not standard packages anyway. On
the positive side, ash is much more lightweight than bash and also less
prone to breakage caused by other packages (just think "readline".)
Also, in principle, if none of the basic scripts do need bash, then an
embedded Debian machine with no users or other reason to need a featureful
interactive shell can refrain completely from having bash. One of the
features of Debian compared to other distributions is the ability to strip
the system to its bare-bones in a relatively simple and controlled manner.
Cheers,
Joost
Reply to: