rc-list - mailing list for the rc(1) shell
 help / Atom feed
* 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

* Re: non login "rc" needs customized environment
@ 2002-02-13 20:36 ` Chet Ramey
  2002-02-14  2:16   ` Scott Schwartz
  0 siblings, 1 reply; 21+ messages in thread
From: Chet Ramey @ 2002-02-13 20:36 UTC (permalink / raw)
  To: pk; +Cc: rc

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


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

* Re: non login "rc" needs customized environment 
  2002-02-13 20:36 ` Chet Ramey
@ 2002-02-14  2:16   ` Scott Schwartz
  2002-02-14 23:35     ` Markus Friedl
  0 siblings, 1 reply; 21+ messages in thread
From: Scott Schwartz @ 2002-02-14  2:16 UTC (permalink / raw)
  To: chet; +Cc: pk, rc

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



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

* Re: non login "rc" needs customized environment
@ 2002-02-14 13:35 smarry
  2002-02-15  0:37 ` woods
  0 siblings, 1 reply; 21+ messages in thread
From: smarry @ 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-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

* Re: non login "rc" needs customized environment
  2002-02-14  2:16   ` Scott Schwartz
@ 2002-02-14 23:35     ` Markus Friedl
  2002-02-15  3:05       ` Scott Schwartz
  0 siblings, 1 reply; 21+ messages in thread
From: Markus Friedl @ 2002-02-14 23:35 UTC (permalink / raw)
  To: Scott Schwartz; +Cc: chet, pk, rc

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.


^ 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
  1 sibling, 0 replies; 21+ messages in thread
From: Dave Mason @ 2002-02-15  0:18 UTC (permalink / raw)
  To: rc

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


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

* Re: non login "rc" needs customized environment
  2002-02-14 13:35 smarry
@ 2002-02-15  0:37 ` woods
  0 siblings, 0 replies; 21+ messages in thread
From: woods @ 2002-02-15  0:37 UTC (permalink / raw)
  To: rc

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


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

* Re: non login "rc" needs customized environment 
  2002-02-14 23:35     ` Markus Friedl
@ 2002-02-15  3:05       ` Scott Schwartz
  0 siblings, 0 replies; 21+ messages in thread
From: Scott Schwartz @ 2002-02-15  3:05 UTC (permalink / raw)
  To: Markus Friedl; +Cc: rc

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.  



^ 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
  1 sibling, 0 replies; 21+ messages in thread
From: Scott Schwartz @ 2002-02-15  3:21 UTC (permalink / raw)
  To: Byron Rakitzis; +Cc: 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.

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.



^ 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-15  4:11 Byron Rakitzis
@ 2002-02-15 14:04 ` Tim Goodwin
  2002-02-27  1:46   ` callum.gibson
  2002-02-27 13:29   ` Carlo Strozzi
  2002-02-27  6:13 ` Derek Fawcus
  1 sibling, 2 replies; 21+ messages in thread
From: Tim Goodwin @ 2002-02-15 14:04 UTC (permalink / raw)
  To: rc

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.


^ 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 14:04 ` Tim Goodwin
@ 2002-02-27  1:46   ` callum.gibson
  2002-02-27  2:16     ` Chris Siebenmann
  2002-02-27 13:29   ` Carlo Strozzi
  1 sibling, 1 reply; 21+ messages in thread
From: callum.gibson @ 2002-02-27  1:46 UTC (permalink / raw)
  To: rc

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


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

* Re: non login "rc" needs customized environment 
  2002-02-27  1:46   ` callum.gibson
@ 2002-02-27  2:16     ` Chris Siebenmann
  2002-02-27 13:32       ` Carlo Strozzi
  0 siblings, 1 reply; 21+ messages in thread
From: Chris Siebenmann @ 2002-02-27  2:16 UTC (permalink / raw)
  To: rc

| 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


^ 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
  1 sibling, 0 replies; 21+ messages in thread
From: Derek Fawcus @ 2002-02-27  6:13 UTC (permalink / raw)
  To: Byron Rakitzis; +Cc: schwartz, pk, rc

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


^ 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  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-15 14:04 ` Tim Goodwin
  2002-02-27  1:46   ` callum.gibson
@ 2002-02-27 13:29   ` Carlo Strozzi
  2002-02-27 22:24     ` Matt H
  1 sibling, 1 reply; 21+ messages in thread
From: Carlo Strozzi @ 2002-02-27 13:29 UTC (permalink / raw)
  To: rc

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


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

* Re: non login "rc" needs customized environment
  2002-02-27  2:16     ` Chris Siebenmann
@ 2002-02-27 13:32       ` Carlo Strozzi
  0 siblings, 0 replies; 21+ messages in thread
From: Carlo Strozzi @ 2002-02-27 13:32 UTC (permalink / raw)
  To: rc Shell

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


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

* Re: non login "rc" needs customized environment
  2002-02-27 13:29   ` Carlo Strozzi
@ 2002-02-27 22:24     ` Matt H
  0 siblings, 0 replies; 21+ messages in thread
From: Matt H @ 2002-02-27 22:24 UTC (permalink / raw)
  To: rc


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


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

end of thread, back to index

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-13 19:21 non login "rc" needs customized environment Peter Koch
     [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-14 13:35 smarry
2002-02-15  0:37 ` woods
     [not found] <byron@rakitzis.com>
2002-02-14 17:44 ` Byron Rakitzis
2002-02-15  0:18   ` Dave Mason
2002-02-15  3:21   ` Scott Schwartz
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-27  0:52 Byron Rakitzis
2002-02-27  6:26 Russ Cox
2002-02-27  6:29 Byron Rakitzis

rc-list - mailing list for the rc(1) shell

Archives are clonable: git clone --mirror http://inbox.vuxu.org/rc-list

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.rc-list


AGPL code for this site: git clone https://public-inbox.org/ public-inbox