Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Feb 2017 01:48:58 +0100
From:      Polytropon <freebsd@edvax.de>
To:        Warren Block <wblock@wonkity.com>
Cc:        byrnejb@harte-lyne.ca, freebsd-questions@freebsd.org
Subject:   Re: Variable assignment in sh
Message-ID:  <20170201014858.eec196d0.freebsd@edvax.de>
In-Reply-To: <alpine.BSF.2.20.1701311445520.54303@wonkity.com>
References:  <b831bd9e40321e59910ea8913c7a6302.squirrel@webmail.harte-lyne.ca> <20170131161824.a9f1ef46.freebsd@edvax.de> <b553c644fccc211f9658b31cfe65e8a0.squirrel@webmail.harte-lyne.ca> <20170131185103.7f911dfb.freebsd@edvax.de> <5f51e2c3bdb8a20c6a7786c2b345c957.squirrel@webmail.harte-lyne.ca> <alpine.BSF.2.20.1701311445520.54303@wonkity.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Tue, 31 Jan 2017 14:51:20 -0700 (MST), Warren Block wrote:
> 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.

A possible addition to /root/.login (a file which csh will
execute when being invoked as a login shell) could be:

	/bin/test -x /usr/local/bin/bash && /usr/local/bin/bash

In case the executable is not available, you will still get
a working csh instance.



> 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.

There are a few people who consider the interactive behaviour
of csh being superior to that of bash, even though bash definitely
has better handling for redirection. On the other hand, many
users seem to prefer zsh (which is a great interactive shell
as well). FreeBSD does not force a specific shell upon the
user. However, it makes sense to not mess with system accounts
because that might trigger the shot into your foot in some
worst case scenario you cannot imagine today. :-)

Also note that toor (also a UID 0 user account) can have
bash as the login shell without interfering that "worst
case imagination".



> I would not write scripts for csh, though, because 
> the built-in script implementation is not great.

And it's considered harmful; see "Csh Programming Considered
Harmful" by Tom Christiansen:

http://www.perl.com/doc/FMTEYEWTK/versus/csh.whynot



> Not a problem, since 
> just putting #!/bin/sh as the first line of a script causes it to run 
> with the standard sh interpreter.

Additionally, it helps to write portable scripts (across
different operating systems), not just for FreeBSD systems
which might or might not have bash installed (at a non-
standard place). ;-)



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20170201014858.eec196d0.freebsd>