Variable assignment in sh
wblock at wonkity.com
Tue Jan 31 21:51:34 UTC 2017
On Tue, 31 Jan 2017, James B. Byrne via freebsd-questions wrote:
> On Tue, January 31, 2017 12:51, Polytropon wrote:
>> On Tue, 31 Jan 2017 12:11:49 -0500, James B. Byrne via
>> freebsd-questions wrote:
>>> In any case, I now have set the shell in the root crontab file
>>> explicitly to /usr/local/bin/bash in hopes of avoiding this problem
>>> in the future.
>> That _might_ introduce problems in the future when bash is not
>> available. My suggestion: Use /bin/sh for scripting except you
>> need to rely on a "bash-ism", a feature that bash can provide,
>> but sh cannot. However, you can use bash interactively to test
>> sh commands, there is "backward compatibility" (bash can be seen
>> as a superset of sh).
> How would bash become unavailable on this particular system without
> someone specifically removing it?
Boot into single user mode. /usr is not (necessarily) mounted, and
doing anything could be challenging.
If you absolutely must have bash for root, leave root's shell as csh and
run bash from within .cshrc. If /usr is not mounted, it will just fail
and leave you with a chance to fix things from a running csh.
It's important to note that shells are two things, an interactive user
interface, and a shell script interpreter. Thanks to a rich selection,
one program does not have to be used for both. For example, I use csh
along with a large autocompletion file and some aliases and it works
very well for that. I would not write scripts for csh, though, because
the built-in script implementation is not great. Not a problem, since
just putting #!/bin/sh as the first line of a script causes it to run
with the standard sh interpreter.
More information about the freebsd-questions