FS#15771 - Install scripts fail when default shell (/bin/sh) is not bash

Attached to Project: Pacman
Opened by Richard Gill (riri) - Monday, 03 August 2009, 13:23 GMT
Last edited by Xavier (shining) - Tuesday, 18 August 2009, 08:54 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 3.2.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Summary and Info:

On my system, I prefer to have a minimal shell (such as /bin/dash) as a default shell (/bin/sh). When doing this, packages which include an install script fail because of a non portable shift instruction.

Steps to Reproduce:

# cd /bin
# rm sh
# ln -s dash sh
# #reinstalling pacman shows the problem
# pacman -S pacman

Proposed solutions:

Either force bash use when launching the shell command, or provide a shell selection setting in pacman.conf. However, the first solution is to prefer as reviewing all packages would be a mess. I've not taken a look in pacman source files, but I can imagine an 'exec' of '/bin/sh', which should be changed for '/bin/bash'.
This task depends upon

Closed by  Xavier (shining)
Tuesday, 18 August 2009, 08:54 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#13803 
Comment by Allan McRae (Allan) - Monday, 03 August 2009, 13:38 GMT
This is not a pacman bug. Pacman uses /bin/sh and that is entirely intended.

It is also not an Arch bug. Arch supports /bin/sh being bash and so can use bashisms for its install scripts. However, if there are bashisms in the Arch .install scripts and these can be made usable by other shells, I think that such request would be implemented.

Comment by Dan McGee (toofishes) - Monday, 03 August 2009, 13:55 GMT
I'm surprised your system works at all with an alternate shell at /bin/sh, I tried this many moons ago and it failed miserably.

Bashisms should be removed if possible from install scripts as Allan mentioned- I would support having a different default /bin/sh but there was a lot of (perceived) resistance last time I tried that. If Ubuntu can do it though...
Comment by Xavier (shining) - Monday, 03 August 2009, 14:01 GMT Comment by Richard Gill (riri) - Monday, 03 August 2009, 14:51 GMT
Well, this could be improved with an added setting in pacman.conf, for those (like me) who prefer to use dash as the system shell, so people not wondering to use an alternate shell does not have to bother with it, nor package maintainers. Only a (little?) dev on pacman.

For people who tried using dash a few months ago, I had the same problem, but now this seems ok (at least all init scripts work out of the box). The only remaining problem is with packages.
Comment by Xavier (shining) - Tuesday, 04 August 2009, 10:49 GMT
The only problem you stated is : a non portable shift instruction
As I already said in the other two links above, with the current pacman code, the 3 lines at the end of most scriptlets containing the shift can be simply removed.
That means you can fix ALL scriptlets with one simple sed line.

Now if you find other compatibility problems, just open a specific bug report for each problematic package (ideally with a patch)

A setting in pacman.conf is stupid, what would it do? The only thing which makes sense would be to have pacman call explicitely /bin/bash, as you already said. The thread on the ML contains a patch which does that, and also suggestions for improving that patch.
But if we need to do that just because of a shift command which is not even used, it's a pity...
Comment by Richard Gill (riri) - Tuesday, 04 August 2009, 12:19 GMT
Well, I were not figuring to check and modify all packages which could contain such statments - I should do it for all packages, not only installed one - maybe an announce on the ML for package maintainers could please them to check there packages ?

I understand that adding a configuration for one invalid command (used or not) is not really interesting :) However, it's more a way to be more souple, because:
* people wanting an alternate default shell do not have to worry about their shell's compatibility (as long as it's Bourne compatible)
* package maintainers do not have to worry about the default system shell, as long as pacman dicts the shell to use (what would be distro specific) so bash enforcement could be done, while the restriction does not apply to the default shell.
It's not so stupid, it's just another way to see how pacman could apply to any distro, or even to Arch when bash won't be the 'preferred' shell.

I won't check and modify the whole repository database, making a patch for each. The better I can do is to make this check and the patches for packages I use. But each time I'll install a faulty package, I'll have to make another patch, and then reinstall the software (hoping the patch will be applied before my next update). That's not IMHO a good way, but laking other solution, I'll take it.

Comment by Xavier (shining) - Tuesday, 04 August 2009, 12:41 GMT
Wait, before opening specific bug, we first need to do the easy fixes on all scriptlets.
 FS#13803  actually has patches for core and extra, but it is probably outdated now.
It would be good to know if this was made automatically, or if it also needed some manual fixes (I didn't even look at the patches yet).

And maybe we can do a check by just sourcing all scriptlets in ABS with dash and look for errors.

In any cases, we need to get at least on Arch dev involved..
But I think the discussion can continue on  FS#13803  and this one can be closed.
Comment by Richard Gill (riri) - Tuesday, 04 August 2009, 15:38 GMT
Ok, I already made a task closure request.

I'm not a massive user of Arch - and so do not use ABS (yet). I'll follow the discussion on  FS#13803  though.
Comment by Aaron Griffin (phrakture) - Tuesday, 04 August 2009, 15:43 GMT
As suggested, a pacman option pointing to which shell to use for scriptlets would be a neat solution. One could even set it to /usr/bin/python for some distro using python based install scriptlets