I typically put a shebang for bash at the top of my shell scripts, e.g.:
#!/usr/bin/bash
However I see many other variants of this, like #!/bin/bash or #!/usr/local/bin/bash etc.
It seems to me these different conventions would result in compatibility or portability issues. If my bash is at another location than someone else's, my script won't work on their machine and vice versa.
If a shell interpreter like bash is apparently not always at the same location, isn't it plain WRONG to explicitly use a hardcoded path in a script?
I understood you can use a somewhat more flexible or less system-dependent approach like this:
#!/usr/bin/env bash
Which results in the (or a?) local version of bash, wherever that may be installed.
Does the latter variant always work? Or is there a better approach that has the highest chance of referring to any system's bash regardless of where it's installed?
I would recommend either "#!/bin/bash" or "#!/usr/bin/bash". On a modern Linux distro, bash should be installed in both places.
Apparently, that isn't true for OpenBSD ... which uses ksh as the default shell. But on an OpenBSD system, you are liable to find that bash isn't installed at all. It is apparently an optional package, and the admin may have not installed it.
So, if you want to maximize portability, use "/bin/sh" and restrict yourself to standard POSIX shell syntax and commands. "/bin/sh" is typically a link to bash or ksh, and runs in POSIX compliant mode.
Other variations:
"#!/usr/local/bin/bash" typically won't work on Linux. If it does, it may give you a locally built / modified version of bash.
"#!/usr/bin/env bash" should work, with a couple of caveats:
This will give you whatever version of bash is first on the user's command search path (i.e. $PATH).
It is conceivable that the path to env may be different, or that it may not exist. (The env command wasn't in the first version of the POSIX specs.)
Related
I have heard about fish that it's a friendly and out-of-box shell but also it doesn't support POSIX standard.
On the other hand I read about POSIX standard (and also I tested it on my Fedora, It's amazing and out-of-box shell now I want to change my default shell to fish).
But the matter that I opened this question for is: I misunderstood about relation between fish and POSIX standard, what do you mean about fish does NOT support POSIX exactly? & How? (Should I change my bash to fish?).
Please explain it simple 'cause I'm a little newbie, thanks.
fish isn't and never tried to be compatible with POSIX sh.
This really just means that it's a separate language (like Java, Python or Ruby) rather than an implementation or extension of sh (like Bash, Dash and Ksh).
Obviously, just like you can't copy-paste Java snippets into a Python program, you can't copy-paste sh code into fish.
In practice, this means that when you search for things like "how do I show the current git branch in my prompt", you need to make sure you find fish answers because the sh ones won't work. Similarly, when books or instructions give commands to run, you may occasionally need to rewrite some of them manually (or open a bash shell and paste them there).
Whether this matters is entirely up to you, so definitely give it a go.
Actually, fish is not compliant with the POSIX sh definition. But neither is csh (and probably zsh). You still can use fish as your interactive shell.
For example echo $$ shows the pid of the shell in POSIX sh. But with fish it does not.
(and that is why I did not switch to fish and keep using zsh as my daily interactive login shell)
You could change your interactive login shell (using chsh) to fish.
But if you write shell scripts, writing them for the POSIX sh specification make these scripts more portable. (You'll use the shebang #!/bin/sh to start them, it is understood by Linux execve(2)). In some cases, you don't care about portability of your shell script and you could make them start with #!/usr/bin/fish to be fish scripts. Then they won't work on systems without fish.
Also, the system(3) C standard library function uses /bin/sh -c.
I enjoyed very much Yann Regis-Gianas' talk on POSIX [s]hell at FOSDEM2018.
I am writing a script and I want it to start with the Bourne shell. As I understand it, starting the script with:
#! /bin/sh
will not always specify the Bourne shell, but whatever the OS links to /bin/sh. Is there a way to explicitly specify Bourne?
Thanks!
The original Bourne Shell is not open source, so if you don't already have it, you're SOL.
If you do already have it, just put the location in the shebang.
Simple as that.
<Reminisce_mode_on>
Place a colon (:) on the first line. I used it on older systems
(A/UX, SCO Unix, Interactive Unix System V Release 3.2 SVR3, circa
1989, comes to mind) as the first character in a file to denote a
Bourne Shell script. It was also recognised by Thompson Toolkit's Korn
Shell (DOS > v3.2 ). Allowed Unix programmers to shell program in the
PC environment (DOS/WindowsNT).
</Reminisce_mode_off> Yeah, I'm old. Unix programmers never die, they just become zombie processes.
Depends on what you mean by "Bourne Shell".
Original Bourne Shell, which I believe is not what you are after:
proprietary, very limited, and only available on some true UNIX
systems, such as Solaris, derived from the original AT&T UNIX code.
#!/bin/sh is the way to get this non-portable shell.
Its ability to run true legacy scripts, and its smallness,
are about the only assets it has in my mind.
Today's memory gives the size asset less appeal.
Modern shells based on Bourne shell syntax. As opposed to, say csh.
bash, ksh, zsh are some. Bash is common in Linux environments, and yes, /bin/sh tends to link to one of these.
To use a specific shell, use something like which $SHELL to
get an absolute path.
#!/bin/env bash is less dependent on the shuffling of paths
found in different operating systems.
But this portable trick has the risk of choosing
the wrong shell if PATH is not set well enough and
does not allow arguments, such as -x, on the shell.
It has the advantage
of PATH being able to control which of several shells you use if
different versions of the same shell are available, which
ksh is well noted for.
So, if you want more help you will really need to detail the application you are after, and your definition of "Bourne Shell".
I've seen in a number of places, including recommendations on this site (What is the preferred Bash shebang?), to use #!/usr/bin/env bash in preference to #!/bin/bash. I've even seen one enterprising individual suggest using #!/bin/bash was wrong and bash functionality would be lost by doing so.
All that said, I use bash in a tightly controlled test environment where every drive in circulation is essentially a clone of a single master drive. I understand the portability argument, though it is not necessarily applicable in my case. Is there any other reason to prefer #!/usr/bin/env bashover the alternatives and, assuming portability was a concern, is there any reason using it could break functionality?
#!/usr/bin/env searches PATH for bash, and bash is not always in /bin, particularly on non-Linux systems. For example, on my OpenBSD system, it's in /usr/local/bin, since it was installed as an optional package.
If you are absolutely sure bash is in /bin and will always be, there's no harm in putting it directly in your shebang—but I'd recommend against it because scripts and programs all have lives beyond what we initially believe they will have.
The standard location of bash is /bin, and I suspect that's true on all systems. However, what if you don't like that version of bash? For example, I want to use bash 4.2, but the bash on my Mac is at 3.2.5.
I could try reinstalling bash in /bin but that may be a bad idea. If I update my OS, it will be overwritten.
However, I could install bash in /usr/local/bin/bash, and setup my PATH to:
PATH="/usr/local/bin:/bin:/usr/bin:$HOME/bin"
Now, if I specify bash, I don't get the old cruddy one at /bin/bash, but the newer, shinier one at /usr/local/bin. Nice!
Except my shell scripts have that !# /bin/bash shebang. Thus, when I run my shell scripts, I get that old and lousy version of bash that doesn't even have associative arrays.
Using /usr/bin/env bash will use the version of bash found in my PATH. If I setup my PATH, so that /usr/local/bin/bash is executed, that's the bash that my scripts will use.
It's rare to see this with bash, but it is a lot more common with Perl and Python:
Certain Unix/Linux releases which focus on stability are sometimes way behind with the release of these two scripting languages. Not long ago, RHEL's Perl was at 5.8.8 -- an eight year old version of Perl! If someone wanted to use more modern features, you had to install your own version.
Programs like Perlbrew and Pythonbrew allow you to install multiple versions of these languages. They depend upon scripts that manipulate your PATH to get the version you want. Hard coding the path means I can't run my script under brew.
It wasn't that long ago (okay, it was long ago) that Perl and Python were not standard packages included in most Unix systems. That meant you didn't know where these two programs were installed. Was it under /bin? /usr/bin? /opt/bin? Who knows? Using #! /usr/bin/env perl meant I didn't have to know.
And Now Why You Shouldn't Use #! /usr/bin/env bash
When the path is hardcoded in the shebang, I have to run with that interpreter. Thus, #! /bin/bash forces me to use the default installed version of bash. Since bash features are very stable (try running a 2.x version of a Python script under Python 3.x) it's very unlikely that my particular BASH script will not work, and since my bash script is probably used by this system and other systems, using a non-standard version of bash may have undesired effects. It is very likely I want to make sure that the stable standard version of bash is used with my shell script. Thus, I probably want to hard code the path in my shebang.
There are a lot of systems that don't have Bash in /bin, FreeBSD and OpenBSD just to name a few. If your script is meant to be portable to many different Unices, you may want to use #!/usr/bin/env bash instead of #!/bin/bash.
Note that this does not hold true for sh; for Bourne-compliant scripts I exclusively use #!/bin/sh, since I think pretty much every Unix in existence has sh in /bin.
For invoking bash it is a little bit of overkill. Unless you have multiple bash binaries like your own in ~/bin but that also means your code depends on $PATH having the right things in it.
It is handy for things like python though. There are wrapper scripts and environments which lead to alternative python binaries being used.
But nothing is lost by using the exact path to the binary as long as you are sure it is the binary you really want.
#!/usr/bin/env bash
is definitely better because it finds the bash executable path from your system environment variable.
Go to your Linux shell and type
env
It will print all your environment variables.
Go to your shell script and type
echo $BASH
It will print your bash path (according to the environment variable list) that you should use to build your correct shebang path in your script.
I would prefer wrapping the main program in a script like below to check all bash available on system. Better to have more control on the version it uses.
#! /usr/bin/env bash
# This script just chooses the appropriate bash
# installed in system and executes testcode.main
readonly DESIRED_VERSION="5"
declare all_bash_installed_on_this_system
declare bash
if [ "${BASH_VERSINFO}" -ne "${DESIRED_VERSION}" ]
then
found=0
all_bash_installed_on_this_system="$(\
awk -F'/' '$NF == "bash"{print}' "/etc/shells"\
)"
for bash in $all_bash_installed_on_this_system
do
versinfo="$( $bash -c 'echo ${BASH_VERSINFO}' )"
[ "${versinfo}" -eq "${DESIRED_VERSION}" ] && { found=1 ; break;}
done
if [ "${found}" -ne 1 ]
then
echo "${DESIRED_VERSION} not available"
exit 1
fi
fi
$bash main_program "$#"
Normally #!path/to/command will trigger bash to prepend the command path to the invoking script when executed. Example,
# file.sh
#!/usr/bin/bash
echo hi
./file.sh will start a new process and the script will get executed like /bin/bash ./file.sh
Now
# file.sh
#!/usr/bin/env bash
echo hi
will get executed as /usr/bin/env bash ./file.sh which quoting from the man page of env describes it as:
env - run a program in a modified environment
So env will look for the command bash in its PATH environment variable and execute in a separate environment where the environment values can be passed to env like NAME=VALUE pair.
You can test this with other scripts using different interpreters like python, etc.
#!/usr/bin/env python
# python commands
Your question is biased because it assumes that #!/usr/bin/env bash is superior to #!/bin/bash. This assumption is not true, and here's why:
env is useful in two cases:
when there are multiple versions of the interpreter that are incompatible.
For example python 2/3, perl 4/5, or php 5/7
when the location depends on the PATH, for instance with a python virtual environment.
But bash doesn't fall under any of these two cases because:
bash is quite stable, especially on modern systems like Linux and BSD which form the vast majority of bash installations.
there's typically only one version of bash installed under /bin.
This has been the case for the past 20+ years, only very old unices (that nobody uses any longer) had a different location.
Consequently going through the PATH variable via /usr/bin/env is not useful for bash.
Add to these three good resons to use #!/bin/bash:
for system scripts (when not using sh) for which the PATH variable may not contain /bin.
For example cron defaults to a very strict PATH of /usr/bin:/bin which is fine, sure, but other context/environments may not include /bin for some peculiar reason.
when the user screwed-up his PATH, which is very common with beginners.
for security when for example you're calling a suid program that invokes a bash script. You don't want the interpreter to be found via the PATH variable which is entirely under the user's control!
Finally, one could argue that there is one legitimate use case of env to spawn bash: when one needs to pass extra environment variables to the interpreter using #!/usr/bin/env -S VAR=value bash.
But this is not a thing with bash because when you're in control of the shebang, you're also in control of the whole script, so just add VAR=value inside the script instead and avoid the aforementioned problems introduced by env with bash scripts.
I have some code which works for me, but when I gave it to some colleagues, it broke. They're using tcsh whereas, as far as I can figure, I'm using csh.
I've tried:
csh -v
csh --version
csh -V
csh --help
csh -h
with no success (they all just take me straight to the interpreter prompt). I've also grepped the man page for the string "version", but I didn't come up with anything useful there either. Is there a way to determine the version of csh that I have installed?
-- Edit --
Following the symbolic links from /bin/csh, they seem to terminate at /bin/bsd-csh which seems to imply that I'm using some BSD flavor csh shell if that helps anyone. Also, I'm using ubuntu linux.
In comments, you've indicated that you're on Ubuntu, and that /bin/csh is a symlink to /etc/alternatives/csh, which is a symlink to /bin/csh.
The csh shell originated on BSD Unix, so it's not surprising that csh is an indirect symlink to /bin/bsd-csh. It goes back to 1978 or so, before it became common for Unix program to report their own version numbers.
Since you're on Ubuntu, this:
dpkg -l csh
should tell you what version you have -- though the version number of the Debian/Ubuntu package isn't likely to be more useful than the information you already have. And the relationship between the package version number and the version of the shell isn't entirely clear.
I'm assuming that's the right package name. If not, try dpkg -S /bin/bsd-csh.
You can tell whether you're running tcsh or not, like this:
if ($?tcsh) then
echo This is tcsh
else
echo This is csh, not tcsh
endif
tcsh is supposed to be backward compatible with csh, with some extra features, mostly for interactive use. A script written for tcsh could easily fail under csh if it uses tcsh-specific features, but I'd expect tcsh to be able to handle a csh script. As the tcsh(1) man page says:
tcsh is an enhanced but completely compatible version of the Berkeley UNIX C shell, csh(1).
I understand you probably can't post the entire failing script, but can you post a small representative example that works for you and fails for your colleagues?
One solution might be to ask you colleagues to install vanilla csh on their systems; they can still use /bin/tcsh as their interactive shell if they like, but #!/bin/csh would then cause the script to be executed by the old csh, not tcsh.
Finally, I can't answer a question about [t]csh scripting without adding a link to this.
Addendum: I have access to a Solaris system with a /bin/csh that isn't tcsh; I can run some simple tests there if you like. One data point: both /bin/tcsh and /bin/csh accept : as a null command, but with /bin/csh it doesn't accept arguments:
% :
% arg
:: Too many arguments
csh --version would work only if csh is actually a symlink to... /bin/tcsh(!)
Otherwise, a csh session doesn't seem to set any version, except in this MKSToolkit, where that csh is supposed to set a variable $csh_version.
Pre-defined Variables
The following variables have special meaning to the C Shell.
Of these, argv, csh_version, cwd, home, path, prompt, ROOTDIR, shell, status, COMSPEC, and TMPDIR are always set by the shell.
Except for cwd and status, this setting occurs only at initialization; these variables are then not modified unless done explicitly by the user.
See this dotfile for instance:
shell_is_csh () { return [ -n "$csh_version" ]; }
/bin/csh links to /etc/alternatives/csh which links to /bin/bsd-csh.
Apparently it's bsd-csh
... then bsd-csh doesn't seem to support any kind of version feature.
If you're using Ubuntu, then your csh is the OpenBSD version, with a few patches. It has absolutely no support for getting its version, being that it doesn't encode its version anywhere. Can't help you beyond that, though.
If you've not installed csh on ubuntu, but have installed tcsh, then it will use tcsh as an alias to csh. They are, as you've discovered, mostly compatible.
For yourself, you can probably debug the issue by using update-alternatives to redirect csh to tcsh (as long as you've installed tcsh as well).
Is it better practice to write Bash scripts or Bourne scripts? My team writes Bourne scripts but I am not entirely sure why.
If this is a holy war question (ie: vim vs. emacs) please just reply: holy war.
It depends on what your target platform is.
If you're only targeting, say, major Linux distributions and Mac OS X, then you can be confident that these systems will have bash available. On other UNIXes (e.g., AIX, Solaris, HP-UX), bash may not necessarily be present, so Bourne is the safer choice. If bash is available, I can think of no reason you might prefer Bourne.
You can be more sure that Bourne shell will be installed on any given Unix computer. Yeah, Bash is ubiquitous on Linux, but the whole world isn't Linux.
The most important thing is to remember that not every OS softlinks /bin/sh to /bin/bash, as some Linux distros do. A lot of scripts are written for bash but begin with:
#!/bin/sh
so that they break e.g. in Ubuntu. So, when you write bash script, always write:
#!/bin/bash
Well, is a matter of taste, but for starters, bourne shell scripts can be run with bash, and I think bash has features that cannot be run by Bourne.
I use Bash as my login shell, but for scripting I'd choose the Bourne shell any day of the week and twice on Sunday. Bash has better features, better user friendliness and better bugs.
Actually, the same stuff that makes me choose Bash when I'm logging in, makes me avoid it when scripting. Bash tries to make everything nice and cozy for the user, but at the expense of a 776 kB executable (on my machine), compared to 140 kB for Bourne shell. Why would my script care about user friendliness? Any gain I might achieve through the use of some clever Bash function is effectively cancelled out by the shell footprint, which is more than five times as big.
I have computers running Linux, FreeBSD and OS X. Although I rarely move anything between the computers, it's nice to have the possibility. In a Bourne shell script, you simply type
#!/bin/sh
and it just works. Always. Bash might be common on Linux, but it's not as standardized as the Bourne shell. On FreeBSD, Bash is not installed by default. It can be installed from Ports if the sysadmin thinks it's a good idea but, even then, it ends up in /usr/local/bin/bash (not /bin/bash). Thus, if you still decide to go with Bash, you should write
#!/usr/bin/env bash
to make the script portable. env will find the shell for you, regardless of your Unix flavor (as long as it's installed).
At the end of the day, it's your choice. Just make sure that your scripts are actually compliant to the shell you choose, and not relying on "sh" being symlinked to "bash" or something similar.
Portability. I write #!/bin/sh unless things get really to painful, and then I write #!/bin/bash. The world is changing very rapidly, and I'm betting that in the future it will be easy to convince sysadmins to install bash. But I hedge my bets by using Bourne for most stuff, which is simple.
On Mac OS X /bin/sh is NOT a Bourne shell. (But you may get a true bournesh over at freshmeat).
To identify a traditional Bourne shell you may try to use the circumflex ^ (caret) as a replacement for | (pipe).
See:
The Traditional Bourne Shell Family,
http://www.in-ulm.de/~mascheck/bourne/
I'd go for bourne again shell, as the bourne shell can be slightly different among unix implementations. With bash you can be sure that bash is always bash.