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 should? cheers -- vbi -- secure email with gpg http://fortytwo.ch/gpg
Attachment:
signature.asc
Description: This is a digitally signed message part