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
