Adding -l option to /bin/sh

[Robert Elz <kre%munnari.OZ.AU@localhost>]

There has been a bunch of discussion in various places, most
recently as part of the PR xsrc/54851 about (amongst various
other things) adding a -l option to sh.

The option exists in many other shells - its purpose is to make
the shell into a login shell (and hence can also be written -o login)

Normally (traditionally - going back as far as I can remember) a
login shell was denoted by when login exec's it, making argv[0]
start with a '-'.   That still works today, it is still used today,
and will continue to work (and be used).

The -l option (and its negative form) +l simply override the default
decision made by testing argv[0]; -l will make the shell a login
shell, regardless of argv[0], and +l will make it a normal shell,
again, regardless of argv[0].   (the -o or +o version does the same thing).

The option will be available to the set command (more because preventing
that costs more code than allowing it than for any benefit) which it isn't
in all shells that support -l (eg: bash) - but note that being a login shell
means exactly one thing internally.  When a login shell starts (after
processing the args, and setting variables from the environment) it reads
/etc/profile and $HOME/.profile (in that order, and assuming those files
exist, if not, nothing happens, the shell just continues to the next step).
That's it.  No user supplied code (regardless of source) is run
before that decision is made, and once made, whether the shell is a
login shell or not is 100% irrelevant to everything.   That is, changing
the option after the shell is running affects nothing but what expanding $-
produces.

All of that is simple, this is close to free in the shell, and is
almost certainly going to happen.

There is one open question though. (Perhaps two, depending how you look at it) 

That is, should it be possible for a login shell to have a -c arg (requiring
a later arg to be commands to execute) or a script file name ?

(A possibility is to simply force +l in either of those cases - it would
not be treated as an error).

Currently it works - except you need to take extraordinary measures to
make it happen, as login (and a few other things which can create login
shells, like xterm (its -ls option)) never invokes a login shell with
either -c or a script name.   You have to make it happen yourself (it
is possible, in a couple of ways, and not even all that difficult, but
no-one normally bothers).

Note that if a script (whether in a file, or as the arg used with sh -c)
wants to read /etc/profile or $HOME/.profile it can do using the '.'
command (perhaps after a test that the file exists).   Since that's all
being a login shell does, and as making it happen that way is so easy,
taking the extra measures necessary to make that happen by invoking the
shell as a login shell just isn't something anyone does.

With -l though, that all changes - if we allow it.   Adding a -l option to
a sh invocation is trivial (it can even be in the #! line if one wants).

So, the question is, should we allow that or not?   Many shells (but not
all - our csh is one of the "not all") do allow it.   Allowing it to happen
actually saves some code (in /bin/sh -- two "x=0;" statements can be deleted,
one for each case, the -c case, and the script file case ... the decision can
be different for the two, that's why the "perhaps two" earlier.)

My personal inclination is that allowing "sh -c 'any command'" to be a login
shell is kind of perverse.  It clearly isn't one.  The same for "sh file".
But that's partly just because of what it is called.   If it was called
"profile reading shell" instead, maybe I'd think differently (what it is
called, and the option to use, isn't going to alter, that's all set in stone
in other places already.)

It is also partly as one of the things that profile files often do, is
issue stty commands (or tset for those who prefer that) to set the terminal
to a known state - and users typically don't want that to happen just
because of running some command that wants to run as a login shell, or
to execute the profile files.   Other (normally) one time user session
starting options can also be performed there (one possibility is for the
profile file to start X for you).

So, opinions?

kre

ps: the code for all of this is ready to commit, not that there is much of
it - the biggest change is to the man page.