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
> 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. The environment can be modified with ssh, via ~/.ssh/environment. ssh also provides ~/.ssh/rc to run commands before the user's command is started. It's run by the user's login shell as taken from the password file. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet) Chet Ramey, CWRU chet@po.CWRU.Edu http://cnswww.cns.cwru.edu/~chet/
| The environment can be modified with ssh, via ~/.ssh/environment. ssh | also provides ~/.ssh/rc to run commands before the user's command is | started. It's run by the user's login shell as taken from the password | file. The ssh/rc thing is busted. The user's session doesn't inherit the environment it computes.
rsh should really be called rcsh; it fails miserably with any other shell. I've dealt with the rsh problem by writing a wrapper script for rsh which also deals with the fact that rc isn't on the default path on my work network, and not available as a login shell either..
This behavior with rsh has always been a problem -- csh gets around it with .cshrc, and I wonder if some similar solution might be necessary for backward compatability. I love the SHLVL hack, but if you put it in place, then rc will now process .rcrc differently across different versions of the shell, and I'd prefer some backward compatability if at all possible. I think it's a good topic for discussion though. Byron.
On Wed, Feb 13, 2002 at 09:16:59PM -0500, Scott Schwartz wrote:
> | The environment can be modified with ssh, via ~/.ssh/environment. ssh
> | also provides ~/.ssh/rc to run commands before the user's command is
> | started. It's run by the user's login shell as taken from the password
> | file.
>
> The ssh/rc thing is busted. The user's session doesn't inherit
> the environment it computes.
yes, but sshd behaves like this since 1995, and it's not
always a good idea to change the default behaviour.
Back when I used rc, I ran a patched version that understood the -C switch that csh gets from rsh, and basically did the same thing. It wasn't necessarily pretty, but it worked. ../Dave
[ On Thursday, February 14, 2002 at 08:35:31 (-0500), Smarasderagd wrote: ]
> Subject: Re: non login "rc" needs customized environment
>
> rsh should really be called rcsh; it fails miserably with any other
> shell.
Rsh works perfectly well with any and every shell.
With ksh and its clones though there are better ways of setting up a
per-user specified environment, just as with csh....
The reason is of course that csh and ksh have a default way of reading a
script specified by the environment variable ENV, which has a default
value specified at compile time....
(in pdksh you have to define DEFAULT_ENV at compile time to enable a
default ENV script....)
Perhaps 'rc' could use a similar technique.
--
Greg A. Woods
+1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
Markus writes: | yes, but sshd behaves like this since 1995, and it's not | always a good idea to change the default behaviour. True. But we could add a new mechanism which would be able to compute the environment for the session.
| This behavior with rsh has always been a problem -- csh gets around | it with .cshrc, and I wonder if some similar solution might be necessary | for backward compatability. Take a look at what zsh does. There are lots of cases one might want to handle, once you start in with different config files: STARTUP/SHUTDOWN FILES Commands are first read from /etc/zshenv. If the RCS option is unset within /etc/zshenv, all other initialization files are skipped. Otherwise, commands are read from $ZDOTDIR/.zshenv. (If ZDOTDIR is unset, HOME is used instead). If the first character of argument zero passed to the shell is -, or if the -l flag is present, then the shell is assumed to be a login shell, and commands are read from /etc/zprofile and then $ZDOTDIR/.zprofile. Then, if the shell is interactive, commands are read from /etc/zshrc and then $ZDOTDIR/.zshrc. Finally, if the shell is a login shell, /etc/zlogin and $ZDOTDIR/.zlogin are read. | I love the SHLVL hack, but if you put it in place, then rc will now | process .rcrc differently across different versions of the shell, and | I'd prefer some backward compatability if at all possible. SHLVL leaves me cold. The issue is how to tell a shell to do some initialization---nesting level should be conceptually infinite, and shouldn't effect that.
>Take a look at what zsh does. There are lots of cases one might
>want to handle, once you start in with different config files:
Hey, my rc did away with the system-wide rcrc implied in Duff's
paper.
All I'm saying is that you don't necessarily want .rcrc to run via rsh --
there might be stuff in there that depends on an interactive shell. Hence
the suggestion that a different mechanism be used.
That being said, I like to use stricter rules for my personal .rcrc:
it is idempotent, so I can always issue ". .rcrc" and be sure there
won't be any nonsense in my environment.
Byron.
My thoughts on this subject. 1. First and foremost, my focus at the moment is on getting rc-1.7 out the door. Whatever we conclude on this issue, I'm not making any changes before then. (So far, nobody's reported any problems with rc-1.6c6; if you've found any, please tell me ASAP!) 2. I agree that there is a real problem here (although we've all managed to muddle along somehow till now). 3. Any solution must be simple. If you want zsh, you know where to find it :-). (The other heavyweight shells, such as bash and tcsh, have also gone down the "twisty little maze of startup files" route; rc will not. Promise.) 4. I'm not at all keen to introduce any more compile-time options. This implies that we must seek a solution which is acceptable to everybody (or almost everybody). 5. I'm keeping a note of the various ideas that have been suggested. When the discussion dries up (or descends into flamefest), I'll post a summary. Tim.
Okay, here's a suggestion. What if by default a non-interactive rc executes .rcrc, but it does so implicitly with the -n flag set. Then, we need a builtin to be able to turn off -n, so that the non- interactive portions of .rcrc might be interpreted. Finally, there also then needs to be a mechanism for avoiding the infinite recursion of .rcrc's. An example .rcrc: # # Non-interactive stuff goes here # exec +n # made-up builtin path=(/a/bin /b/bin /c/bin) # # Interactive stuff goes here # exec -n # made-up builtin stty dec It's convoluted because I want rc to preserve compatability with the old .rcrc semantics: i.e., I want an old .rcrc to work properly even via rsh. Maybe this is a holy grail not worth pursuing since who likes the old semantics of rsh anyway? Byron.
tjg@star.le.ac.uk writes: }4. I'm not at all keen to introduce any more compile-time options. } This implies that we must seek a solution which is acceptable to } everybody (or almost everybody). It seems to me the default is backwards. Due to rc being invoked from various place over which you may not have control (and hence can't add the -l flag), rc should by default read .rcrc (or something). It is easy to avoid reading it by adding a test to the first line, eg. (using the level count variable someone suggested): ~ $rclvl () && { rclvl=1 #rest of your usual .rcrc - put it in a file if you want and source it #like this . .rclogin } || { rclvl=`{expr $rclvl + 1} # other stuff you might want to do every time. } We don't need a maze of twisty dot files, just one which is always read. Since rc stuffs everything in environment variables things are inherited by sub-rc-shells anyway, including functions. Of course, the major problem is that this isn't backwards compatible. What it _does_ allow is a choice between whether you get the startup files or not, which the current default does not allow for. C (c)2002 Callum Gibson callum.gibson@db.com Global Markets IT, Deutsche Bank, Australia 61 2 9258 1620 ### The opinions in this message are mine and not Deutsche's ###
| It seems to me the default is backwards. Due to rc being invoked from | various place over which you may not have control (and hence can't add | the -l flag), rc should by default read .rcrc (or something). It is easy | to avoid reading it by adding a test to the first line, eg. (using the | level count variable someone suggested): Consulting .rcrc for every new shell requires reading and parsing all of it on every semi-interactive subshell. (The same is true for any other file rc would be looking at, of course.) I spawn a lot of copies of rc over the course of my day. I'm not really enthused about adding this overhead (and this dependancy on $home responding right now) to them. This is a long way to go just because rsh (and ssh) have problems that can easily be fixed via wrappers. - cks
On Thu, Feb 14, 2002 at 11:11:29PM -0500, Byron Rakitzis wrote:
>
> All I'm saying is that you don't necessarily want .rcrc to run via rsh --
> there might be stuff in there that depends on an interactive shell. Hence
> the suggestion that a different mechanism be used.
>
> That being said, I like to use stricter rules for my personal .rcrc:
> it is idempotent, so I can always issue ". .rcrc" and be sure there
> won't be any nonsense in my environment.
Add a flag (say -S) which when used as 'rc -S file' will act as if ". file"
had been the first command executed. I've been thinking of hacking this
into my copy of rc, just so that when starting xterms I can be lasy and
forgo typing '. .rc/interactive' into every new shell.
This could then be used with "ssh -t host 'rc -S startup_file'" from the
originating host if a specific environment set up is required. I quite
_like_ the fact that I can get an virgin environment when logging in
remotely.
In fact the above could be hidden by having a _local_ wrapper for ssh
which played the above games when logging into the remote system.
Alternately since ssh can pass environment strings across to the remote
process, simply set the environment you need for rc at your local end
and allow this to inititialise the remote rc.
DF
> Add a flag (say -S) which when used as 'rc -S file' will act as if ". file"
> had been the first command executed. I've been thinking of hacking this
> into my copy of rc, just so that when starting xterms I can be lasy and
> forgo typing '. .rc/interactive' into every new shell.
>
> This could then be used with "ssh -t host 'rc -S startup_file'" from the
> originating host if a specific environment set up is required. I quite
Even easier, just use ssh -t host 'rc -c ''. startup_file; . -i /dev/stdin'''.
> Add a flag (say -S) which when used as 'rc -S file' will act as if ". file" > had been the first command executed. I've been thinking of hacking this > into my copy of rc, just so that when starting xterms I can be lasy and > forgo typing '. .rc/interactive' into every new shell. > This could then be used with "ssh -t host 'rc -S startup_file'" from the > originating host if a specific environment set up is required. I quite > _like_ the fact that I can get an virgin environment when logging in > remotely. I am not sure I understand the ssh problem described here. My understanding was that this is a problem with NON-interactive shells. As long as you are willing to play games with wrappers and so on and so forth, why not simply do: rsh foo 'rc -c ''. .rcrc; '$^cmd'''' Incidentally, a good way of getting an interactive shell to do something just once, e.g., when starting a new xterm, is to set fn prompt as follows: fn prompt { fn prompt # remove myself from the environment one-time init stuff } This works differently from .rcrc because it could be, for example, that your .xinitrc runs rc as a login shell, but only when a subshell finally prints a prompt do you do things like set a terminal type, etc. Byron.
On Fri, Feb 15, 2002 at 09:04:36AM -0500, Tim Goodwin wrote: > > 3. Any solution must be simple. If you want zsh, you know where to > find it :-). (The other heavyweight shells, such as bash and tcsh, > have also gone down the "twisty little maze of startup files" > route; rc will not. Promise.) Thanks God :-) -- For easier reading please set the Courier font. Messages larger than 30 KB may not receive immediate attention. Freedom for Business: http://swpat.ffii.org
On Tue, Feb 26, 2002 at 09:16:03PM -0500, Chris Siebenmann wrote: > > Consulting .rcrc for every new shell requires reading and parsing all > of it on every semi-interactive subshell. (The same is true for any > other file rc would be looking at, of course.) > > I spawn a lot of copies of rc over the course of my day. I'm not > really enthused about adding this overhead (and this dependancy on > $home responding right now) to them. I use rc heavily for Web scripting, so it would be even more of a problem. Please do not go that way. carlo -- For easier reading please set the Courier font. Messages larger than 30 KB may not receive immediate attention. Freedom for Business: http://swpat.ffii.org
> > have also gone down the "twisty little maze of startup files"
> > route; rc will not. Promise.)
>
> Thanks God :-)
I'm not much of a me too guy but
"ME TOO"
by all means offer extra startup stuff as some sort of option but rapid startup time is one of the reasons (among many) I use rc
ta