martin f krafft writes:
> > Well, only if /bin/sh is bash.
>
> No, also with dash and zsh. And for the cases where $SHLVL is not
> set, my patch will just no-op.
I tested dash here and it didn't (the man page also makes no mention of
SHLVL either). Are you sure? As for zsh, I suppose I should have assumed
it has everything ;-)
I guess my point was just that if it says #!/bin/sh it's a script for
any POSIX shell and this is a workaround for a feature in shells that
are a superset of POSIX. I'd like to see dash as the default /bin/sh
sooner rather than later so that things like this don't come up.
> Well, yes and no. I use SHLVL to tell make my $PS1 tell me when I am
> in a subshell. I don't care that there are already two shells
> involved just to get the terminal (xsession (where I reset SHLVL
> myself) + urxvtcd).
I'm not *strongly* opposed to doing something in rxvt-unicode, but I
do think this (I mean, SHLVL itself) is an ugly hack. Isn't what you
actually want here counting *interactive* shells? From a little googling
it seems that what people want SHLVL for is displaying something in PS1
or otherwise modifying interactive behavior. For this purpose I think
something like
case $- in
*i*) ishlvl=$(($ishlvl+1));;
esac
would be more useful (do normal programs, as opposed to shell init
scripts, ever consult SHLVL?). As you said, the value SHLVL normally
"starts at" sitting in front of an X session is totally arbitrary and
useless. I'd really prefer to discourage its use.
> Plus, the shell that spawns urxvtcd or urxvtd will not be around
> anymore when the terminal is spawned:
Right, but the definition of SHLVL doesn't say anything about this.
So, if bash runs my ~/.xsession, the SHLVL in the environment is still
incremented when that shell disappears by exec-ing the session manager.
> Sure, but let me ask you the opposite, in the face of the
> aforementioned "the shell that spawns urxvtcd or urxvtd will not be
> around anymore": why should $SHLVL be incremented at all?
Well, I also think this is dumb, but only because I think SHLVL itself
is dumb. :-) It seems to be the natural consequence of the design
-- if some random thing happened to be invoked by a shell, SHLVL is
incremented, whether we care about it in the real world or not. Adding a
workaround here is possible, but won't fix that broken design for other
programs.
--
things change.
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
