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. A tmux session could be attached from dozens of parent shells with different environments during it's life. Spawning login shells makes sense. And I am not saying we should force login shells - this will always be configurable somehow. > > > 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. > > > 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? > > > 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. 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. > > Regards. > -- > J??r??mie Courr??ges-Anglas > GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
