Re: *term -ls, a summary
>>>>> "Manfred" == Manfred Wassmann <debian-devel@NCC-1701.B.Shuttle.de> writes:
Manfred> I am fully aware of that distinction, that is why I wan't (and
Manfred> do) have my xterms started with -ls. All I want is *one*
Manfred> option in *one* place for all desktop
Manfred> environments/window-managers/terminal-emulators to set this
Manfred> behaviour.
Just place the modification in .bashrc (everything in the same place)?
Manfred> The current situation really sucks. We have more than a dozen
Manfred> terminal emulators and about the same amount of window
Manfred> managers/desktop environments and you have to configure each of
Manfred> them seperatly. And everytime you start a different one you are
Manfred> stuck with that bloody default.
Only if the you take the view of the standing you expressed in an earlier
mail (below). But then, how many times does you "start a different one"
(i.e., how many times do you switch to use another terminal emulator)?
Manfred> Opening an xterm for interacting directly with a shell is IMHO
Manfred> functionally the same as opening an VC. And I am really pissed
Manfred> off if I don't get a login shell and the profiles aren't
Manfred> sourced. It's different of course if you open the xterm to run
Manfred> a program which is not a shell.
If you think that this is the way to interpret "a login shell", it is
reasonable that shells coming from the "terminal" button should be login
shells. IMNSHO, this is not the right thing to do. The "exception clause"
you have mentioned at the end indicates the problem: being a login shell or
not depend on the program executed, on a case-by-case basis. If you have a
terminal running "sh", you want it to be a login shell. If you have one
running "sh -c 'aptitude'", you want it to be a non-login interactive shell.
That is a mess---at least, that is for me.
The problem is basically about semantics. Once we fix the semantics,
incorrect programs should be fixed (perhaps locally in Debian only),
usability problems can be worked around. If the semantics is not right, all
we get is just an ad-hoc combination of treaks that sometimes work and
sometimes won't. There are so many different combination of terminal
emulator, shell and application programs there, that we can't really afford
to be inconsistent.
What I think login shell is all about is quite simple. Login shell is a
shell where you first receive your identity (or uid) and thus environment.
So if you start X using xdm or gdm, whatever related to the uid acquisition
is done by the .xsession or .gnomerc files, which serves the purpose of
"login shell" initializations. Similarly, if you login from a virtual
console, you get a login shell. If you get a shell using ssh, you should
get a login shell---no matter whether the shell executed by your ssh session
is used just for one program or for many programs. On the other hand, if
you "startx" after getting a virtual console, or push the X terminal button,
or run bash from your own shell, you are not acquiring a new identity, so
you shouldn't get a login shell (unless you request explicitly, of course.)
I think that is quite important. The .profile file is the important place
to put session-wide customizations like PATH, umask, etc. If my shell
initialization makes my umask to be 027, and I change my umask to 077
manually before executing "startx", I really won't expect the umask will
suddenly become 027 again. If I get a shell using ssh, I expect I get a
terminal that has 027 as umask, no matter whether I'm running a single
program with it using the command option, or I get an interactive shell.
The system should be clean enough...
.xsession (or whatever): should really source .xinitrc after setting the
environment.
.xinitrc: everything that you want to appear everytime you see X
.profile: should really source .bashrc after setting the environment.
.bashrc: everything that you want to happen in every interactive bash
instance.
.login: should really source .cshrc after setting the environment.
.tcshrc: everything that you want to happen in every tcsh instance.
There are actually quite a few places that Debian didn't support the above
view. E.g., xsession is always executed, no matter whether it is from a
display manager or from startx. Well, I can change my config files,
but... why Debian itself cannot be more consistent? A week ago somebody
asked me how to change the default remote umask when using sftp. I don't
know how to answer, except asking him to write a umask-changing PAM module
himself. Why that is not set when ssh acquires its uid?
Regards,
Isaac.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: