From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gemma.TechFak.Uni-Bielefeld.DE ([129.70.136.103]) by hawkwind.utcs.toronto.edu with SMTP id <75569>; Wed, 13 Feb 2002 14:57:17 -0500 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by gemma.TechFak.Uni-Bielefeld.DE (8.9.1/8.9.1/TechFak/pk+ro20010720) with SMTP id UAA24948 for ; Wed, 13 Feb 2002 20:21:44 +0100 (MET) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id UAA01849; Wed, 13 Feb 2002 20:21:43 +0100 Message-Id: <200202131921.UAA01849@grimsvotn.TechFak.Uni-Bielefeld.DE> To: rc@hawkwind.utcs.toronto.edu Subject: non login "rc" needs customized environment X-PGP-Fingerprint: 85 89 64 AD 73 79 92 1F C8 76 95 2D 15 09 19 93 X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Wed, 13 Feb 2002 14:21:43 -0500 From: Peter Koch Folks, this must be a FAQ but since I did not find it in that old collection some of you may be able to shed some light on the following problem. We have been using "rc" as default login shell for more than 10 years now with currently 1000+ users in our department. Every now and then, but with increasing frequency recently we've felt uncomfortable with "rc"s handling of $HOME/.rcrc. It's only processed if "rc" is a login shell, which is not the case if you use rsh/ssh for calling commands on a remote system. Unfortunately this prevents users from customizing their environment there, especially the PATH variable. Calling "rc -l" explicitly, e.g. as in rsh foo 'rc -l ' < `{echo cmd} to enforce .rcrc processing is not always an option. Even worse, when using CVS you can ask the "cvs" command to use rsh/ssh to transparently check in/out objects on that remote system, but it needs to be able to find the appropriate "cvs" commands there, which it can't unless/before the PATH variable is set accordingly. Now "rc" users seem to lose. (There are similar scenarios, so a "cvs" only approach doesn't help, and changing the default PATH assignment also is not an option.) For these reasons we would like to trim "rc" to enable user environment customization even if "rc" is not marked as login shell. "bash" and "tcsh" support SHLVL which can be used to tell apart the top level (i.e. either login shell or first shell started by rshd/sshd) from any child or subsequent shell. So I would like to suggest to add this ``feature'' to "rc", to be activated optionally at compile time: 1) IF upon startup (SHLVL is not set or does not contain a numeric value) OR (shell is marked as login shell) THEN SHLVL=1 ELSE SHLVL++ 2) Process $HOME/.rcrc iff (sic!) SHLVL == 1 This may have backward compatibility issues with non-interactive, non-login top level shells (intentional, see above!) and also non-interactive login shells. Changing the code to accomplish this seems not too difficult, but since this is going to be an architectural change I'd like to learn other's opinions before- hand. Also, any better approach to the original problem or pointer to an existing patch would be fine. Thanks, Peter