#1352 Bash scripts should rely on bash explicitly
Closed None Opened 9 years ago by sundaram.

Scripts that are provided by Fedora that rely on Bash should explicitly use #!/bin/bash to enable users to switch the default system (non-interactive) shell I intend to run checkbashisms

$ checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin)

and file tickets against scripts that rely on bash to make that dependency explicit. I wanted to consult with FESCo that this makes sense before doing so.

PS:

While this is related to the discussion to switching the default system shell at

https://lists.fedoraproject.org/pipermail/devel/2014-October/202876.html

this ticket itself is NOT about switching the distro default but merely making it possible for users to do so.


Another related step would be to drop https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Default_Shell and get shell scripts that call bash to do so explicitly as well.

You may want to talk to the packaging committee about these as well. The first one if you want to encode it into the guidelines as well as a one time bug reporting session. I think It's common sense but the members of the fpc will be very different shortly so I can't speak for them at all.

The second one would likely deepend on whether a fedora change is approved that says that fedora's /bin/sh is not pointing at bash any longer so it probably couldn't be decided until then.

Note that the default shell guideline does not mean that people can include bash extended features if they specify /bin/sh - it is restricted to meaning that people can rely on the bash implementation of the Bourne shell when /bin/sh is used.

There may be something useful to do, but I am strongly against the change as proposed (all personal opinion, just to perhaps allow more time before a FESCo meeting, especially for my “line in the sand” below):

== The benefits of dash don’t outweigh the costs ==
In my evaluation, the disk space and memory saved are trivial (probably not worth even the time spent on this month’s discussion about this), especially not if we end up still requiring bash installed on every system for RPM scriptlets, which do use bash-specific features in practice. Whereas the costs are not extreme, but noticeable.

== Marking bash uses with /bin/bash is a non-feature ==

=== Users don’t want/need this
Outside of extremely minimal embedded systems which don’t build from Fedora anyway, I can’t imagine a user valuing the ability to choose a shell. “I get to spend 4 hours today studying differences between bash and dash to maybe save less than 4 MB of disk space.” All users I know find it difficult to evaluate and learn even the tools they directly use for their application-specific uses, and evaluating/choosing low-level tools they don’t need to interact with is not helping.

This can be interesting only to someone who explicitly wants to spend time learning how Linux works, but then…

=== This is not a good way to architect a distribution
I don’t fully agree with the “Linux is not about choice” rant, but it is basically applicable in this space: Even if the Linux ecosystem has interchangeable components in various places, users should not have to make all these choices, and ''distributions are precisely where we help users with this'' by choosing the appropriate components out of all the possible alternatives, and making sure that our choice actually works for all cases.

=== Having the /bin/bash references is not enough to give users choice of shells
This would at least involve setting up alternatives, and perhaps dependency trimming and package splits and whatever more necessary to allow users to replace the shell easily enough, ''and on top of that'' testing the distribution in both scenarios!

If we are not willing to commit to doing all that work (where the regular testing is the most demanding part), we shouldn’t even be starting on this path.

== Yet more manual packaging/review work ==

This is a pretty random place, but just as good as any for me to try to draw a line in the sand, and I suppose the timing with FPC changes makes it appropriate.

I will no longer tolerate/support any packaging guideline changes which, without expanding Fedora to an entirely new ecosystem/use case, add manual packaging or package review work. We are software developers, and the way we solve problems in our area and in this century is by writing software.

(We will see how long that lasts ☺)

So no, I don’t like adding more steps to do during packaging and package updates, more things to check during reviews, nor filing tickets to manually change packages.

== A possible alternative ==

Modify rpm and/or redhat-rpm-config (and perhaps rpmlint, though that should be entirely unnecessary and optional) so that it, as part of the build process, runs the checkbashisms script and automatically change the shebang. Add nothing to packaging guidelines, file no tickets for manual work; let it be picked up by the F22 mass rebuild.

This could only be done if the change from /bin/sh to /bin/bash were always semantically safe, which it apparently isn’t. Perhaps the change should be to /bin/bash --posix instead? We would need an expert to confirm.

I ''still'' wouldn’t consider this a useful feature, but if it were completely automated and transparent, I would find no reason to object if somebody wanted to do this.

The alternative idea proposed above has already been rejected.

https://bugzilla.redhat.com/show_bug.cgi?id=850706

No; that bug proposes changing the interpreter for rpm-executed scriplets. What I am talking above is editing of not rpm-executed but rpm-shipped scriptlets, i.e. implementing the title of this ticket, “bash scripts should rely on bash explicitly”.

This seems like a ton of 'make work' and churn when we have more important things to focus on.

I'd be fine with a "SHOULD" guideline/recommendation about this, but I guess thats up to the FPC. ie, if possible fix 'bashisms' in your scripts that call '#!/bin/sh', but don't block on it.

Replying to [comment:7 kevin]:

This seems like a ton of 'make work' and churn when we have more important things to focus on.

I'd be fine with a "SHOULD" guideline/recommendation about this, but I guess thats up to the FPC. ie, if possible fix 'bashisms' in your scripts that call '#!/bin/sh', but don't block on it.
That would still be 'make work' unless we assume that packagers just ship SHOULD entries without reading them. The packaging guidelines which are already long enough to be a significant barrier to entry to new contributors.

From today's meeting:

AGREED: Ask Rahul to work with upstreams to resolve this issue rather than patching it downstream (+1: 7 0:0 -1:0)

Login to comment on this ticket.

Metadata