[Slackbuilds-users] bashisms?

[Jim Diamond]

On Sat, Aug 29, 2015 at 11:25 (-0400), B Watson wrote:

> On 8/29/15, Jim Diamond <Jim.Diamond at acadiau.ca> wrote:

>>> it'd be easy enough to sed the shebangs to #!/bin/bash

>> Well, this is, I believe, something which is also wrong in principle.

> In general, you're right. For the specific case of Slackbuilds,
> they're all already bash scripts (since /bin/sh is bash on Slack).
Well, yes and no.  See below.

> If Slackware 15.0 suddenly starts using dash for /bin/sh, it's safe
> to change the shebang lines for SBo scripts to read #!/bin/bash.
Maybe, maybe not.

> There are slight differences when bash is run as "sh" rather than
> "bash", but they only have to do with which startup files are read
> (see INVOCATION section in man page).

You are wrong on this last point (according to the bash man page).
Aside from the startup files being different, there are other changes
in behaviour when bash is invoked as /bin/sh.  (Search the man page
for all the sentences with "posix".)

>> zsh (at least with the options I get when I run it):
>> $ b='echo a'
>> $ $b
>> zsh: command not found: echo a

> Interesting. Tried this with bash. Invoking it as sh or with the
> --posix flag doesn't change the way this works (it still echoes a,
> doesn't act like zsh).
Indeed.  This is annoying me, because I'm sure (99% sure?) that I
fairly recently ran into something where bash's order for processing a
command line is different than POSIX's order.

In any case,
http://www.gnu.org/software/bash/manual/bashref.html#Bash-POSIX-Mode
lists 50 differences when bash is in POSIX mode.

Admittedly, it is a different question whether any SBo contributors
write slackbuilds which work in one mode and not the other.


> ash works like bash, for this case.  So does ksh, and so does hsh (the
> Heirloom shell). Looks like zsh might be the odd man out here.
It is (*), for better or for worse.  There was an "argument" in
comp.unix.shell not too long ago about this.  The nice thing about
this zsh behaviour is that you don't have to go around protecting
variable expansion like "$var" all the time.  I'd bet that it is more
often the case that one does not want a variable expansion to be word
split than for the expansion to be word split.

(*) Well, not entirely:
fish:
~> set a "echo b"
~> echo $a
echo b
~> $a
Variables may not be used as commands. In fish, please define a function or use 'eval a'.


Cheers.

                                Jim