On Sat, 23 Dec 2017 at 22:04:44 -0600, LinuxChix SysAdmin wrote:
> Changing the shell to /bin/bash for tuptime for example, eliminates the
> error with using 'su -'.
When writing profile.d snippets, you can't assume that every user has
bash as their login shell. profile.d snippets need to be written to be
at least minimally compatible with the POSIX shell language, if only
via a guard like
if [ -n "$BASH_VERSION" ] || [ -n "$ZSH_VERSION" ]; then
... your bashisms here ...
fi
Debian's default /bin/sh (dash) implements the POSIX shell language and
hardly any more than that.
POSIX shell:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
The superset of POSIX shell that a Debian /bin/sh can be assumed to have:
https://www.debian.org/doc/debian-policy/#scripts
(I think dash implements *slightly* more than what Policy ยง10.4 requires
it to.)
> Aliases present no problem. Functions, depending on how they are written,
> do.
Yes. Aliases are part of the POSIX shell language, and so are functions defined
with the somefunction () {...} syntax, but the function reserved word in
bash is not a reserved word in the POSIX shell language.
It's unfortunate that the POSIX shell language has so many traps and
pitfalls, but we're several decades too late to influence how it works.
> Doing the same thing but with the () included did not work. That has me
> scratching my head. It should have bypassed those lines entirely.
() is a special token in POSIX /bin/sh, so it can affect tokenization
even inside a check for bash. If you're doing something tricky, you can
use a pattern like
if [ -n "$BASH_VERSION" ]; then
. /usr/local/share/my-bashisms
fi
to dodge that, and put the parts that have weird tokenization in
/usr/local/share/my-bashisms.
> I'm not sure there's a good solution for this. It seems to be
> such a specific issue.
Welcome to shell scripting. :-(
smcv
