Re: *term -ls, a summary

[Isaac To <kkto@csis.hku.hk>]

>>>>> "Adrian" == Adrian 'Dagurashibanipal' von Bidder <avbidder@fortytwo.ch> writes:

    Adrian> [1] (Login, non-interactive shell) Should this occur?

I think the concepts say "yes".  E.g., if you type "ssh <host> <mycommand>",
the shell really should be a login shell, even though the shell is not used
to interact with the user.  However, in practice, this does not happen.
This is one of the position where I think the system is broken: without
running .profile, the environment is "halfly configured".  I.e., my programs
run with PATH (and other environment variables) set to a value different
from what I usually use, its umask does not match my own policy, or user
limits not set, etc.  It is like using an auto variable uninitialized from
main(): it will have initial value, it will be the same everytime you run
the program (because the kernel clear the memory), but it will not be easy
to know what value it is set to, and it can change everytime you upgrade
your compiler.  In fact, when I actually use "ssh" in any serious way, I
always have to do something like "ssh <host> '. .profile; <mycommand>'"
instead of the simple command shown above.  I see this a rather stupid way
to follow the broken behaviour of rsh.

    Adrian> So ssh <host> <somecmd> should invoke <somecmd> from a login
    Adrian> shell?

See above.  Even "sftp <host>" should execute the ssh tunnel in a login
shell, I believe.  There is one more technicality: the .profile file should
source the .bashrc file only if it is a interactive shell.

    Adrian> At the top of the default .bashrc: --- ~/.bashrc: executed by
    Adrian> bash(1) for non-login shells.  ..  # If running interactively,
    Adrian> then: ---

    Adrian> which suggests that .bashrc is also read for non-interactive
    Adrian> shells (it usually isn't), and fails to mention that with the
    Adrian> default configuration it is also read for login shells from
    Adrian> .bash_profile.

There is a more neat solution, though.  Forget completely about the
distinction about login shell and non-login shell.  Simply link .profile and
.bashrc to the same file (or let one source the other).  Just do all things
supposed to be done by .profile by a PAM module.  A session module in the
lines of pam_env.so, except that it reads a file in the home directory of
the user with a fixed filename (say, .env).  The syntax of this file is
preferably similar to sh, and should at least have power to set environment
variables, set ulimits, set umask, change current directory, and run a
program.  Of course it would be better if there are constructs for
conditional execution and local variable assignments.

My problem with the current system is that session setup really shouldn't be
the task of bash in the first place.  Somehow early systems don't have a GUI
and won't have network connection, making it possible to "overload" the sh
program to do the initialization.  But now, when there are many shells that
can be set to the users' shell, and when there are many ways to get a shell
program running, it feels rather stupid to need each of them implementing a
mechanism for setting up the initial environment.  If PAM is designed to
delegate all these tasks, why don't use it to the full extent?

Regards,
Isaac.


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org