Hi I don't really mind too much what the method is to turn login shells off and if you want to improve that, great (although -l is not a good solution), but the default needs to stay with them on.
I think it makes sense to have login shells by default. It's fine if you disagree but - like several other options - I don't think there are good reasons or any consensus to change, especially since it is easy to configure. I'm afraid tmux defaults are never going to please everyone. Some even had the gall to hate on the nice green status line ;-). On Thu, Jun 21, 2012 at 02:55:21PM +0200, J??r??mie Courr??ges-Anglas wrote: > Nicholas Marriott <[email protected]> writes: > > > On Thu, Jun 21, 2012 at 10:21:08AM +0200, J??r??mie Courr??ges-Anglas > wrote: > >> Nicholas Marriott <[email protected]> writes: > >> > >> > I think it is correct and better to spawn login shells by default, these > >> > are not child shells of some shell process, they are entirely new > >> > shells. > >> > >> I think we disagree here, they *are* children of some shell process, > >> (unless tmux is directly spawned as the user's login shell, of course). > >> When a user logs in, a login shell is spawned, which reads (for > >> bourne-like shells as ksh) /etc/profile and ~/.profile, if present. > >> > >> Those files traditionally contain commands that only need to be launched > >> once, such as exporting environment variables, automatically launching > >> applications such as ssh-agent, expensive actions, etc. > >> > >> Interactive shells, then, can benefit from the environment that has been > >> set up. If an interactive shell needs more automatic configuration, > >> e.g. terminal-specific stuff, another dotfile can be used. ksh has ENV, > >> bash uses ~/.bashrc. This, imho, is much more flexible. > >> > >> And it has been the way to do it since a long time. I believe that the > >> behaviour of GNU screen matches that. > > > > I don't agree and this doesn't change my mind, sorry. > > Though I find my arguments to be pretty convincing, and am also sorry > about that. But ok, I was kinda expecting it wouldn't be easy to > convince you. :P > > > A tmux session could be attached from dozens of parent shells with > > different environments during it's life. > > Sure, and tmux already comes with update-environment, which has sane and > useful defaults. If one doesn't like this, using ENV='~/.kshrc' (*) (or > ~/.${SHELL}rc, doesn't matters) is still an option and is imho *exactly* > why the concept of login shell exists (a behaviour different from a non > login interactive shell). > > (*) this is a bit related: perhaps would it be interesting to have ksh > read by default ~/.kshrc on interactive shells (letting the user > override it with ENV in ~/.profile); and then ship a bare-bones .kshrc > in /etc/skel/. > > > Spawning login shells makes sense. And I am not saying we should force > > login shells - this will always be configurable somehow. > > Of course, I understand that you're not saying such a thing. What > bothers me is that it is "on" by default, which I believe is against the > usual way to do it (*), *and* that the ways to disable it are not clean > imho. > > (*) Of course, if a certain behaviour was wrong, then it would make > sense to change the default. I'm not going against what's done to > improve a given situation. > > >> > There is already an option to change it, default-command. I don't see a > >> > problem spawning two shells, > >> > >> The result being: > >> > >> ksh -c 'ksh' > >> > >> or > >> > >> ksh -c 'exec ksh' > >> > >> showing in ps(1) output. > >> > >> In the first case, you have useless processes entries, which sucks. > >> There is a soft limit of 128 processes per user, in the OpenBSD default > >> login class, and this one is pretty easy to reach, especially with > >> current desktop environments. > >> > >> In the second case, the first ksh instance is replaced, but you still > >> have exec'ed twice ksh. Which imho is a hint that there is something > >> wrong. > > > > But it works, right? Lots of things are run with sh -c, it's harmless. > > "It works" isn't what I'm talking about. tmux is an awesome, clean, > elegant piece of software. The fact I should revert to "sh -c 'exec > ksh'" to get what I think should be the default goes against that. > Yes, nitpicking. > > >> > shells are running, started, exited all the > >> > time and fork is not expensive anymore. What exactly is the issue with > >> > this? Do you have any boxes where this is noticeably slower than one > >> > shell? How much? > >> > >> The fewer commands you run when spawning a new tmux window, the faster > >> you get to the promt, especially is your box is loaded. Yes, I only > >> have (ok, not so) slow machines, and I see a difference in use. No, > >> I don't have *precise* numbers to show right now. > > > > So there is no problem except that it doesn't feel right? > > My ~/.profile isn't huge, and I *feel* the lag. I have a crappy > Atom-based laptop, and often do heavy processing on it. tmux spawning > login shells makes it uncomfortable, but is much snappier when using my > (trivial) diff. Also, lots of people are using tmux on slower machines > than mine. > > >> > If you can convince me it isn't a good idea and we need an option, I > >> > would suggest making some new prefix to default-shell like "+", so > >> > "+/bin/sh" doesn't run a login shell. > >> > >> I don't want to convince you that we need an option to *disable* > >> spawning login shells, but that not spawning login shells should be the > >> default. Users that *want* tmux to spawn login shells can already use > >> the -l switch or set tmux as their login shell, my diff does take care > >> of not clobbering this feature, I think. > > > > I am not going to change the default without a good reason. > > Well, I believe it wouldn't change anything anyway, except for people > that didn't bother/know about using a ~/.kshrc and think that they can > put dynamic reconfiguration in their ~/.profile. This kind of people > would expect that just typing "exec ksh" would re-read their ~/.profile, > which is wrong, and should revert to "exec ksh -l". Which breaks the > least astonishment principle. > > Also, I know that tmux has gone portable since a long time (since the > beginning, perhaps?), but at least on OpenBSD people are expected to > read release notes and see if introduced changes do impact their setup. > > Moreover, new users on other platforms would also have tmux behave as > GNU screen and graphical terminal emulators in this regard, this can be > seen as a Good Thing (tm). > > > If you want it to be easier or nicer to turn them off, then perhaps a > > login-shell option (server, session, window option, whatever). Using a > > command-line flag here is less useful than an option because it can't be > > set in the config file. > > Sure. Assuming I succeed in convincing you and the other developers, > some people might prefer using a login-shell tmux option than having to > use stuff like ... > > alias tmux='tmux -l' > > ... or having default-command set to ... > > sh -c 'exec ksh -l' > > See what would you have to do to get non-standard behaviour. ;) > > Another approach would be having the default-shell checked to see if it > begins with a "-". default-shell should be an absolute path anyway, and > similar logic is already present in names.c. > > I could come up with another diff, if you agree with me about this. But > I still think the default should be changed. ;) > > I'll stop here about this "defaults to login shell" concern. I hope > that my arguments were read as constructive, my will is only to try to > help a bit about improving tmux and OpenBSD, which are pieces of > software that I love. > > Thanks for your attention. > -- > J??r??mie Courr??ges-Anglas > GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
