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.
