On 07:42 20 Dec 2002, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
| from the man page for bash, when you run a script normally,
| it runs as a non-login, non-interactive script. but with
| one or more options, you can run it as a login script, an
| interactive script, or both (options being some combination
| of -l or --login, -i, etc.)
|
| running it in one of these ways will get the script to
| possibly consult the startup files like /etc/profile,
| .bash_profile or .bashrc.
|
| fair enough, but under what circumstances would someone
| *want* to consult any of those startup or config files when
| running a script?
For a script, pretty much never. Why would you when you can just
". $HOME/.bash_profile" if that's really what you want.
Those option exist to turn stuff on and off at will. For example, if
you're firing up a "login" shell for someone (real programs just exec()
bash with a leading "-" in argv[0], which is the standard way for all
UNIX shells).
BUT ...
| so i guess the question is, what are the reasonable
| circumstances where someone would *want* to run a script
| as a login or interactive (barring scripts that might be
| explicitly written to run only at login time).
Well, as a login shell? Me, never.
But interactive? Often.
An extended real world example follows.
Look at these scripts:
http://www.zip.com.au/~cs/scripts/slaves
http://www.zip.com.au/~cs/scripts/rslaves
and these shell functions which use them:
# make some slaves
enslave()
{ [ $# = 0 ] \
&& { if [ -n "$_slavefd" ]
then echo "Current slaves: $_slaves."
else echo "No slaves."
fi
return 0
}
[ -n "$_slavefd" ] && { echo "You already have a slave on fd $_slavefd
[$_slaves]" >&2
echo "Free it with unslave()." >&2
return 1
}
[ -n "$DISPLAY" ] || { echo "No \$DISPLAY! Can't pop slave terminals!" >&2
return 1
}
_slavepipe=`pipecmd rslaves -t "$@"` || return 1
_slaves=$*
exec 8>"$_slavepipe"
_slavefd=8
}
# dispatch command to the slaves
slave:()
{ [ -n "$_slavefd" ] || { echo "No slave!" >&2; return 1; }
eval "echo \"set -x; \$*; set +x\" >&$_slavefd"
}
# free the slaves
unslave()
{ [ -n "$_slavefd" ] || { echo "Nothing slaved." >&2; return 1; }
eval "exec $_slavefd>&-"
_slavefd=
}
# zsh preexec unction with hook to pass command to "slave:" function
preexec()
{ ttyl "$1"
[ -n "$_slavefd" ] && slave: "$3"
}
which are part of my shell setup.
Basicly, slaves is a generic "copy stdin to a bunch of other things"
script. rslaves does that to remote shells on other machines.
Example use: I keep home and work directory trees in sync with rsync.
Very efficient. But if I _rearrange_ things (eg move a big directory from
one spot to another) rather than just make new files then rsync sees a
huge new directory to copy. So for big moves I do them in both places.
So I type "enslave work", at home. That neatly pops up a small window
with a shell at work. From then on, any command I type at home is run
both at home and at work. So I can cd around and move stuff, and it's done
at both ends _exactly_ the same way without possibility of error.
Neat eh?
BUT, because stdin is not a tty for the ssh connection, the shell at
the far end is not interactive. Now, I don't _really_ want a tty at
the far end; I'm sending _post_ typing stuff down there, which could be
misinterpreted. But I do want prompts and most of the other interactive
trappings (eg a failed "cd" doesn't about the shell, etc).
And so I invoke the remote shell with the "-i" option (in the rslaves
script), which gets me prompts and also the .bashrc (well, .zshrc for me,
but you get the idea) so that my usual shell functions and aliases are
also in force.
There are other similar circumstances one may imagine - this is just
the one I have been using recently.
Cheers,
--
Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/
Remember the Unified Field Theory? Well, forget it. Physicists have
pretty much thrown in the towel on unifying gravity with the other
elemental forces, so now we have the Standard Model, which says that
everything works together in intricate harmony except gravity, which is
on holiday in Tasmania and need not concern us further.
- Jon Carroll on the Higgs Boson
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
