StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>First of all, you should very seldom use <code>$*</code> and you should almost always use <code>"$@"</code> instead. There are a number of questions here on SO which explain the ins and outs of why.</p> <p>Second - the <code>env</code> command has two main uses. One is to print the current environment; the other is to completely control the environment of a command when it is run. The third use, which you are demonstrating, is to modify the environment, but frankly there's no need for that - the shells are quite capable of handling that for you.</p> <p>Mode 1:</p> <pre><code>env </code></pre> <p>Mode 2:</p> <pre><code>env -i HOME=$HOME PATH=$PREPENDPATH:$PATH ... command args </code></pre> <p>This version cancels all inherited environment variables and runs <code>command</code> with precisely the environment set by the ENVVAR=value options.</p> <p>The third mode - amending the environment - is less important because you can do that fine with regular (civilized) shells. (That means "not C shell" - again, there are other questions on SO with answers that explain that.) For example, you could perfectly well do:</p> <pre><code>#!/bin/bash export PATH=${PREPENDPATH:?}:$PATH exec python "$@" </code></pre> <p>This insists that <code>$PREPENDPATH</code> is set to a non-empty string in the environment, and then prepends it to <code>$PATH</code>, and exports the new PATH setting. Then, using that new PATH, it executes the <code>python</code> program with the relevant arguments. The <code>exec</code> replaces the shell script with <code>python</code>. Note that this is quite different from:</p> <pre><code>#!/bin/bash PATH=${PREPENDPATH:?}:$PATH exec python "$@" </code></pre> <p>Superficially, this is the same. However, this will execute the <code>python</code> found on the pre-existing PATH, albeit with the new value of PATH in the process's environment. So, in the example, you'd end up executing Python from <code>/usr/bin</code> and not the one from <code>/home/pi/prepend/bin</code>.</p> <p>In your situation, I would probably not use <code>env</code> and would just use an appropriate variant of the script with the explicit export.</p> <p>The <code>env</code> command is unusual because it does not recognize the double-dash to separate options from the rest of the command. This is in part because it does not take many options, and in part because it is not clear whether the ENVVAR=value options should come before or after the double dash.</p> <p>I actually have a series of scripts for running (different versions of) a database server. These scripts really use <code>env</code> (and a bunch of home-grown programs) to control the environment of the server:</p> <pre><code>#!/bin/ksh # # @(#)$Id: boot.black_19.sh,v 1.3 2008/06/25 15:44:44 jleffler Exp $ # # Boot server black_19 - IDS 11.50.FC1 IXD=/usr/informix/11.50.FC1 IXS=black_19 cd $IXD || exit 1 IXF=$IXD/do.not.start.$IXS if [ -f $IXF ] then echo "$0: will not start server $IXS because file $IXF exists" 1>&2 exit 1 fi ONINIT=$IXD/bin/oninit.$IXS if [ ! -f $ONINIT ] then ONINIT=$IXD/bin/oninit fi tmpdir=$IXD/tmp DAEMONIZE=/work1/jleffler/bin/daemonize stdout=$tmpdir/$IXS.stdout stderr=$tmpdir/$IXS.stderr if [ ! -d $tmpdir ] then asroot -u informix -g informix -C -- mkdir -p $tmpdir fi # Specialized programs carried to extremes: # * asroot sets UID and GID values and then executes # * env, which sets the environment precisely and then executes # * daemonize, which makes the process into a daemon and then executes # * oninit, which is what we really wanted to run in the first place! # NB: daemonize defaults stdin to /dev/null and could set umask but # oninit dinks with it all the time so there is no real point. # NB: daemonize should not be necessary, but oninit doesn't close its # controlling terminal and therefore causes cron-jobs that restart # it to hang, and interactive shells that started it to hang, and # tracing programs. # ??? Anyone want to integrate truss into this sequence? asroot -u informix -g informix -C -a dbaao -a dbsso -- \ env -i HOME=$IXD \ INFORMIXDIR=$IXD \ INFORMIXSERVER=$IXS \ INFORMIXCONCSMCFG=$IXD/etc/concsm.$IXS \ IFX_LISTEN_TIMEOUT=3 \ ONCONFIG=onconfig.$IXS \ PATH=/usr/bin:$IXD/bin \ SHELL=/usr/bin/ksh \ TZ=UTC0 \ $DAEMONIZE -act -d $IXD -o $stdout -e $stderr -- \ $ONINIT "$@" case "$*" in (*v*) track-oninit-v $stdout;; esac </code></pre>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload