[arch-general] dash as default shell?
Today I set dash as my default shell [1] on two PCs. We will see if I get into trouble. This question was asked years ago but maybe good to ask again. Could dash be made the default shell in Arch? I did some simple benchmarks and dash is much faster than bash, moreover being far smaller there is less chance of bugs. A possible issue is bashisms, however Ubuntu has been using dash as default for 14 years and Debian also for several years so hopefully most scripts have had bashisms removed by upstreams. What do you think? [1] https://wiki.archlinux.org/index.php/Dash#Use_DASH_as_/bin/sh
On 6/17/20 2:18 PM, Piscium via arch-general wrote:
Today I set dash as my default shell [1] on two PCs. We will see if I get into trouble.
This question was asked years ago but maybe good to ask again. Could dash be made the default shell in Arch?
Couldn't you just set it as the default for your user using chsh? DR
On 6/17/20 2:36 PM, David Rosenstrauch wrote:
On 6/17/20 2:18 PM, Piscium via arch-general wrote:
Today I set dash as my default shell [1] on two PCs. We will see if I get into trouble.
This question was asked years ago but maybe good to ask again. Could dash be made the default shell in Arch?
Couldn't you just set it as the default for your user using chsh?
This isn't about using it as a login shell. Describing this as "my default shell" is a very bad description. This is actually about setting dash as the system /bin/sh implementation. -- Eli Schwartz Bug Wrangler and Trusted User
On Wed, 17 Jun 2020 at 19:39, Eli Schwartz via arch-general <arch-general@archlinux.org> wrote:
On 6/17/20 2:36 PM, David Rosenstrauch wrote:
On 6/17/20 2:18 PM, Piscium via arch-general wrote:
Today I set dash as my default shell [1] on two PCs. We will see if I get into trouble.
This question was asked years ago but maybe good to ask again. Could dash be made the default shell in Arch?
Couldn't you just set it as the default for your user using chsh?
This isn't about using it as a login shell. Describing this as "my default shell" is a very bad description.
This is actually about setting dash as the system /bin/sh implementation.
Indeed, poor choice of words, sorry for the confusion, however in the link I provided in my original email [1] it was clear in what sense I meant it to be a default. [1] https://wiki.archlinux.org/index.php/Dash#Use_DASH_as_/bin/sh
On Wed, 17 Jun 2020 at 20:37, David Rosenstrauch <darose@darose.net> wrote:
On 6/17/20 2:18 PM, Piscium via arch-general wrote:
Today I set dash as my default shell [1] on two PCs. We will see if I get into trouble.
This question was asked years ago but maybe good to ask again. Could dash be made the default shell in Arch?
Couldn't you just set it as the default for your user using chsh?
I don't think many people will want to use dash as interactive shell. It's more about running shell scripts with a #!/bin/sh shebang. It is still possible to do that system wide of course, with a symlink in /usr/local/bin . The question whether it makes sense as default /bin/sh on Arch Linux remains valid though. I personally would be positive towards that change. -- Maarten
On 17 Jun 2020 8:36 p.m., "David Rosenstrauch" <darose@darose.net> wrote: On 6/17/20 2:18 PM, Piscium via arch-general wrote:
Today I set dash as my default shell [1] on two PCs. We will see if I get into trouble.
This question was asked years ago but maybe good to ask again. Could dash be made the default shell in Arch?
Couldn't you just set it as the default for your user using chsh? Yes, that would probably more safe. Also, you could have a user "doot" or whatever name with user ID 0 and shell /bin/dash to log in as a sys admin with dash. Alternatively when you "su" interactively you could instead do "sudo dash". Used to do the same (new user with ID 0 I mean) under Solaris and it worked flawlessly. Best regards, NTS
On 6/17/20 3:05 PM, NTS wrote:
On 17 Jun 2020 8:36 p.m., "David Rosenstrauch" <darose@darose.net> wrote:
On 6/17/20 2:18 PM, Piscium via arch-general wrote:
Today I set dash as my default shell [1] on two PCs. We will see if I get into trouble.
This question was asked years ago but maybe good to ask again. Could dash be made the default shell in Arch?
Couldn't you just set it as the default for your user using chsh?
Yes, that would probably more safe. Also, you could have a user "doot" or whatever name with user ID 0 and shell /bin/dash to log in as a sys admin with dash.
Alternatively when you "su" interactively you could instead do "sudo dash".
Used to do the same (new user with ID 0 I mean) under Solaris and it worked flawlessly.
It would be extremely safe because it wouldn't do anything, not even what the original poster wanted. It's completely unrelated to anything whatsoever. -- Eli Schwartz Bug Wrangler and Trusted User
On Wed, Jun 17, 2020 at 07:18:33PM +0100, Piscium via arch-general wrote:
What do you think?
I'm not sure how much utility is in doing this, but I've had my /bin/sh linked to various shells over the years, and it never ended up tripping me up, despite me tinkering with my systems constantly. The shells I've used as my /bin/sh were dash, posh, loksh (openbsd's ksh on linux) and busybox's ash. I have no specific reason for doing this, just curiosity.
On June 17, 2020 7:06:01 PM UTC, "Jack L. Frost" <fbt@fleshless.org> wrote:
On Wed, Jun 17, 2020 at 07:18:33PM +0100, Piscium via arch-general wrote:
What do you think?
I'm not sure how much utility is in doing this
Pretty much this, to be honest. I don't really see the point of changing everyone's /bin/sh for one person's personal preference when there isn't really any point in doing so to begin with.
On Wed, 17 Jun 2020 at 20:19, Kusoneko <kusoneko@kusoneko.moe> wrote:
Pretty much this, to be honest. I don't really see the point of changing everyone's /bin/sh for one person's personal preference when there isn't really any point in doing so to begin with.
The reasons Ubuntu switched in 2006 and Debian in 2011 were speed, less bugs and more security. A simple benchmark I ran with several shells using konsole (which is one of the fastest terminals according to my simple benchmarks): time ls -R / • dash 8.45 • zsh 8.53 (1 % bigger) • bash 17.1 • fish 19.55 Times are in seconds, on my desktop that has a spinning drive. The first time it takes longer as the system caches stuff so the times above are after running a few times. I read that in some benchmarks dash is up to 4 times faster than bash.
On June 17, 2020 7:27:29 PM UTC, Piscium via arch-general <arch-general@archlinux.org> wrote:
On Wed, 17 Jun 2020 at 20:19, Kusoneko <kusoneko@kusoneko.moe> wrote:
Pretty much this, to be honest. I don't really see the point of changing everyone's /bin/sh for one person's personal preference when there isn't really any point in doing so to begin with.
The reasons Ubuntu switched in 2006 and Debian in 2011 were speed, less bugs and more security. A simple benchmark I ran with several shells using konsole (which is one of the fastest terminals according to my simple benchmarks):
time ls -R /
• dash 8.45 • zsh 8.53 (1 % bigger) • bash 17.1 • fish 19.55
Times are in seconds, on my desktop that has a spinning drive. The first time it takes longer as the system caches stuff so the times above are after running a few times. I read that in some benchmarks dash is up to 4 times faster than bash.
Sure. I personally don't really have a dog in this fight, as I don't really do shell scripting and use zsh as my login shell in most cases, and bash otherwise, but someone has to play devil's advocate and point out the cost of changing something that is this widely establish across so many distros. Of course, as most things are made with Ubuntu as a baseline because it is supposedly the most user-friendly, I'd bet the issue I pointed out isn't widespread, but it is likely still there and needs to be pointed out.
On 17/06/2020 21:27, Piscium via arch-general wrote:
The reasons Ubuntu switched in 2006 and Debian in 2011 were speed, less bugs and more security. A simple benchmark I ran with several shells using konsole (which is one of the fastest terminals according to my simple benchmarks):
time ls -R /
• dash 8.45 • zsh 8.53 (1 % bigger) • bash 17.1 • fish 19.55
Times are in seconds, on my desktop that has a spinning drive. The first time it takes longer as the system caches stuff so the times above are after running a few times. I read that in some benchmarks dash is up to 4 times faster than bash.
I cannot understand the benchmark there. If I run `bash -c "time ls -R /"` or `dash -c "time ls -R /"`, the only difference is the shell I started, and the way it reads commands and forks to launch time and/or ls, isn't it? So I also can have the same test using `{bash,dash} -c "echo Hello World"`[1], isn't it? I personnaly suspect that the output handling is responsible of that long execution time. The konsole may be as fast as it can, it may still be a bottleneck as it has to print the (long) output of `ls -R`. So I checked with /dev/null as output. I also get rid of /proc (looping symlinks…) and /bin, /lib, /share… as clear symlinks of other points—but it should not change the result as we want to compare execution time. # bash -c '/usr/bin/time ls -R /{dev,home,run,sys,usr,boot,etc,opt,root,srv,tmp,var}' # dash -c '/usr/bin/time ls -R /{dev,home,run,sys,usr,boot,etc,opt,root,srv,tmp,var}' After some warm-up executions to put objects in cache, both commands executes in 1.25 seconds on my computer. [1] OK, precision of measure changes, we have to loop somewhere—but it is *how* it is measured, not *what* is measured, which is my problem. -- Henry-Joseph Audéoud
Another proper consideration is continuity of development. If a death causes a shell to become abandonware as a result of a developer failing to arrange for another to take the project on updates if they happen at all will take some time. On Wed, 17 Jun 2020, Piscium via arch-general wrote:
Date: Wed, 17 Jun 2020 15:27:29 From: Piscium via arch-general <arch-general@archlinux.org> To: General Discussion about Arch Linux <arch-general@archlinux.org> Cc: Piscium <groknok@gmail.com> Subject: Re: [arch-general] dash as default shell?
On Wed, 17 Jun 2020 at 20:19, Kusoneko <kusoneko@kusoneko.moe> wrote:
Pretty much this, to be honest. I don't really see the point of changing everyone's /bin/sh for one person's personal preference when there isn't really any point in doing so to begin with.
The reasons Ubuntu switched in 2006 and Debian in 2011 were speed, less bugs and more security. A simple benchmark I ran with several shells using konsole (which is one of the fastest terminals according to my simple benchmarks):
time ls -R /
? dash 8.45 ? zsh 8.53 (1 % bigger) ? bash 17.1 ? fish 19.55
Times are in seconds, on my desktop that has a spinning drive. The first time it takes longer as the system caches stuff so the times above are after running a few times. I read that in some benchmarks dash is up to 4 times faster than bash.
--
On 17/06/2020 21.27, Piscium via arch-general wrote:
On Wed, 17 Jun 2020 at 20:19, Kusoneko <kusoneko@kusoneko.moe> wrote:
Pretty much this, to be honest. I don't really see the point of changing everyone's /bin/sh for one person's personal preference when there isn't really any point in doing so to begin with.
The reasons Ubuntu switched in 2006 and Debian in 2011 were speed, less bugs and more security. A simple benchmark I ran with several shells using konsole (which is one of the fastest terminals according to my simple benchmarks):
time ls -R /
• dash 8.45 • zsh 8.53 (1 % bigger) • bash 17.1 • fish 19.55
Times are in seconds, on my desktop that has a spinning drive. The first time it takes longer as the system caches stuff so the times above are after running a few times. I read that in some benchmarks dash is up to 4 times faster than bash.
Sorry, but... wat? This is a benchmark of $SOMETHING, but the $SOMETHING is so far removed from any common use case that I struggle to understand its relevance to... anything. So for me the answer would be: No. (Also, stop trying to optimize the wrong things.) Regards,
On Wed, 17 Jun 2020 19:18:59 +0000, Kusoneko wrote:
I don't really see the point of changing everyone's /bin/sh for one person's personal preference when there isn't really any point in doing so to begin with.
See OP's first post:
I did some simple benchmarks and dash is much faster than bash, moreover being far smaller there is less chance of bugs.
-- Merlin Büge
On 6/17/20 3:18 PM, Kusoneko wrote:
On June 17, 2020 7:06:01 PM UTC, "Jack L. Frost" <fbt@fleshless.org> wrote:
On Wed, Jun 17, 2020 at 07:18:33PM +0100, Piscium via arch-general wrote:
What do you think?
I'm not sure how much utility is in doing this
Pretty much this, to be honest. I don't really see the point of changing everyone's /bin/sh for one person's personal preference when there isn't really any point in doing so to begin with.
Completely free, no cost speed improvements have no utility? Reread the original post. -- Eli Schwartz Bug Wrangler and Trusted User
On June 17, 2020 7:35:27 PM UTC, Eli Schwartz via arch-general <arch-general@archlinux.org> wrote:
On 6/17/20 3:18 PM, Kusoneko wrote:
On June 17, 2020 7:06:01 PM UTC, "Jack L. Frost" <fbt@fleshless.org> wrote:
On Wed, Jun 17, 2020 at 07:18:33PM +0100, Piscium via arch-general wrote:
What do you think?
I'm not sure how much utility is in doing this
Pretty much this, to be honest. I don't really see the point of changing everyone's /bin/sh for one person's personal preference when there isn't really any point in doing so to begin with.
Completely free, no cost speed improvements have no utility? Reread the original post.
-- Eli Schwartz Bug Wrangler and Trusted User
It has the cost that everyone who uses scripts that use bashisms will inevitably have issues, furthermore, considering Arch only supports x86_64, I've yet to see systems under that architecture have low amounts of memory and 6MB of disk storage is incredibly small. The real question here is "Is it worth forcing people to remove bashisms or specify that the script is meant for bash in their scripts (whichever ones don't do so already) for a speed improvement on a shell scripts that work with dash?" Note that some upstreams will likely not care, and maintainers will have to patch the scripts manually in that case.
It has the cost that everyone who uses scripts that use bashisms will inevitably have issues, Anybody who is using Bash features with /bin/sh shebang is wrong anyway. Want Bash features? Use #!/bin/bash Want simpler POSIX-compatible shell that is also faster? Use #!/bin/sh Do not care? Use #!/bin/bash furthermore, considering Arch only supports x86_64, I've yet to see systems under that architecture have low amounts of memory and 6MB of disk storage is incredibly small Doesn't mean that performance and resource consumption is irrelevant. Virtual machines might be
On 17/06/2020 22:54, Kusoneko wrote: pretty constrained, for example. Celeron + 4GB laptops exist and people might use them.
Note that some upstreams will likely not care, and maintainers will have to patch the scripts manually in that case.
That was the problem for Debian and derivatives when they took that initiative. Now, I think, the scripts are mostly either patched by Debian maintainers or written properly in upstreams because Debian is pretty popular distro.
On 6/17/20 3:54 PM, Kusoneko wrote:
It has the cost that everyone who uses scripts that use bashisms will inevitably have issues, furthermore, considering Arch only supports x86_64, I've yet to see systems under that architecture have low amounts of memory and 6MB of disk storage is incredibly small. The real question here is "Is it worth forcing people to remove bashisms or specify that the script is meant for bash in their scripts (whichever ones don't do so already) for a speed improvement on a shell scripts that work with dash?" Note that some upstreams will likely not care, and maintainers will have to patch the scripts manually in that case.
Debian/Ubuntu has extensive prior art in this matter. It was very important and resulted in very noticeable speed improvements on x86_64 systems with lots of memory and disk storage, because pid 1 used to be shellscripts and doing it in bash is slow and gets even slower the more you fork new scripts. :) Also Linux isn't everything :) and there are plenty of systems where bash is not installed by default. e.g. the *BSDs. Also also, bash is not installed on systems such as alpine linux. So any script assuming /bin/sh is bash, is broken on lots of systems. ... This is not actually a problem, I've used dash as my /bin/sh for years and haven't once encountered a broken script. -- Eli Schwartz Bug Wrangler and Trusted User
On 6/17/20 14:18, Piscium via arch-general wrote: (SNIP)
... A possible issue is bashisms, however Ubuntu has been using dash as default for 14 years and Debian also for several years so hopefully most scripts have had bashisms removed by upstreams.
This is false. Or at the least, grievously inaccurate. Both Ubuntu and Debian use dash as the symlinked shell for /bin/sh, the default *system shell*, NOT the interactive shell for users.[0][1] Both continue to use bash as the default shell for the interactive shell (user shell). Install the latest Ubuntu and/or Debian in a VM if you don't believe me, but you'll see the same: root@ubuntutest:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04 LTS Release: 20.04 Codename: focal root@ubuntutest:~# which $SHELL /bin/bash root@ubuntutest:~# ls -l $SHELL -rwxr-xr-x 1 root root 1183448 Feb 25 12:03 /bin/bash root@ubuntutest:~# file $SHELL /bin/bash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=a43fec47192ff49c2d3fed671f2be8df7e83784a, for GNU/Linux 3.2.0, stripped root@ubuntutest:~# echo $SHELL /bin/bash root@debian:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster root@debian:~# which $SHELL /bin/bash root@debian:~# ls -l $SHELL -rwxr-xr-x 1 root root 1168776 Apr 18 2019 /bin/bash root@debian:~# file $SHELL /bin/bash: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=ffe165dc81a64aea2b05beda07aeda8ad71f1e7c, stripped root@debian:~# echo $SHELL /bin/bash In fact, Debian explicitly warns that dash is intended to NOT be used as the interactive shell: "It is not intended to be used interactively by a user, for example, in a terminal emulator, but rather focuses on speed and compatibility with standards. Therefore, many interactive features are not present in Dash, making it faster and more memory efficient than Bash."[1] It's faster *because they removed user features*. [0] https://wiki.ubuntu.com/DashAsBinSh [1] https://wiki.debian.org/Shell#Non-interactive_Shell -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
On 6/17/20 15:58, brent s. wrote:
This is false. Or at the least, grievously inaccurate.
To clarify: This is less-so aimed at OP; the only issue there was a poor choice of words and explaining the suggested switch. The previous post was aimed moreso at those that do not understand there are two shells: one the system uses in scripts (usually init scripts, but more on that in a moment) vs. one the user uses, the interactive shell (the one you run commands from). /bin/sh should be fully POSIX-compatible, /bin/bash has extra features that users would find useful (such as various completion functions, etc.) dash is written to be POSIX-compliant, but no more. Now, to init- because Arch uses systemd (and, yes, now Debian and Ubuntu), one must wonder what benefit, if any, this actually serves. systemd invokes the command directly, it does not spawn a shell to run an init script like sysvinit, upstart, openrc, etc. This is, primarily, the purpose of the system shell. I don't really see much of a benefit to it being that Arch uses systemd. Granted, it probably wouldn't harm much either given the purpose of the system shell, and probably why those who have already changed it haven't seen any noticeable effects. It just seems like an unnecessary change. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
On Wed, 17 Jun 2020 at 21:21, brent s. <bts@square-r00t.net> wrote:
Now, to init- because Arch uses systemd (and, yes, now Debian and Ubuntu), one must wonder what benefit, if any, this actually serves. systemd invokes the command directly, it does not spawn a shell to run an init script like sysvinit, upstart, openrc, etc. This is, primarily, the purpose of the system shell.
I don't really see much of a benefit to it being that Arch uses systemd. Granted, it probably wouldn't harm much either given the purpose of the system shell, and probably why those who have already changed it haven't seen any noticeable effects. It just seems like an unnecessary change.
It's a good point you made that with systemd there are less benefits of a fast /bin/sh. Ubuntu made its switch to dash in 2006 [1] and Debian in 2011 [2], [3], and they switched to systemd later in 2013 and 2012, respectively [4]. But switching to dash would also be about security, as less code means less bugs [5]. I found only one CVE for dash, an old one when dash is used as a login shell [7]. There are a number of bash bugs but they tend to be in various devices that are not necessarily using the latest bash version so most would not apply to Arch (it would take a long time to go through the list [8] in detail so I won't do it). [1] https://wiki.ubuntu.com/DashAsBinSh [2] https://wiki.debian.org/Shell [3] https://www.debian.org/News/2011/20110205a [4] https://en.wikipedia.org/wiki/Systemd#Adoption [5] https://lwn.net/Articles/614218/ [6] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bash [7] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0854 [8] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bash+
On Wed, Jun 17, 2020 at 11:17:08PM +0100, Piscium via arch-general wrote:
But switching to dash would also be about security, as less code means less bugs [5].
Usage of a more concise, powerful and clean shell language is much more suitable as a point when bringing forth an argument of there being less bugs. I'd say that the amount of bugs in the underlying implementation of a shell almost does matter nothing when compared to the horrors of hacked-together shell scripts that try to be as "basic" as possible, trying to be as "compatible" as possible with anything, exchanging cleanliness and expressiveness for horrible Debian init script-style code. Saving a pseudo-array into a string just to manually reconstruct the pseudo-list when the occasion arises to access a specific element is just one example of what awaits people who ignore the benefits of Bash arrays when they could have had them just by using a different shebang. And nearly everybody who has to write this quickly will do it wrong.
On 6/18/20 12:08 PM, lists@2ion.de wrote:
On Wed, Jun 17, 2020 at 11:17:08PM +0100, Piscium via arch-general wrote:
But switching to dash would also be about security, as less code means less bugs [5].
Usage of a more concise, powerful and clean shell language is much more suitable as a point when bringing forth an argument of there being less bugs.
I'd say that the amount of bugs in the underlying implementation of a shell almost does matter nothing when compared to the horrors of hacked-together shell scripts that try to be as "basic" as possible, trying to be as "compatible" as possible with anything, exchanging cleanliness and expressiveness for horrible Debian init script-style code.
Saving a pseudo-array into a string just to manually reconstruct the pseudo-list when the occasion arises to access a specific element is just one example of what awaits people who ignore the benefits of Bash arrays when they could have had them just by using a different shebang.
Why does this have anything to do with switching /bin/sh? Scripts which do not "ignore the benefits of bash arrays when they could have had them just by using a different shebang", would not be affected by such a change as they do not, in fact, use a different shebang. Meanwhile, scripts which use bashisms but a /bin/sh shebang are broken even if /bin/sh is a symlink to bash. Bash disables some, but not all, features of bash if it is invoked in POSIX mode, such as via a symlink named /bin/sh -- so, you do not even get the benefits of bash, and never have, if you used /bin/sh as your shebang.
And nearly everybody who has to write this quickly will do it wrong.
And yet, some do not. Some write elegant, simple POSIX sh scripts which do it right. For example, people often forget that pipelines and functions are an option, and sometimes a much faster and better option than global state variables. And most people who are writing /bin/bash scripts are *also* doing it wrong because they don't really know what they are doing. Just saying. :p -- Eli Schwartz Bug Wrangler and Trusted User
On 18/06/2020 18.22, Eli Schwartz via arch-general wrote:
On 6/18/20 12:08 PM, lists@2ion.de wrote:
On Wed, Jun 17, 2020 at 11:17:08PM +0100, Piscium via arch-general wrote:
But switching to dash would also be about security, as less code means less bugs [5].
Usage of a more concise, powerful and clean shell language is much more suitable as a point when bringing forth an argument of there being less bugs.
I'd say that the amount of bugs in the underlying implementation of a shell almost does matter nothing when compared to the horrors of hacked-together shell scripts that try to be as "basic" as possible, trying to be as "compatible" as possible with anything, exchanging cleanliness and expressiveness for horrible Debian init script-style code.
Saving a pseudo-array into a string just to manually reconstruct the pseudo-list when the occasion arises to access a specific element is just one example of what awaits people who ignore the benefits of Bash arrays when they could have had them just by using a different shebang.
Why does this have anything to do with switching /bin/sh? Scripts which do not "ignore the benefits of bash arrays when they could have had them just by using a different shebang", would not be affected by such a change as they do not, in fact, use a different shebang.
Meanwhile, scripts which use bashisms but a /bin/sh shebang are broken even if /bin/sh is a symlink to bash. Bash disables some, but not all, features of bash if it is invoked in POSIX mode, such as via a symlink named /bin/sh -- so, you do not even get the benefits of bash, and never have, if you used /bin/sh as your shebang.
This is a valid argument.
And nearly everybody who has to write this quickly will do it wrong.
And yet, some do not. Some write elegant, simple POSIX sh scripts which do it right. For example, people often forget that pipelines and functions are an option, and sometimes a much faster and better option than global state variables.
And most people who are writing /bin/bash scripts are *also* doing it wrong because they don't really know what they are doing. Just saying. :p
This is an argument from the Perfect/Robot programmer and is utterly false. We should just collectively face the truth that shell is not a good way to program anything non-trivial. :D Regards,
On 6/18/20 6:06 PM, Bardur Arantsson wrote:
On 18/06/2020 18.22, Eli Schwartz via arch-general wrote:
And nearly everybody who has to write this quickly will do it wrong.
And yet, some do not. Some write elegant, simple POSIX sh scripts which do it right. For example, people often forget that pipelines and functions are an option, and sometimes a much faster and better option than global state variables.
And most people who are writing /bin/bash scripts are *also* doing it wrong because they don't really know what they are doing. Just saying. :p
This is an argument from the Perfect/Robot programmer and is utterly false.
We should just collectively face the truth that shell is not a good way to program anything non-trivial. :D
I... don't see what you're arguing against? Someone made an argument that security would be aided by using a larger shell which has more features that can avoid some of the gross hacks people sometimes do in POSIX sh. I argued in response that most people suck at writing bash *anyway*, and it's possible for people who know what they're doing to write perfectly safe POSIX sh. It's immaterial to the discussion either way, but I just figured I would point out that anyone who I'd actually trust to write shell scripts, I'd usually trust to write POSIX shell scripts too. So there's no need to make some arbitrary divide where bash is "safer" than POSIX sh and the latter should never be used. Your response is... I'm wrong because only the Perfect/Robot programmer can write good shell of any kind, and people shouldn't program in shell? Where did I say people should program in shell? -- Eli Schwartz Bug Wrangler and Trusted User
I would want the default /bin/sh shell to be dash just for the sake of standardization. Also no one really expects /bin/sh to be bash, that alone is confusing for some people (myself included). Josef Miegl
On 06/17/2020 01:18 PM, Piscium via arch-general wrote:
Today I set dash as my default shell [1] on two PCs. We will see if I get into trouble.
This question was asked years ago but maybe good to ask again. Could dash be made the default shell in Arch?
Please NO. Bash has been the default, and while there is nothing wrong with a Bourne-again (or Debian Almquist) type shell, it would break more than a decade of setups... If you want Dash, make the change after install. -- David C. Rankin, J.D.,P.E.
On 6/18/20 12:11 AM, David C. Rankin wrote:
On 06/17/2020 01:18 PM, Piscium via arch-general wrote:
Today I set dash as my default shell [1] on two PCs. We will see if I get into trouble.
This question was asked years ago but maybe good to ask again. Could dash be made the default shell in Arch?
Please NO. Bash has been the default, and while there is nothing wrong with a Bourne-again (or Debian Almquist) type shell, it would break more than a decade of setups...
If you want Dash, make the change after install.
You pulled this assertion out of thin air, do you have any proof that it "breaks more than a decade of setups"? Note that as has already been pointed out, any setup which it breaks is inherently flawed, and in addition was broken on Debian, the most popular linux distribution by sheer numbers, as well as most non-Linux forms of Unix. It's actually in practice very unlikely that this will break anyone's setup. Also if you really think Arch Linux is afraid to break people's setups, I suggest you reread https://www.archlinux.org/news/python-is-now-python-3/ -- Eli Schwartz Bug Wrangler and Trusted User
Also I think some people here wrote, that they used dash as /bin/sh for years without problems. I personally also prefer dash as /bin/sh, but I dont think the pacman-trigger approach described in the wiki is a clean way of doing it. I dont know the arch packaging a lot, but I think a package which provides dash as bin/sh would be a cleaner approach. On Thu, 18 Jun 2020 00:33:59 -0400 Eli Schwartz via arch-general <arch-general@archlinux.org> wrote:
You pulled this assertion out of thin air, do you have any proof that it "breaks more than a decade of setups"?
On 18/06/2020 06.33, Eli Schwartz via arch-general wrote:
On 6/18/20 12:11 AM, David C. Rankin wrote:
On 06/17/2020 01:18 PM, Piscium via arch-general wrote:
Today I set dash as my default shell [1] on two PCs. We will see if I get into trouble.
This question was asked years ago but maybe good to ask again. Could dash be made the default shell in Arch?
Please NO. Bash has been the default, and while there is nothing wrong with a Bourne-again (or Debian Almquist) type shell, it would break more than a decade of setups...
If you want Dash, make the change after install.
You pulled this assertion out of thin air, do you have any proof that it "breaks more than a decade of setups"?
OP is the one making an assertion, so the burden of proof is on them. That said... I suspect most the system-wide breakage that would have been expected would be due to init scripts and systemd ameliorates that to a large degree.
Note that as has already been pointed out, any setup which it breaks is inherently flawed, and in addition was broken on Debian, the most popular linux distribution by sheer numbers, as well as most non-Linux forms of Unix.
Inherent flaws in a setup doesn't mean that shit doesn't break. Ideally, yes, there would be no flaws, but this is the real world. Doubtless, we all try to strive towards perfection, but there is no such thing in practice.
It's actually in practice very unlikely that this will break anyone's setup.
Also if you really think Arch Linux is afraid to break people's setups, I suggest you reread https://www.archlinux.org/news/python-is-now-python-3/
In practice, I agree that it probably won't break much, but your arguments largely don't hold water. Regards and FWIW,
On 6/18/20 6:00 PM, Bardur Arantsson wrote:
On 18/06/2020 06.33, Eli Schwartz via arch-general wrote:
You pulled this assertion out of thin air, do you have any proof that it "breaks more than a decade of setups"?
OP is the one making an assertion, so the burden of proof is on them.
That said... I suspect most the system-wide breakage that would have been expected would be due to init scripts and systemd ameliorates that to a large degree.
The OP is sharing an assertion made by many people, that /bin/sh as dash is safe. As I've mentioned previously in the thread, there is a lot of prior art. Anything that is expected to work on multiple distros, generally should work. SysV init scripts might not work, if they were Arch-specific. Yes. That is of course no longer a concern, and the primary concern is instead system scripts, applications, frameworks, etc. which run after boot, not as part of boot.
Note that as has already been pointed out, any setup which it breaks is inherently flawed, and in addition was broken on Debian, the most popular linux distribution by sheer numbers, as well as most non-Linux forms of Unix.
Inherent flaws in a setup doesn't mean that shit doesn't break. Ideally, yes, there would be no flaws, but this is the real world.
Doubtless, we all try to strive towards perfection, but there is no such thing in practice.
That is completely beside the point. If it doesn't work on Debian, chances are someone is going to notice and fix it. :p The world is no longer a place where everyone assumes /bin/sh works like bash. Following in the footsteps of Debian in this regard is not some super dangerous endeavor.
It's actually in practice very unlikely that this will break anyone's setup.
Also if you really think Arch Linux is afraid to break people's setups, I suggest you reread https://www.archlinux.org/news/python-is-now-python-3/
In practice, I agree that it probably won't break much, but your arguments largely don't hold water.
I've provided rationale why I don't believe it will break much, you *agree* with me, and yet you say my arguments don't hold water? -- Eli Schwartz Bug Wrangler and Trusted User
On 19/06/2020 00.18, Eli Schwartz via arch-general wrote:
I've provided rationale why I don't believe it will break much, you *agree* with me, and yet you say my arguments don't hold water?
Heh, I'm too tired to get into a detailed debate, but it's very possible to be right for the wrong reasons! :) Regards,
I haven't seen this mentioned yet which makes me wonder if I've misunderstood, but isn't it already the case that bash runs in a posix-compatible mode if executed as /bin/sh? I remember a bug a while back [1] that broke graphical login because flatpak used a bashism in an X startup script. Does this not imply that any bashisms executed with /bin/sh would already be causing breakage today on Arch Linux? [1] https://bugs.archlinux.org/task/61420#comment176360
On 6/18/20 7:15 PM, Chris Billington via arch-general wrote:
I haven't seen this mentioned yet which makes me wonder if I've misunderstood, but isn't it already the case that bash runs in a posix-compatible mode if executed as /bin/sh?
I remember a bug a while back [1] that broke graphical login because flatpak used a bashism in an X startup script. Does this not imply that any bashisms executed with /bin/sh would already be causing breakage today on Arch Linux?
Yep -- as I said earlier in the thread:
Meanwhile, scripts which use bashisms but a /bin/sh shebang are broken even if /bin/sh is a symlink to bash. Bash disables some, but not all, features of bash if it is invoked in POSIX mode, such as via a symlink named /bin/sh -- so, you do not even get the benefits of bash, and never have, if you used /bin/sh as your shebang.
-- Eli Schwartz Bug Wrangler and Trusted User
participants (18)
-
Bardur Arantsson
-
brent s.
-
Chris Billington
-
David C. Rankin
-
David Rosenstrauch
-
Eli Schwartz
-
Henry-Joseph Audéoud
-
Jack L. Frost
-
Josef Miegl
-
Jude DaShiell
-
Kusoneko
-
lists＠2ion.de
-
Maarten de Vries
-
Merlin Büge
-
NTS
-
Piscium
-
Shorrer
-
Simon Brand