Re: *term -ls, a summary
>>>>> "Osamu" == Osamu Aoki <debian@aokiconsulting.com> writes:
Isaac> Just place the modification in .bashrc (everything in the same
Isaac> place)?
Osamu> It works but ... aesthetically bad. This is parsed every time
Osamu> interactive sub-shell is invoked. You do not need to export
Osamu> environment over and over.
"Do everything in .bashrc" is just a suggestion to the original poster based
on his (IMO, weaker) idea of login shell. :) The discussion below that
should make it clean that I'm not in that camp.
On the other hand, it is not *just* aesthetically bad. (I can withstand the
lost of a few milliseconds to set the environment variables, umask, ulimits,
current directories, etc. :) As I've said in the last mail, if I:
login through virtual console
type "umask 022" (or "PATH=$PATH:/usr/bin/foo")
"startx"
create a new terminal
I'll expect that the modification of setting will still be there in the new
terminal. If I set everything in .bashrc, it will override my manual
setting, which is not quite nice.
Isaac> how many times does you "start a different one" (i.e., how many
Isaac> times do you switch to use another terminal emulator)?
Osamu> Everytime invoking new terminal :)
Osamu> $ xterm & $ kterm &
Most terminal emulator has a configuration file which let you specify
whether you want to have login shell by default. By "switch to use another
terminal emulator", what I really mean is, "use a terminal emulator which
you have never used before". There are not really that many terminal
emulators, and if I count the number of them that are used enough that I
care to make the setting, I can count only 1. I don't think it is too much
to ask if the user does not match the idea of a "login shell" from that of
the distribution. Anyway, that is just an alternative suggestion that is
given to the original poster based on his idea of login shell. I won't do
it at all. :)
Osamu> /etc/X11/xinit/xinitrc is just ". /etc/X11/Xsession"
Isaac> There are actually quite a few places that Debian didn't support
Isaac> the above view. E.g., xsession is always executed, no matter
Isaac> whether it is from a display manager or from startx.
Osamu> Because /etc/X11/xinit/xinitrc is just ". /etc/X11/Xsession".
I perfectly understand the code fragments that make up the current situation
(I'm a programmer :). I just don't quite agree that it should be done that
way. The only excuse is that different developers have different ideas
about what is a login shell, so each code to their own model.
>> .profile: should really source .bashrc after setting the environment.
>> .bashrc: everything that you want to happen in every interactive bash
>> instance.
Osamu> This approach ensures functionality you wants but is likely to
Osamu> execute redundant codes. That's why all the serious debian
Osamu> people was talking about PAM.
Agree with the latter part (use PAM! [see my other post]), except that
currently there is no module for that purpose (write one?).
On the other hand, I don't agree that it executes redundant code. If you
don't want your environment settings to be done many times, do it in
.profile, as the "setting the environment" part. The same holds for
.xsession. If you write into .bashrc something that needs to be done once
per session, you can't really blame the system for executing everytime you
run a sub-shell. On the other hand, there are actually things (e.g.,
setting shell, non-environment variables) that needs to be done for every
shell.
>> Well, I can change my config files, but... why Debian itself cannot
>> be more consistent?
Osamu> Debian is consistent. It just has different idea from your idea.
Really curious about that. What is Debian's idea on login shell? What's
the defination of "login shell" that matches well with all packages? BTW, I
don't think the description in the man page of bash is a definition. It
tells when bash will consider a shell to be a login shell, but it never
tells when such a shell should be created, and what extra responsibility are
carried by a login shell.
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: