[proposal] make dash the default shell for boot scripts

ncopa · 2008-06-23 12:09:14

Mr.Elendig wrote:

## man 1 bash

3516 BUGS
3517        It's too big and too slow.
Let's do the init stuff in py and C instead

py? please no!

If you want C, have a look at openrc.

iphitus · 2008-06-23 12:53:18

ncopa wrote:

iphitus wrote:
So far, nobody has been capable of proving that any significant speed gain is attained by using dash instead, nor that this has any practical advantage over bash.
Using dash is not all about speed. The speed is just a bonus.

Nobody has demonstrated any bonus.

The real benefit is that it becomes POSIX compliant.

Using a posix compliant sh for Arch's stock initscripts has no practical reason.

What makes the initscripts so different that they should be implemented in a posix sh syntax compliant language? Gentoo gets by with python, and other distros use bash happily, and others use C (upstart). As far as I'm concerned, posix sh and Bash are different languages. Why rewrite the scripts using posix sh instead of bash?

Those distros that were mentioned in the OP to have moved to sh, are very different distros. Typically in Debian and Ubuntu especially, you're not often messing with initscript level configuration files - like things we do in rc.conf (and ubuntu at least is moving to upstart). Whereas in Arch, you're messing with config files and initscript level things more frequently. Bash makes more sense. To move to a different language for the scripts means dumping bash arrays, and other bash features, which make rc.conf easier, and keep the code behind the scripts simple and easy for people to work with. That's a feature of Arch. That's a practical reason for using bash.

Arch is light and simple. Perfect for building an uclibc distro on (I do this kind of stuff). Unfortunally, bash is too bloaty.
Get rid of bloat, gain speed and be portable is a win. Sure, you don't switch over night, but it is possible.

A uclicbc distro would mean everything would be compiled from scratch, with many significant changes -- effectively a fork of Arch. If someone's willing to spend the time to maintain such a fork, I'm sure they're willing to spend the time to apply some patches to initscripts.

carlocci: changing to sh does not make the scripts any more 'standard'. There's no such thing as standard initscripts and no standard language to use for initscripts.

Last edited by iphitus (2008-06-23 12:56:43)

lloeki · 2008-06-23 13:14:26

which make rc.conf easier

don't want to put fuel on the fire, but how much easier? to me

daemons="foo bar baz"

and

daemons=(foo bar baz)

are strictly equivalent (except for space in names, which is unlikely anyway)

as for why I like the idea, maybe it has roots years ago when my gentoo machine becoming b0rked just because bash went FUBAR for some reason. also I like the idea of initscripts (eg rc.conf) being coherent with initcpio (mkinitcpio.conf) stuff. besides, making the core of the system rely on the minimal set of code is interesting in itself, although one might argue that anyway part of it would end up relying on bash and part of it on sh. yet I don't want it to become the default first thing tomorrow, if ever. I want it and its migration to be reliable first.

ncopa · 2008-06-23 14:34:12

iphitus wrote:

ncopa wrote:
iphitus wrote:
So far, nobody has been capable of proving that any significant speed gain is attained by using dash instead, nor that this has any practical advantage over bash.
Using dash is not all about speed. The speed is just a bonus.
Nobody has demonstrated any bonus.

dash is faster, but thats not the point.

What makes the initscripts so different that they should be implemented in a posix sh syntax compliant language? Gentoo gets by with python, and other distros use bash happily, and others use C (upstart). As far as I'm concerned, posix sh and Bash are different languages. Why rewrite the scripts using posix sh instead of bash?

Gentoo is in the process of switching from bash arrays in config files to posix compilant config. They used to have bash arrays there too but those got replaced.

No. You dont need python to boot a gentoo system.
Yes you can boot gentoo with busybox. I do it. Gentoo have lots other issues but thats another question.

Those distros that were mentioned in the OP to have moved to sh, are very different distros. Typically in Debian and Ubuntu especially, you're not often messing with initscript level configuration files - like things we do in rc.conf (and ubuntu at least is moving to upstart). Whereas in Arch, you're messing with config files and initscript level things more frequently. Bash makes more sense. To move to a different language for the scripts means dumping bash arrays, and other bash features, which make rc.conf easier, and keep the code behind the scripts simple and easy for people to work with. That's a feature of Arch. That's a practical reason for using bash.

The Arch initscript uses very few bash specific features. Only thing is the array style in conf and that is just cosmetical. A matter of taste and keep what people are used to do. bash makes sense in some situations but this initscripts in arch is not one of those.

Arch is light and simple. Perfect for building an uclibc distro on (I do this kind of stuff). Unfortunally, bash is too bloaty.
Get rid of bloat, gain speed and be portable is a win. Sure, you don't switch over night, but it is possible.
A uclicbc distro would mean everything would be compiled from scratch, with many significant changes -- effectively a fork of Arch. If someone's willing to spend the time to maintain such a fork, I'm sure they're willing to spend the time to apply some patches to initscripts.

I have 300-400 packages in my uclibc distro and no, you are wrong. You really don't want to apply patches unless you really need to. And when you patch you send patches upstream.

It is possible to make Arch's scripts compatible with posix and I posted a patch in the other thread. They are even compatible with bash so your rc.conf with bash arrays will still work. I'm not just talking. I'm willing to help you make it happen, but if there is no interest, thats fine for me. I will not fight for working for you for free.

ncopa · 2008-06-23 15:02:04

lloeki wrote:

which make rc.conf easier
don't want to put fuel on the fire, but how much easier? to me
daemons="foo bar baz"
and
daemons=(foo bar baz)
are strictly equivalent (except for space in names, which is unlikely anyway)

Correct. The difference is close to zero. You avoid things like though:

daemons=('foo' 'bar' 'baz')

The current way the arrays is implemented don't allow space in names anyway. If you only want one array here and there you can use 'set' to simulate arrays eg.

set "foo" "bar" "baz with space"
for i in "$@"; do
  ...
done

So the only real reasons to use arrays is when you need nested arrays with spaces and similar.

as for why I like the idea, maybe it has roots years ago when my gentoo machine becoming b0rked just because bash went FUBAR for some reason. also I like the idea of initscripts (eg rc.conf) being coherent with initcpio (mkinitcpio.conf) stuff. besides, making the core of the system rely on the minimal set of code is interesting in itself, although one might argue that anyway part of it would end up relying on bash and part of it on sh. yet I don't want it to become the default first thing tomorrow, if ever. I want it and its migration to be reliable first.

phrakture · 2008-06-23 17:07:36

Cripes people, this has come up hundreds of times. I'm going to break it down for you.

I will not do this because I think it's a stupid idea. Stop holding your breath for arch to have dash initscripts, it won't happen.

You are all more than welcome to do this yourself. It's not hard. It's just dumb. Go ahead and do it, post some patches, put a package in the AUR, do something - but we won't

crouse · 2008-06-24 00:19:18

ncopa wrote:

Using dash is not all about speed. The speed is just a bonus. The real benefit is that it becomes POSIX compliant.
Arch is light and simple. Perfect for building an uclibc distro on (I do this kind of stuff). Unfortunally, bash is too bloaty.
Get rid of bloat, gain speed and be portable is a win. Sure, you don't switch over night, but it is possible.

man bash

       If  bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as
       possible, while conforming to the POSIX standard as well.  When invoked as an interactive login shell, or a  non-inter-
       active  shell with the --login option, it first attempts to read and execute commands from /etc/profile and ~/.profile,
       in that order.  The --noprofile option may be used to inhibit this behavior.  When invoked as an interactive shell with
       the  name  sh,  bash looks for the variable ENV, expands its value if it is defined, and uses the expanded value as the
       name of a file to read and execute.  Since a shell invoked as sh does not attempt to read and execute commands from any
       other  startup  files,  the  --rcfile  option has no effect.  A non-interactive shell invoked with the name sh does not
       attempt to read any other startup files.  When invoked as sh, bash enters posix mode after the startup files are  read.

       When  bash is started in posix mode, as with the --posix command line option, it follows the POSIX standard for startup
       files.  In this mode, interactive shells expand the ENV variable and commands are read and executed from the file whose
       name is the expanded value.  No other startup files are read.

Thank goodness Arch won't be messing up tons of ancient scripts just to appease a few people. Bash has worked for years, and is still a better shell than dash, plus, I guess I never thought of using Arch as an embedded distro. (the major reason for uclibc distro) Just mho though.

When invoked as sh, bash enters posix mode after the startup files are read. Glad to hear from the boss things won't be changing.

Last edited by crouse (2008-06-24 00:19:59)

LTSmash · 2008-06-24 02:52:09

phrakture wrote:

Cripes people, this has come up hundreds of times. I'm going to break it down for you.
I will not do this because I think it's a stupid idea. Stop holding your breath for arch to have dash initscripts, it won't happen.
You are all more than welcome to do this yourself. It's not hard. It's just dumb. Go ahead and do it, post some patches, put a package in the AUR, do something - but we won't

And if this showed up that it is worth the work and it's functional, if we say "the proyect has got mature", then would you change your opinion, or not?

Allan · 2008-06-24 02:58:34

LTSmash wrote:

And if this showed up that it is worth the work and it's functional, if we say "the proyect has got mature", then would you change your opinion, or not?

Well, most thing like this never get to that stage and thus we don't have prior situations to base this answer on. So, the answer is "possibly".

ncopa · 2008-06-24 06:11:09

crouse wrote:

ncopa wrote:
Using dash is not all about speed. The speed is just a bonus. The real benefit is that it becomes POSIX compliant.
Arch is light and simple. Perfect for building an uclibc distro on (I do this kind of stuff). Unfortunally, bash is too bloaty.
Get rid of bloat, gain speed and be portable is a win. Sure, you don't switch over night, but it is possible.
man bash
       If  bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as
       possible, while conforming to the POSIX standard as well.
Thank goodness Arch won't be messing up tons of ancient scripts just to appease a few people. Bash has worked for years, and is still a better shell than dash, plus, I guess I never thought of using Arch as an embedded distro. (the major reason for uclibc distro) Just mho though.
When invoked as sh, bash enters posix mode after the startup files are read. Glad to hear from the boss things won't be changing.

You don't get it. Bash will contiue work if you make scripts posix compliant, just like your manpage states. You could even use your arrays in your rc.conf if you wanted. This is not about forbidding people using bash. Its about allowing people pick another shell if they want.

cactus · 2008-06-24 07:12:17

hahahhahaha

oh man. this thread is hilarious.

iphitus · 2008-06-24 10:25:43

ncopa: You're rewriting the initscripts in a different programming language. You might as well just write them in fortran, i don't care - you don't have a sound technical reason for the change.

uclibc: Maintain your own initscripts. If you're rebuilding 300 or more packages (an Arch fork), you can trivially maintain your own initscripts.
speed: Nonsense, nobody has proved any relevant speed increase
fuzzy wuzzy posix cosy factor: wooo!

Wish my coffee looked like that.

Last edited by iphitus (2008-06-24 10:29:30)

lloeki · 2008-06-24 11:53:48

I'm not arguing for inclusion or something. an aur package comprised of a patch to current initscripts serves me just as well.

for some usefulness, no need to look for embedded or uclibc. arch is a perfect candidate for good old PIIs (i686) with few ram (I have some which won't boot with more than 256Mb, and many have only 64Mb fitted). in this situation, each Mb counts. that's why we like to use awesome/openbox/rxvt/abiword/gnumeric there... it makes a perfect recycled desktop.

stupid htop output:

PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command 
 6794 lloeki    20   0 15396  1652  1208 S  0.0  0.2  0:00.00 bash -c read a
 6830 lloeki    20   0   260   104    80 S  0.0  0.0  0:00.00 dash -c read a

look at virt, res, shr.

toofishes · 2008-06-24 12:21:24

The legitimate (and something that may need fixing) gripe here is that an Arch system can't boot unless /bin/sh is symlinked to /bin/bash (e.g. it fails with /bin/dash). I don't know if this is still true, but at one point it was so fixing that issue is legitimate. This is separate from making every startup script on an Arch system run under non-bash sh.

iphitus · 2008-06-24 13:11:49

toofishes wrote:

The legitimate (and something that may need fixing) gripe here is that an Arch system can't boot unless /bin/sh is symlinked to /bin/bash (e.g. it fails with /bin/dash). I don't know if this is still true, but at one point it was so fixing that issue is legitimate. This is separate from making every startup script on an Arch system run under non-bash sh.

Shouldn't the shebang for rc.sysinit cause the scripts to be run using bash? (presently it's #!/bin/bash) Otherwise you could change /etc/inittab to read: "/bin/bash /etc/rc.sysinit"

lloeki: I had a Pentium 2 running Arch. Using dash for initscripts instead of bash would do nothing though, as the boot isn't ram limited, it's hard drive and CPU limited -- ram isnt an issue. initscripts run at boot and then no longer. Nobody has yet proved any relevant difference in cpu usage either.

Last edited by iphitus (2008-06-24 13:19:28)

Mr.Elendig · 2008-06-24 14:17:01

With initscripts with loads of large for loops, then it would make a differece, but even on a for loop with 10k executions, the difference is way less, that what you could achive with using external compiled apps instead.
In most cases stripping down the udev rules, and playoing around with the modules and daemons array, will have a bigger impact than switching to dash.

Edit: Dash's for loop might be 6 times faster , but, the loops in the init script are so few, and quite short, so in the end you won't get a nopticable speedup.
http://www.pixelbeat.org/programming/sh … takes.html > This page shows some examples on bash vs dash speed, but notice how mutch faster the use or core tools are.

Last edited by Mr.Elendig (2008-06-24 14:21:20)

phrakture · 2008-06-24 16:04:01

LTSmash wrote:

phrakture wrote:
Cripes people, this has come up hundreds of times. I'm going to break it down for you.
I will not do this because I think it's a stupid idea. Stop holding your breath for arch to have dash initscripts, it won't happen.
You are all more than welcome to do this yourself. It's not hard. It's just dumb. Go ahead and do it, post some patches, put a package in the AUR, do something - but we won't
And if this showed up that it is worth the work and it's functional, if we say "the proyect has got mature", then would you change your opinion, or not?

Yes, absolutely. Please change my mind. Please convince me. I am not being snarky, I am being 100% serious here.

crouse · 2008-06-25 01:01:29

https://bugs.launchpad.net/ubuntu/+sour … +bug/61463
Worth reading imho, I realize that 99% of the Arch users would probably be able to handle a minor issue like this, but I found it revolting that Ubuntu that claims to be the "most user friendly" broke countless scripts in servers and desktops......and while I know how to fix these minor problems, many using Ubuntu were scratching their heads. For the life of me, I could not see how it benifitted them to switch from bash to dash. Some philisophical point to make, to stay debian compatible, idk.

I understand that the pro-dash people say "It's not our problem, the scripts are written wrong in the first place and all of them need to be fixed......" ......... me, I live in the real world, and I don't think it's nearly as easy to get 1,000's of scripts and their creators to the same mindset as it is to simply leave bash as the default..........call me silly.

Last edited by crouse (2008-06-25 01:02:17)

lloeki · 2008-06-25 07:28:20

altered your statement a bit:

I understand that the pro-linux people say "It's not our problem, the software is written wrong in the first place and all of it need to be fixed......" ......... me, I live in the real world, and I don't think it's nearly as easy to get 1,000's of software and their creators to the same mindset as it is to simply use windows as the default..........call me silly.

okay I got far, but it's the idea. not because everybody does it means that it's what should be done.

I truly understand phrak&iphitus PoV, and they are right in what they say: initscripts are currently run as #!/bin/bash and it is a different (albeit very near, almost a superset) language. they chose bash as a language, and they do it the right way.
what you say is different from what people are arguing on this thread: you say that we should always assume #!/bin/sh == #!/bin/bash, and use bashisms in sh scripts, and thus have sh->bash symlink, because hey, everybody does it. which is just plain wrong because it advertises use of the wrong language (which is what a shebang is about), and this is why patches have already been applied here in Arch to change #!/bin/sh to #!/bin/bash.

also I can't believe that people can say this:

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.

we're using computers. computers are dumb, computing machines. being technically correct is what matters. if you stray from that, you bring in ambiguity, and you're in for loads of problems, and that's precisely what happens. people writing bashisms in sh scripts were technically incorrect, and things started to break when they and their users were confronted with software made by people that were (in their right mind) assuming correctness.

as for 'the most user friendly', it is in the end, as when opening a file #!/bin/sh MEANS one thing: it IS a posix sh script and bashisms are forbidden, and #!/bin/bash IS and MEANS bash is used, and bashisms are allowed, which is all unrelated to sh symlink to bash or whatever. besides, when one writes a script, one may like having syntax highlighting, and I'm pretty sure #!/bin/sh won't make bashisms highlighted correctly in many editors, which is right, because it's not the correct language.

Last edited by lloeki (2008-06-25 07:38:09)

crouse · 2008-06-25 14:39:43

I get it, but like I said, I also live in the real world......... it would be similar to Firefox all of the sudden refusing to load incorrectly coded webpages...

toofishes · 2008-06-25 16:14:00

Mr.Elendig wrote:

With initscripts with loads of large for loops, then it would make a differece, but even on a for loop with 10k executions, the difference is way less, that what you could achive with using external compiled apps instead.
In most cases stripping down the udev rules, and playoing around with the modules and daemons array, will have a bigger impact than switching to dash.
Edit: Dash's for loop might be 6 times faster , but, the loops in the init script are so few, and quite short, so in the end you won't get a nopticable speedup.
http://www.pixelbeat.org/programming/sh … takes.html > This page shows some examples on bash vs dash speed, but notice how mutch faster the use or core tools are.

It isn't the for loop where the big savings occur; the savings come when you have a bunch of forked processes using /bin/sh. dash will load up and start running faster than bash in this case. Udev forks off a shell for each piece of hardware or module, so that can get expensive.

lloeki · 2008-06-25 18:41:45

I get it, but like I said, I also live in the real world......... it would be similar to Firefox all of the sudden refusing to load incorrectly coded webpages...

in fact it really does shit with broken web pages, esp. with javascript. it's just that people coding for that other broken browser started coding respecting standards, and standards defines a quirks mode with relaxed checks. ten years ago, that battle was fought, people were arguing that IE was the Rule because it was everywhere, but w3c won. nowadays w3c defines html and css, and screw IE (which is trying to push silverlight and wmv the same way as before, hopefully w3c will make theora part of html5). yet remnants of this era exists, and you can see them when you try to embed some flash or java thing, there are two ways of doing it, the IE way (embed tag) and the Netscape way (object tag) (or is it the other way around?), and both are ignored by the other, thanks to the fact that html is defined to ignore unknown tags (but if it was not for that, for sure they would bark). I certainly don't like to see what the web would have been like if it was microsoftish...

well, sorry for the OT.

Last edited by lloeki (2008-06-25 18:42:09)

lloeki · 2008-06-25 18:46:52

back to the subject.

about shell spawning, this is interesting.

I hear the '100000' factor already. fact remains that bash starts 2* slower, and eats 10* the memory. in the end I'd like to know if it matters on initscripts, but I'll have to wait: job's taking a fair share of my time.

damjan · 2008-07-17 15:12:56

for me the best feature of dash is that it's statically linked.. so even in the case of a major fuck-up with some of the libraries much of my system will still work. That's a definitive plus.

Now, as I understand, this thread is not about changing from bash to dash, but about making small corrections in the Arch scripts so that they could run with dash (or even with other shs?) so that people could choose.

How big is this work?

carlocci · 2008-07-17 16:25:46

damjan wrote:

for me the best feature of dash is that it's statically linked.. so even in the case of a major fuck-up with some of the libraries much of my system will still work.

yeah, let's say a disaster happened and my glibc packet disappeared and miracolously the bootscripts didn't rely on mount, ln, modprobe, mkdir and every other external program.
I would have a good dash prompt to work with!
I could edit some configuration files with vim NOT
I could cp NOT the libc back from a mounted NOT usb pen
I could install glibc with pacman NOT

Arch Linux

#26 2008-06-23 12:09:14

Re: [proposal] make dash the default shell for boot scripts

#27 2008-06-23 12:53:18

Re: [proposal] make dash the default shell for boot scripts

#28 2008-06-23 13:14:26

Re: [proposal] make dash the default shell for boot scripts

#29 2008-06-23 14:34:12

Re: [proposal] make dash the default shell for boot scripts

#30 2008-06-23 15:02:04

Re: [proposal] make dash the default shell for boot scripts

#31 2008-06-23 17:07:36

Re: [proposal] make dash the default shell for boot scripts

#32 2008-06-24 00:19:18

Re: [proposal] make dash the default shell for boot scripts

#33 2008-06-24 02:52:09

Re: [proposal] make dash the default shell for boot scripts

#34 2008-06-24 02:58:34

Re: [proposal] make dash the default shell for boot scripts

#35 2008-06-24 06:11:09

Re: [proposal] make dash the default shell for boot scripts

#36 2008-06-24 07:12:17

Re: [proposal] make dash the default shell for boot scripts

#37 2008-06-24 10:25:43

Re: [proposal] make dash the default shell for boot scripts

#38 2008-06-24 11:53:48

Re: [proposal] make dash the default shell for boot scripts

#39 2008-06-24 12:21:24

Re: [proposal] make dash the default shell for boot scripts

#40 2008-06-24 13:11:49

Re: [proposal] make dash the default shell for boot scripts

#41 2008-06-24 14:17:01

Re: [proposal] make dash the default shell for boot scripts

#42 2008-06-24 16:04:01

Re: [proposal] make dash the default shell for boot scripts

#43 2008-06-25 01:01:29

Re: [proposal] make dash the default shell for boot scripts

#44 2008-06-25 07:28:20

Re: [proposal] make dash the default shell for boot scripts

#45 2008-06-25 14:39:43

Re: [proposal] make dash the default shell for boot scripts

#46 2008-06-25 16:14:00

Re: [proposal] make dash the default shell for boot scripts

#47 2008-06-25 18:41:45

Re: [proposal] make dash the default shell for boot scripts

#48 2008-06-25 18:46:52

Re: [proposal] make dash the default shell for boot scripts

#49 2008-07-17 15:12:56

Re: [proposal] make dash the default shell for boot scripts

#50 2008-07-17 16:25:46

Re: [proposal] make dash the default shell for boot scripts

Board footer