[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: *term -ls, a summary

On Thu, 2002-07-25 at 15:02, Isaac To wrote:
> >>>>> "Adrian" == Adrian 'Dagurashibanipal' von Bidder <avbidder@fortytwo.ch> writes:

> 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.

Strongly agree. Other initialisations should happen with $BASH_ENV, to
be set from your profile.

>     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

No, I don't think so. Leave profile and bashrc, and write pam modules
and move things from profile to pam. You end up with an empty profile,
much better.

> 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.

Such a module would be really GREAT - you'd finally have the same
'profile' executed from all ?dm, bash and even if you execute something
for once in a while from a tcsh login...

> 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?

Good question. Probably because pam does not get the attention it

-- vbi

secure email with gpg                         http://fortytwo.ch/gpg

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: