rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* Re: non login "rc" needs customized environment
@ 2002-02-14 13:35 Smarasderagd
  2002-02-15  0:37 ` Greg A. Woods
  0 siblings, 1 reply; 21+ messages in thread
From: Smarasderagd @ 2002-02-14 13:35 UTC (permalink / raw)
  To: pk, rc

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



^ permalink raw reply	[flat|nested] 21+ messages in thread
* Re: non login "rc" needs customized environment
@ 2002-02-27  6:29 Byron Rakitzis
  0 siblings, 0 replies; 21+ messages in thread
From: Byron Rakitzis @ 2002-02-27  6:29 UTC (permalink / raw)
  To: byron, dfawcus; +Cc: pk, rc, schwartz

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


^ permalink raw reply	[flat|nested] 21+ messages in thread
* Re: non login "rc" needs customized environment
@ 2002-02-27  6:26 Russ Cox
  0 siblings, 0 replies; 21+ messages in thread
From: Russ Cox @ 2002-02-27  6:26 UTC (permalink / raw)
  To: rc

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



^ permalink raw reply	[flat|nested] 21+ messages in thread
* Re: non login "rc" needs customized environment
@ 2002-02-27  0:52 Byron Rakitzis
  0 siblings, 0 replies; 21+ messages in thread
From: Byron Rakitzis @ 2002-02-27  0:52 UTC (permalink / raw)
  To: rc, tjg

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.


^ permalink raw reply	[flat|nested] 21+ messages in thread
* Re: non login "rc" needs customized environment
@ 2002-02-15  4:11 Byron Rakitzis
  2002-02-15 14:04 ` Tim Goodwin
  2002-02-27  6:13 ` Derek Fawcus
  0 siblings, 2 replies; 21+ messages in thread
From: Byron Rakitzis @ 2002-02-15  4:11 UTC (permalink / raw)
  To: byron, schwartz; +Cc: pk, rc

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


^ permalink raw reply	[flat|nested] 21+ messages in thread
* Re: non login "rc" needs customized environment
@ 2002-02-14 17:44 Byron Rakitzis
  2002-02-15  0:18 ` Dave Mason
  2002-02-15  3:21 ` Scott Schwartz
  0 siblings, 2 replies; 21+ messages in thread
From: Byron Rakitzis @ 2002-02-14 17:44 UTC (permalink / raw)
  To: pk, rc

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.


^ permalink raw reply	[flat|nested] 21+ messages in thread
[parent not found: <chet@nike.ins.cwru.edu>]
* non login "rc" needs customized environment
@ 2002-02-13 19:21 Peter Koch
  0 siblings, 0 replies; 21+ messages in thread
From: Peter Koch @ 2002-02-13 19:21 UTC (permalink / raw)
  To: rc


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


^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2002-02-28  6:11 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-14 13:35 non login "rc" needs customized environment Smarasderagd
2002-02-15  0:37 ` Greg A. Woods
  -- strict thread matches above, loose matches on Subject: below --
2002-02-27  6:29 Byron Rakitzis
2002-02-27  6:26 Russ Cox
2002-02-27  0:52 Byron Rakitzis
2002-02-15  4:11 Byron Rakitzis
2002-02-15 14:04 ` Tim Goodwin
2002-02-27  1:46   ` callum.gibson
2002-02-27  2:16     ` Chris Siebenmann
2002-02-27 13:32       ` Carlo Strozzi
2002-02-27 13:29   ` Carlo Strozzi
2002-02-27 22:24     ` Matt H
2002-02-27  6:13 ` Derek Fawcus
2002-02-14 17:44 Byron Rakitzis
2002-02-15  0:18 ` Dave Mason
2002-02-15  3:21 ` Scott Schwartz
     [not found] <chet@nike.ins.cwru.edu>
2002-02-13 20:36 ` Chet Ramey
2002-02-14  2:16   ` Scott Schwartz
2002-02-14 23:35     ` Markus Friedl
2002-02-15  3:05       ` Scott Schwartz
2002-02-13 19:21 Peter Koch

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).