Talk:Dash

Bashisms in install scripts

Looking at https://github.com/archlinux/svntogit-packages/blob/packages/pacman/trunk/PKGBUILD it seems that at least currently pacman is configured to explicitly use bash as the "scriptlet-shell" which I am guessing is what executes install scripts. So I am guessing that having bashisms in those shouldn't stop me from linking /bin/sh to dash. I'll be trying this out and report back, or maybe if someone more knowledgeable comes across this they can clarify. Manulari (talk) 19:58, 24 September 2014 (UTC)

Yes, scriptlet-shell is shell to use by default to execute pacman install scripts. I think Arch devs and maintainers give up to enforce sh on devs and cover their sh missteps and gone with the flow of bash. sh was replaced by bash in scriptlet-shell there somewhere in 2013 or 2014. In 2011-2013 I used DASH as daily driver for sh and started to catch bashisms around there. There all the way trend, there is too many bashisms now in my system. Too many to be possible to use DASH by default. So DASH now to special use-cases and small installations.PiroXiline (talk) 12:39, 6 September 2016 (UTC)

Please list the bashisms, this seems like a good place to do it. On my installation, bashisms in sh scripts that Dash does not support are almost nonexistant among the official packages. Neven (talk) 14:51, 4 November 2017 (UTC)

Method of replacing /bin/sh

Using pacman.conf's NoUpgrade and NoExtract causes pacstrap (from arch-install-scripts) to no longer work correctly (since it doesn't depend on whether dash is actually installed). It's better to use the pacman hook which checks that dash is installed first. Having a working pacstrap is very useful when working with systemd containers and what not. Kieranc (talk) 15:46, 20 April 2018 (UTC)

I'd go one step further and point out the justification for NoUpgrade was *wrong* since when bash overwrites the symlink it... well, overwrites the symlink with something that works even if it is a slower, more heavyweight binary. I have no idea why that change was made in the first place. -- Eschwartz (talk) 17:30, 22 April 2018 (UTC)

Apparently if a system upgrade takes too long, the user might launch another shell which is not dash before the post-transaction hook is invoked. See the edit summary in [1]. -- Lahwaacz (talk) 18:27, 22 April 2018 (UTC)

Well, this is not good grounds for being unable to tell whether the symlink actually works and has something on the other end. :( But maybe I misread this, because I read the Note included in those changes which seemed to imply that using a hook might somehow result in no /bin/sh at all. Though on second read, I guess I associated that with the initial edit instead of being a reference purely to using NoExtract without NoUpgrade.

It's silly anyway, IMHO, because using /bin/sh ==> bash during the small window of time during which pacman is extracting further packages and has not yet run the hooks causes no damage other than using a slightly slower interpreter. We should optimize the case of safety via hook dependencies, rather than efficiency in small corner cases. Disregarding the irrelevant "downloading packages" stage during which the symlink is not yet removed... people do not upgrade bash as part of lengthy, time-consuming upgrade processes during which failing to use dash is a mission-critical failure, nearly as often as they upgrade bash on e.g. systems with possibly synced system configuration through etckeeper or orchestration tools like ansible without being completely positive what other package is there. ;) And if they do, then they should stop doing things in the middle of non-atomic package manager updates -- it is purely a timing issue, and with worse timing they can actually end up running programs while glibc is missing, never mind bash or sh! -- Eschwartz (talk) 19:03, 22 April 2018 (UTC)

Isn't it better for the user to symlink .local/bin/sh to /usr/bin/dash instead? --Ubone (talk) 13:53, 3 January 2019 (UTC)

No... the only reason to change sh to be dash instead of bash is for scripts which hardcode /bin/sh. -- Eschwartz (talk) 14:01, 3 January 2019 (UTC)

Wouldn't it be nicer if the bash package does not own /bin/sh at all, but install the symlink as part of a post-install script only if it is not already present? Suggested in https://bugs.archlinux.org/task/67681 -- ghen