Bug#275140: Redirections and noclobber
<warning: this is a bit long>
Okay, so here's how bash initialization works, AFAICT.
This is condensed from the bash info/man page.
Bash initialization is pretty complicated;
I believe this is b/c it's intentionally very flexible.
- shells/sessions can either be:
- login or non-login
- interactive or non-interactive
What makes this confusing in that there's thus 4 types of sessions,
[which is already sorta confusing]
but only 2 default files.
----------------------------------------
I only meaningfully use two types of sessions:
- interactive
- shell scripts
An easy way to deal with this is to:
- start all interactive shells as login
- put the following at the top of ~/.bash_profile:
set BASH_ENV=~/.bashrc
source ~/.bashrc
Then the rest of ~/.bash_profile contains the interactive-specific
settings, and ~/.bashrc is the "general settings".
However, this obscures the essential roles of the initialization
files.
----------------------------------------
Here's how it actually works:
[throughout, "source" means "source if exists"]
- login shells
(I don't know any sense in non-interactive login, but you can do it)
source /etc/profile, then source the first available
[meaning exists and is readable] of:
~/.bash_profile, ~/.bash_login, ~/.profile
They doesn't touch ~/.bashrc or BASH_ENV.
On logout, it sources ~/.bash_logout
- non-login interactive shells
source /etc/bash.bashrc, then source ~/.bashrc
They doesn't touch ~/.bash_profile or BASH_ENV.
- non-interactive, non-login shells
source $BASH_ENV
[I don't know if non-interactive login shells source this.]
They doesn't touch ~/.bash_profile or ~/.bashrc
Thus, you can have entirely different behavior for all of these.
Philosophically, a login shell might do stuff like ssh-add or
nfrm or whatever, which you only need to do once,
while non-login interactive shells are what you start in an xterm, say.
These are often viewed as -layers-:
+ non-interactive (shell scripts)
+ non-login interactive
+ login-interactive
where each succeeding layer adds more settings.
Two common techniques:
- have ~/.bash_profile source ~/.bashrc
typically a login session is a regular interactive session, plus
some one-shot programs
- set BASH_ENV=~/.bashrc
then include a section in ~/.bashrc that reads:
if [ -n "$PS1" ]; then
# set whatever interactive things you want
fi
so you can use ~/.bashrc for shell scripts as well,
but not set the interactive things.
[This is what Julian suggests.]
##################################################################
-Personally-, my shell scripts and interactive sessions run
in essentially the same environment;
all I change is that my interactive sessions set the prompt,
aliases, completions, dircolors -- stuff that's not useful
on non-interactive sessions.
[I do this b/c otherwise I get very confusing bugs in
scripts, that I can't reproduce at the commandline, as the
environment is different.]
This is not to say that this is the -right- way of doing
things, or that Debian should support it, only that it's the
way I do things, and perhaps others.
A further personal feeling (not a policy recommendation) is
that when I wish to clobber a file in a shell script, I
should explicitly write >| (to force clobbering); if I write
just > (w/o forcing clobbering), it means I expect no file
is there, and should abort if there is one.
##################################################################
So in sum:
[to answer Frank's question]
- it's not that "set -o noclobber" gets inherited,
it's that I explicitly set it for non-interactive shells
(it's in my ~/.bashrc, and I set BASH_ENV=~/.bashrc),
hence they affect packaging scripts.
Note that I run su as "sudo bash", so root uses the same
environment as I do (and thus has the "set -o noclobber").
- to clarify my suggested resolutions:
I can see 3 resolutions:
1: use >| to force clobbering
2: have "set +o noclobber" in the script to turn off noclobber
3: require folk to not set noclobber in their .bashrc
(i.e., WONTFIX)
1 & 2 allow people to have whatever environment they want,
and relies on the package maintainers to specify explicit
clobbering.
3 makes life easier on the package maintainers (they can
write > instead of >|), but requires people to have a
specific bash environment (viz., one that doesn't set
noclobber).
This is a general philosophical question:
"what assumptions should package scripts make about their environment?"
with concequences rather beyond just noclobber.
I'm new to Debian, so I don't know if there is some
consensus answer to this question, and I wasn't able to find
one through googling.
My personal feeling is:
"If not too hard, make packages scripts run independently of environment."
and I suspect that this is (unofficial?) Debian policy,
which is why I suggested using >|
That is, Debian and Free Software in general usually try to
be highly portable, within the limits set by reason.
It's -possible- that many, many installation scripts assume
that noclobber is not set -- I don't know.
This is a practical question, however, not a philosophical one;
if policy is (or it is decided) that packaging scripts should not
assume that noclobber is set, and many scripts assume this,
then it's a bug and would require work to fix, but it may
not be a very pressing bug, and could be fixed as it affects
people (e.g., I could report it whenever it happens to me --
I just updated ~300 packages, and only the teTeX/doc-dsssl ones
were affected).
Note that if this is the case (many packages make many
assumptions about the environment), then package scripts
could all read some standard file like
/etc/dpkg/bashrc
or whatever that specifically sets up a nice environment.
So in sum, I have two questions/unknowns:
Q1: Does Debian have a policy on assumptions on the
environment that packaging scripts can make?
Q2: Regardless of policy, do many packaging scripts in fact
make such assupmitions?
Thanks again for your attention.
salaam,
nils
Reply to: