rc-list - mailing list for the rc(1) shell
 help / Atom feed
* Re: $pid 
       [not found] ` <cks@hawkwind.utcs.toronto.edu>
@ 1992-06-04 10:05   ` malte
  1992-11-04 12:45   ` set subtract malte
                     ` (3 subsequent siblings)
  4 siblings, 0 replies; 43+ messages in thread
From: malte @ 1992-06-04 10:05 UTC (permalink / raw)
  To: rc

I don't think echo `{ echo $pid } should be different from echo $pid because
I don't really want know that backquote substitution requieres a fork(2).
Of course, shell functions and explicit subshell commands "@{ .. }" should.

Malte.



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

* Re: set subtract 
       [not found] ` <cks@hawkwind.utcs.toronto.edu>
  1992-06-04 10:05   ` $pid malte
@ 1992-11-04 12:45   ` malte
  1992-11-06 12:03   ` rc and signal handlers malte
                     ` (2 subsequent siblings)
  4 siblings, 0 replies; 43+ messages in thread
From: malte @ 1992-11-04 12:45 UTC (permalink / raw)
  To: rc

	
	 The problem with a set-subtract function is that it will loose quoting
	information if it's used as 'foo `{set-sub ....}', and you thus need to
	have it passed variable names to work on. But then you can't just use
	this on a command line; you have to build lists beforehand. About
	half the time I'd like to use this is on command lines, so I keep
	wishing for a better solution.
	
		- cks

Applause, applause!

I'd vote for making such a function built into rc to avoid meta character
trouble, the way the ~ operator does it.
A related builtin I always wanted to have:

	idx = `{ index list_of_patterns list_to_search_in }

This should return a list of indices of the search patterns in the second list.

	; echo `{ index a ( a b c a ) }
	1 4
	;

Malte



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

* Re: rc and signal handlers 
       [not found] ` <cks@hawkwind.utcs.toronto.edu>
  1992-06-04 10:05   ` $pid malte
  1992-11-04 12:45   ` set subtract malte
@ 1992-11-06 12:03   ` malte
  1997-09-19 17:21   ` are there any patches which add ~ expansion to rc Jeremy Fitzhardinge
  2001-10-24  3:25   ` Beta release rc-1.6b3 available Chris Siebenmann
  4 siblings, 0 replies; 43+ messages in thread
From: malte @ 1992-11-06 12:03 UTC (permalink / raw)
  To: rc

	
	| Also, the man-page is not too clear about signals:
	|  "Only signals that are being ignored are passed on to programs run by rc"
	| The should read "signals that are being caught", I guess.
	
	 The manpage is correct as written; caught signals are not passed on to
	children, and revert to default behavior. Only ignored signals are passed
	on to children.
	
	 If one thinks about how catching signals works, it becomes obvious that
	this has to be that way.
	
		- cks

This is perfectly true! But also ugly ! This way, one has to redefine signal
handlers for each backquote substitution. On BSD and System V children
inherit signal handlers when forking and one has to change them explicitly.
Could someone explain to me why rc does it automatically ? I'd rather prefer
a simple way to reset signal handlers, something like

	fn sigreset {
		for( sig in `{ whatis -s | cut -f2 '-d ' } )
			eval fn $sig
	}

About "return"ing from a signal handler: One really doesn't want to do that.
I just mentioned it to make it clear to beginners. What bothers me most is
that rc doesn't complain about a return when defining the function and that
everything is fine when invoking the function interactively. But, when the
signal is caught, you'll get "return outside of function".

Malte



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

* are there any patches which add ~ expansion to rc
@ 1997-09-17 15:56 Joseph Skinner
  1997-09-17 21:56 ` Scott Schwartz
  1997-09-17 22:08 ` Mark K. Gardner
  0 siblings, 2 replies; 43+ messages in thread
From: Joseph Skinner @ 1997-09-17 15:56 UTC (permalink / raw)
  To: rc

Hi

the title just about says it all.

This is one of the few things that I miss from bash and have noted that
this has been added to es.

What is the general view of this being part of rc.

Also where can I get the latest version of rc and it still being 
actively developed.

Joe.

-- 
=======================================================================
in real life: Joseph Skinner         |There's no such thing as a wizard
email: joe@earthlight.co.nz          |who minds his own business
       jskinner@es.co.nz             | - Berengis the Black
http:  www.earthlight.co.nz/users/joe|   Court Mage to the Earls Caeline
========================================================================


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

* Re: are there any patches which add ~ expansion to rc 
  1997-09-17 15:56 are there any patches which add ~ expansion to rc Joseph Skinner
@ 1997-09-17 21:56 ` Scott Schwartz
  1997-09-17 22:08 ` Mark K. Gardner
  1 sibling, 0 replies; 43+ messages in thread
From: Scott Schwartz @ 1997-09-17 21:56 UTC (permalink / raw)
  To: Joseph Skinner; +Cc: rc

Joseph Skinner <joe@earthlight.co.nz> writes:
| What is the general view of this being part of rc.

Wrong level of abstraction.  Your os should provide a (virtual)
filesystem mounted on "/u" so you can say /u/username in every
context.  Sun's automounter can almost do this right; amd can
probably do better.



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

* Re: are there any patches which add ~ expansion to rc
  1997-09-17 15:56 are there any patches which add ~ expansion to rc Joseph Skinner
  1997-09-17 21:56 ` Scott Schwartz
@ 1997-09-17 22:08 ` Mark K. Gardner
  1 sibling, 0 replies; 43+ messages in thread
From: Mark K. Gardner @ 1997-09-17 22:08 UTC (permalink / raw)
  To: joe; +Cc: rc

Joe,

A while ago I hacked rc to add ~ expansion. (It was a real kludge.)
However, after thinking about it more I decided that expansion really
belongs in readline/editline. So I modified readline v2.1 to support
it. I then had to make a relatively minor change to rc to initialize
readline properly and to perform expansion.

[Caveat: I decided not to use ~ because of its obvious conflict with
pattern matching in rc. Instead I used % which seems to be free. It
would have been better if the final expansion was done in readline,
but it appeared that readline would be too easy to break.]

The modification works fine. I have to remember to use ~ instead of %
in emacs though! The patch is too long to post and is of (perhaps)
limited interest so I will email it to you directly.

Mark

-- 
Mark K. Gardner (mkgardne@cs.uiuc.edu)
University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
-- 


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

* Re: are there any patches which add ~ expansion to rc
       [not found] ` <cks@hawkwind.utcs.toronto.edu>
                     ` (2 preceding siblings ...)
  1992-11-06 12:03   ` rc and signal handlers malte
@ 1997-09-19 17:21   ` Jeremy Fitzhardinge
  2001-10-24  3:25   ` Beta release rc-1.6b3 available Chris Siebenmann
  4 siblings, 0 replies; 43+ messages in thread
From: Jeremy Fitzhardinge @ 1997-09-19 17:21 UTC (permalink / raw)
  To: Chris Siebenmann; +Cc: rc

On Sep 18,  7:26pm, Chris Siebenmann wrote:
>  Our local solution is a /u directory (automatically) populated with
> symlinks that point to the appropriate places. We've been running it
> for years without problems; I can mail people copies of either a sh
> or a perl version[*] of the script that maintains /u if desired.

While I agree that /u is an elegant approach to dealing with the ~user
problem, the most common use of ~ is when referring to one's own
home directory, which /u doesn't help with.  I once implemented /u
as a user-space filesystem under Linux which generated its contents
on demand from /etc/passwd. It also had a /u/me which always referred
to the caller's home direcory, which is hard to do with a conventional
symlink /u.

The $H solution is OK for rc, but it has the same problems as ~, in that
not everything will understand it.

	J


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

* building rc on QNX4
@ 2000-04-26 15:02 Sam Roberts
  0 siblings, 0 replies; 43+ messages in thread
From: Sam Roberts @ 2000-04-26 15:02 UTC (permalink / raw)
  To: rc


rc looks really good to me, so I built it over the weekend, and
I'm starting to use it. I think I've seen a few problems, but I'll
play some more and see what I can turn up, in the meantime, here's
what I had to do to get it to build:

- it has setpgid(), but not setpgrp();
- it also has a utoa in <stdlib.h>, but not with the same args;
- and it's va_list isn't an lvalue.

So, are these patches accpetable? QNX's default bastardized ksh
is ok for interactive use, but not great for programming, and
I don't think I have to bash bash on the rc mailing list... 
(sorry, I couldn't resist ;-)

Also, there's a few things I've always figured should be easy,
like piping fds other than stdout->stdin, that are under rc.

Oh, and QNX also lacks a groff tex formatting system... do you
think you could distribute a pre-processed rc.1 as rc.man, so
it could be read by less? And how about postscript as well
(groff -man rc.1>rc.ps)?

I found a Linux box to format rc.1 on, but...

Anyhow, I'm sure I'll have more questions as I play.

So far so good, and thanks a bunch!
Sam


diff -ur rc-1.6b2-orig/config.h.in rc-1.6b2/config.h.in
--- rc-1.6b2-orig/config.h.in	Wed Oct 13 07:55:03 1999
+++ rc-1.6b2/config.h.in	Tue Apr 25 09:31:27 2000
@@ -107,6 +107,9 @@
 /* Define if you have the mkfifo function.  */
 #undef HAVE_MKFIFO
 
+/* Define if you have the setpgid function.  */
+#undef HAVE_SETPGID
+
 /* Define if you have the setpgrp function.  */
 #undef HAVE_SETPGRP
 
diff -ur rc-1.6b2-orig/configure.in rc-1.6b2/configure.in
--- rc-1.6b2-orig/configure.in	Fri Dec 10 06:25:53 1999
+++ rc-1.6b2/configure.in	Tue Apr 25 09:31:20 2000
@@ -38,7 +38,7 @@
 AC_TYPE_UID_T
 AC_CHECK_TYPE(ssize_t, long)
 
-AC_CHECK_FUNCS(getgroups setpgrp setrlimit strerror)
+AC_CHECK_FUNCS(getgroups setpgrp setpgid setrlimit strerror)
 RC_FUNC_GETGROUPS
 
 RC_FUNC_SIGSETJMP
diff -ur rc-1.6b2-orig/print.c rc-1.6b2/print.c
--- rc-1.6b2-orig/print.c	Thu Aug 19 05:22:03 1999
+++ rc-1.6b2/print.c	Tue Apr 25 09:36:17 2000
@@ -70,9 +70,9 @@
 	return FALSE;
 }
 
-static char *utoa(unsigned long u, char *t, unsigned int radix, const char *digit) {
+static char *utostr(unsigned long u, char *t, unsigned int radix, const char *digit) {
 	if (u >= radix) {
-		t = utoa(u / radix, t, radix, digit);
+		t = utostr(u / radix, t, radix, digit);
 		u %= radix;
 	}
 	*t++ = digit[u];
@@ -120,7 +120,7 @@
 		while (*altform != '\0')
 			prefix[pre++] = *altform++;
 
-	len = utoa(u, number, radix, table[upper]) - number;
+	len = utostr(u, number, radix, table[upper]) - number;
 	if ((flags & FMT_f2set) && (size_t) format->f2 > len)
 		zeroes = format->f2 - len;
 	else
diff -ur rc-1.6b2-orig/proto.h rc-1.6b2/proto.h
--- rc-1.6b2-orig/proto.h	Wed Oct 13 10:57:22 1999
+++ rc-1.6b2/proto.h	Tue Apr 25 09:37:34 2000
@@ -27,7 +27,11 @@
 objects of type va_list.  Of course, most places don't have this yet,
 but where it does exist we need to use it. */
 #ifndef __va_copy
+#ifndef __QNX__
 #define __va_copy(x,y) (x)=(y)
+#else
+#define __va_copy(x,y) x[0]=y[0]
+#endif /* __QNX__ */
 #endif
 
 #if STDC_HEADERS
@@ -84,9 +88,11 @@
 
 #else /* HAVE_SETPGRP */
 
+#ifndef HAVE_SETPGID
 /* Nothing doing. */
 #define setpgid()
 #define tcsetpgrp()
+#endif /* HAVE_SETPGID */
 
 #endif /*HAVE_SETPGRP */
 

-- 
Sam Roberts, sroberts at uniserve dot com, www.emyr.net/Sam


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

* Re: building rc on QNX4 
  2000-04-27 16:56 Scott Schwartz
@ 2000-04-27 20:41 ` Sam Roberts
  2000-04-28  7:28   ` vrl (was: Re: building rc on QNX4) Gert-Jan Vons
  0 siblings, 1 reply; 43+ messages in thread
From: Sam Roberts @ 2000-04-27 20:41 UTC (permalink / raw)
  To: rc

Said Scott Schwartz <schwartz@bio.cse.psu.edu>:
> Said Sam <sroberts@uniserve.com>:
> | Oh, and QNX also lacks a groff tex formatting system... do you
> | think you could distribute a pre-processed rc.1 as rc.man, so
> | it could be read by less? And how about postscript as well
> | (groff -man rc.1>rc.ps)?
> 
> Years ago, Henry Spencer wrote a man-page-only-roff in awk for cnews,
> for just such a contingency.

That he's such a gifted awk hacker is pretty cool, but
I think it's easier to add a rule to the rc build to pack
the .man in with the distribution than to find that code!

Vrl, for example, has a vrl.man that comes with it.

--

Speaking of which, is this an appropriate place to talk about
vrl? I posted some diffs to the author, no response yet (only
been a day or so -- I'm just mentioning, not griping).

I had some trubles with it's termcap usage. It seems to
think that @7 is the keypad END key/capability. This wasn't
defined on my system, and while I found it defined in a bunch
of Linux termcap entries (mostly in what looked like old PC
consoles), it wasn't in the ansi entries.

Poking around it seemed the right thing was to use kh for HOME
and kH for END (vrl was using kh for HOME and @7 for END).

Any comments?

--

Also, I can't call 'login' from an rc shell, strangely, it
complains about not being session leader. I'm quite baffled.

I have to look into exactly what it takes to be a session
leader, calling setsid() at the beginning of main didn't
cut it, and the ps output for a ksh and rc don't seem to
show a difference in terms of how the sid, pgrp, and controlling
terminal are set up.

--

Also, I just noticed ^L doesn't clear the screen. I'll look
into that sometime.

--

Ciao!
Sam




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

* Re: vrl (was: Re: building rc on QNX4)
  2000-04-27 20:41 ` Sam Roberts
@ 2000-04-28  7:28   ` Gert-Jan Vons
  2000-04-28 18:38     ` Sam Roberts
  2000-04-28 19:03     ` rc not session leader? Sam Roberts
  0 siblings, 2 replies; 43+ messages in thread
From: Gert-Jan Vons @ 2000-04-28  7:28 UTC (permalink / raw)
  To: rc, Sam Roberts

Sam Roberts wrote:

>Speaking of which, is this an appropriate place to talk about
>vrl? I posted some diffs to the author, no response yet (only
>been a day or so -- I'm just mentioning, not griping).

That would be me, since I'm the author :-) I assume you sent it to my 
(old) usa.net address, I'll check my inbox there.

>I had some trubles with it's termcap usage. It seems to
>think that @7 is the keypad END key/capability. This wasn't
>defined on my system, and while I found it defined in a bunch
>of Linux termcap entries (mostly in what looked like old PC
>consoles), it wasn't in the ansi entries.
>
>Poking around it seemed the right thing was to use kh for HOME
>and kH for END (vrl was using kh for HOME and @7 for END).

kH is the "last-line" key according to FreeBSD's termcap(5). What is the 
OS you are using, what is the tty type, and on what hardware? (please 
mail me the termcap entry for your tty)

"last-line" for going to the end of a line seems a bit strange, but if 
that is what your tty sends when you hit the End key... I could fall back 
to kH if there is no @7 defined.

>--
>Also, I can't call 'login' from an rc shell, strangely, it
>complains about not being session leader. I'm quite baffled.

What kind of OS are you using? I can use "login" under solaris and 
freebsd without any problems.

>Also, I just noticed ^L doesn't clear the screen. I'll look
>into that sometime.

Nope. When you use vrl, ^L redisplays the line, useful in case it got 
garbled by the output of some background process. Note also that vrl is 
about lines, it doesn't (want/need to) know about the screen. The unix 
'clear' command handles that very well.



         Gert-Jan
-----
"If you are good, you will be assigned all the work. If you
  are really good, you will get out of it."
     - Dilbert



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

* Re: vrl (was: Re: building rc on QNX4)
  2000-04-28  7:28   ` vrl (was: Re: building rc on QNX4) Gert-Jan Vons
@ 2000-04-28 18:38     ` Sam Roberts
  2000-05-02  8:16       ` Gert-Jan Vons
  2000-04-28 19:03     ` rc not session leader? Sam Roberts
  1 sibling, 1 reply; 43+ messages in thread
From: Sam Roberts @ 2000-04-28 18:38 UTC (permalink / raw)
  To: rc, Gert-Jan Vons; +Cc: sam

> 
> >Speaking of which, is this an appropriate place to talk about
> >vrl? I posted some diffs to the author, no response yet (only
> >been a day or so -- I'm just mentioning, not griping).
> 
> That would be me, since I'm the author :-) I assume you sent it to my 
> (old) usa.net address, I'll check my inbox there.

Yep, that's what's in 1.3's README! ;-)
 
> >I had some trubles with it's termcap usage. It seems to
> >think that @7 is the keypad END key/capability. This wasn't
> >defined on my system, and while I found it defined in a bunch
> >of Linux termcap entries (mostly in what looked like old PC
> >consoles), it wasn't in the ansi entries.
> >
> >Poking around it seemed the right thing was to use kh for HOME
> >and kH for END (vrl was using kh for HOME and @7 for END).
> 
> kH is the "last-line" key according to FreeBSD's termcap(5). What is the 
> OS you are using, what is the tty type, and on what hardware? (please 
> mail me the termcap entry for your tty)

QNX4, using their pterm (the Photon Terminal, Photon being the GUI
system), with ANSI emulation. The esc sequence for END (by observation)
is \E[Y, but is not present in their /etc/termcap (I guess most programs
are useing terminfo now). Below is the termcap:

qansi|qansi-m|qansi-8859m|QNX ANSI:am:G0:co#80:it#8:li#25:ti=\E[?7h:\
    :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:LE=\E[%dD:\
    :RA=\E[?7l:RI=\E[%dC:SA=\E[?7h:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:\
    :ae=^O:al=\E[L:as=^N:bt=\E[Z:cb=\E[K\E[X:cd=\E[J:ce=\E[K:ch=\E[%i%dG:\
    :cl=\E[2J\E[H:cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:ct=\E[2g:dc=\E[P:dl=\E[M:do=\E[B:\
    :ec=\E[%dX:ho=\E[H:ic=\E[@:is=\E[?7h\E[0;10;39;49m:\
    :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\EOT:k6=\EOU:k7=\EOV:k8=\EOW:k9=\EOX:\
    :k;=\EOY:kB=\E[Z:kC=\ENa:kD=\E[P:kF=\E[a:kI=\E[@:kN=\E[U:kP=\E[V:kR=\E[b:kT=\ENb:\
    :ka=\ENd:kb=\177:kd=\E[B:kh=\E[H:kl=\E[D:kr=\E[C:ku=\E[A:\
    :le=\E[D:ll=\E[99H:mb=\E[5m:md=\E[1m:me=\E[m^O:mh=\E[2m:mk=\E[9m:mr=\E[7m:\
    :nd=\E[C:nw=\EE:op=\E[39;49m:rp=%.\E[%p2%{1}%-%db:\
    :se=\E[27m:sf=\E[S:so=\E[7m:sr=\E[T:st=\EH:ue=\E[24m:up=\E[A:us=\E[4m:\
    :ac=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~:\
    :vb=\E[?5h\E[?5l:ve=\E[?25h\E[?12l:vi=\E[?25l:\
    :ws=\E[5m:we=\E[m:bo=\E[1m:be=\E[m:

So, I can just add ":@7=\E[Y:", but I looked at /usr/lib/terminfo/terminfo.src,
and checked out the other emulation pterm can do, the native QNX terminal
type:

term   terminfo              termcap
----   --------              -------
qnx    kend=\377\250         kH=\0377\0250
ansi   kend=\E[Y             Nothing at all...

Thus I made the obvious assumption that vrl should use 'kH', and I
should add 'kH' to the termcap entry for ansi. Then rc/vrl would
work fine with both emulations.

It doesn't surprise me that this is wrong, QNX is relatively new,
and some of their support for legacy Unix stuff is shaky.

So, what's the "right" way? A note in the README for QNX4 users saying
to add :@7\E[Y: to "qansi" and :@7=\0377\0250: to "qnx" in their
termcaps so that all works well?

> "last-line" for going to the end of a line seems a bit strange, but if 
> that is what your tty sends when you hit the End key... I could fall back 
> to kH if there is no @7 defined.
> 

> >Also, I just noticed ^L doesn't clear the screen. I'll look
> >into that sometime.
> 
> Nope. When you use vrl, ^L redisplays the line, useful in case it got 
> garbled by the output of some background process. Note also that vrl is 
> about lines, it doesn't (want/need to) know about the screen. The unix 
> 'clear' command handles that very well.

And fn clear { /bin/echo \f } is working well for me, thanks for the clarification.

Sam




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

* Re: rc not session leader?
  2000-04-28  7:28   ` vrl (was: Re: building rc on QNX4) Gert-Jan Vons
  2000-04-28 18:38     ` Sam Roberts
@ 2000-04-28 19:03     ` Sam Roberts
  1 sibling, 0 replies; 43+ messages in thread
From: Sam Roberts @ 2000-04-28 19:03 UTC (permalink / raw)
  To: rc

> >Also, I can't call 'login' from an rc shell, strangely, it
> >complains about not being session leader. I'm quite baffled.
> 
> What kind of OS are you using? I can use "login" under solaris and 
> freebsd without any problems.

Russ Cox also tells me that login works fine under his system. I
kind of expected that rc was working fine everywhere else.

.............

And in the process of gathering the ps outputs to post here, I
just figured it out. Duh.

login has to be *execed*, not forked/and execed. So login is
a builtin shell alias for "exec login" in QNX's korn shell, so
login gets execed by the shell, the session leader and is happy.
I was trying to run login, so login was being execed by a forked
child of rc, NOT the session leader, and it was failing.

fn login { exec builtin login $* } seems appropriate here...

Thanks!
Sam




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

* Re: vrl (was: Re: building rc on QNX4)
  2000-04-28 18:38     ` Sam Roberts
@ 2000-05-02  8:16       ` Gert-Jan Vons
  0 siblings, 0 replies; 43+ messages in thread
From: Gert-Jan Vons @ 2000-05-02  8:16 UTC (permalink / raw)
  To: Sam Roberts, rc

Sam Roberts wrote:

>Yep, that's what's in 1.3's README! ;-)

FYI, the latest version of vrl (1.3.2, which includes 2 bug fixes) can be 
found at http://vons.free.fr/tools/index.html

>QNX4, using their pterm (the Photon Terminal, Photon being the GUI
>system), with ANSI emulation. The esc sequence for END (by observation)
>is \E[Y, but is not present in their /etc/termcap (I guess most programs
>are using terminfo now). Below is the termcap:
>....
>So, what's the "right" way? A note in the README for QNX4 users saying
>to add :@7=\E[Y: to "qansi" and :@7=\0377\0250: to "qnx" in their
>termcaps so that all works well?

That solution fixes the problem not only for "vrl" but for other 
termcap-aware programs as well.

I registered for a free copy of QNX, so I should be able to have a look 
at this myself somewhere during the summer.



         Gert-Jan
-----
How come wrong numbers are never busy?



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

* Re: building rc on QNX4
  2000-04-27 17:39 building rc on QNX4 Carlo Strozzi
@ 2000-05-02 14:41 ` Tim Goodwin
  0 siblings, 0 replies; 43+ messages in thread
From: Tim Goodwin @ 2000-05-02 14:41 UTC (permalink / raw)
  To: rc

> Also, I think that the name 'rc' is sometimes a too short one. On AIX,
> for instance, it conflicts with the system startup script /etc/rc.

Why is this any more a "conflict" than that between /usr/bin/passwd and
/etc/passwd?  OK, so /etc/rc is executable, which /etc/passwd isn't, but
surely you don't ever want to run /etc/rc by hand?  And even if you do,
who puts /etc in their path?  (I don't use AIX, by the way.)

> I use Linux, so that's not a problem for me, nevertheless I would
> really like that the default 'make install' stuff set up a symlink
> to rc with a longer and more meaningful name, like 'rcsh'.

Sounds a bit close to `tcsh' to me :-).  But if that's what you want,
just say

    sh configure '--program-suffix=sh'

You can also use `--program-prefix' to tack things onto the beginning of
the name, or `--program-transform-name' to do arbitrarily weird things
to it.

Tim.


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

* Re: building rc on QNX4
  2000-05-04 15:18 Carlo Strozzi
@ 2000-05-08  8:29 ` Tim Goodwin
       [not found]   ` <tjg@star.le.ac.uk>
  2000-05-08 13:28   ` Carlo Strozzi
  0 siblings, 2 replies; 43+ messages in thread
From: Tim Goodwin @ 2000-05-08  8:29 UTC (permalink / raw)
  To: rc

> A more important issue IMHO is whether Rc should provide a built-in
> read function, similar to the one offered by most Bourne shells;

There is no *need* to make `read' a builtin: see the EXAMPLES file in
the distribution for an alternative.  One of rc's design goals is to
avoid unnecessary builtins.  So, no, I don't think this is likely to
happen.

(I accept that there is some work to be done, first in terms of
documentation: the EXAMPLES file is not as visible as it should be.
Also, I have some vague ideas for the future about a package of small
utilities to work with rc (and other shells); one of these would be
something like `line'---unfortunately not available everywhere---and
make a building block for an efficient `read' function.)

>                                                                  another
> one is whether it will ever make it possible not to export everything to
> the environment by default.

I brought this up a few months ago, and the consensus seemed to be that
the current scheme works well enough in practice.  Have you encountered
a problem?

Tim.


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

* Re: building rc on QNX4 
       [not found]   ` <tjg@star.le.ac.uk>
@ 2000-05-08 11:50     ` David Luyer
  0 siblings, 0 replies; 43+ messages in thread
From: David Luyer @ 2000-05-08 11:50 UTC (permalink / raw)
  To: Tim Goodwin; +Cc: rc


Tim Goodwin wrote:
> >                                                                  another
> > one is whether it will ever make it possible not to export everything to
> > the environment by default.
> 
> I brought this up a few months ago, and the consensus seemed to be that
> the current scheme works well enough in practice.  Have you encountered
> a problem?

I encountered a problem with this years ago but just started using
"su -" when I was trying to get programs to run that it broke.

Basically some OS's (Digital Unix for one I think) have C libraries which
choke horribly if the size of the command line + environment array is greater 
than a certain value, and if you have a number of complex functions in your 
shell this value (64k?) can be a pain.

Although it is really useful to have the shell functions inherited by a shell 
which was spawned from some unrelated program running under the initial shell,
maybe we need some way to prevent this in specific cases?

Maybe some syntax along the lines of:

(+ HOME PATH path USER LOGNAME "fn "*) /usr/sbin/cron &

to pass HOME, PATH, path, USER, LOGNAME and fn_* only

(- "fn "*) /usr/sbin/cron &

to pass everything but fn_*

But then - as with most things this could be done in a function

eg: run sh with HOME USER LOGNAME
    run sh without "fn "*

which could be implemented relatively easily if there was an option to whatis 
to just list variables instead of show what they are.

(eg: "whatis -fq" - list functions, "whatis -vq" - list variables)

Anyway - basically - I think it might be more useful to extend whatis such
that it can be used to implement easily a facility to run a command without 
any environment variables, rather than to actually implement that facility 
internally.

David.
-- 
----------------------------------------------
David Luyer
Senior Network Engineer
Pacific Internet (Aust) Pty Ltd
Phone:  +61 3 9674 7525
Fax:    +61 3 9699 8693
Mobile: +61 4 1064 2258, +61 4 1114 2258
http://www.pacific.net.au        NASDAQ: PCNTF
<< fast 'n easy >>
----------------------------------------------




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

* Re: building rc on QNX4
  2000-05-08  8:29 ` Tim Goodwin
       [not found]   ` <tjg@star.le.ac.uk>
@ 2000-05-08 13:28   ` Carlo Strozzi
  1 sibling, 0 replies; 43+ messages in thread
From: Carlo Strozzi @ 2000-05-08 13:28 UTC (permalink / raw)
  To: rc

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

On Mon, May 08, 2000 at 04:29:54AM -0400, Tim Goodwin wrote:
 >> A more important issue IMHO is whether Rc should provide a built-in
 >> read function, similar to the one offered by most Bourne shells;
 >
 >There is no *need* to make `read' a builtin: see the EXAMPLES file in
 >the distribution for an alternative.  One of rc's design goals is to
 >avoid unnecessary builtins.  So, no, I don't think this is likely to
 >happen.
 >

Unfortunately the example provided does not work the way 'read' does,
and is an extra-process that needs to be spawned for each input line.
                                                                     
 >> one is whether it will ever make it possible not to export everything to
 >> the environment by default.
 >
 >I brought this up a few months ago, and the consensus seemed to be that
 >the current scheme works well enough in practice.  Have you encountered
 >a problem?

hmm ... not really. Mine is just a general concern. Currently I
initialize every variable that I'm going to use in a script, right
at the beginning of the program, somewhat like what you do with C
whan you declare things first.  That is because unless I maintain a
global name-space I never know what a variable is going to contain 
when the program is called. Having a clean environment would
be desirable in general.

Anyway, the above is another minor issue, it may as well be that the
current scheme is ok. What I _really_ miss is a 'read', or 'line',  
function, for record-oriented input, and I think this feeling is
shared also by others. While things like 'test' are rarely called   
inside a loop, reading lines from a file is the opposite, and spawning
an external process on each line sucks, especially when one uses
the shell for writing Web CGI scripts, like I do.

Beside all that, I am a long-time (Bourne) shell user, and I whish I
had uncovered rc before :-)

Anyway, just to give my two-cent and not just ask for things :-), here
are a couple of functions to emulate often-used external processes like
basename(1) and dirname(1). I've tried to mimic the respective utilities
as closely as I could. Bug-fixes are welcome :-)

bye  -carlo
-- 
I can read MIME or uuencoded e-mail attachments in PDF, Postscript, HTML,
RTF or text formats. Please do not send Word or Excel files. 

[-- Attachment #2: rcstuff.txt --]
[-- Type: text/plain, Size: 612 bytes --]

#
# Emulate dirname(1)
#

fn DirName {
   ~ $1 () && { echo DirName: too few arguments >[1=2] ; return 1 }
   ~ $1 '' .* && { echo . ; return }
   ~ $1 / && { echo / ; return }
   x=() y=() {
      x = ``(/) {echo -n $1}
      ~ $1 /* && ~ $x(2) () && { echo / ; return }
      ~ $x(2) () && { echo . ; return } 
      * = $x
      while (!~ $#* 0 1) { y = $y/$1 ; shift }
      echo $y
   }
}

#
# Emulate basename(1)
#

fn BaseName {
   ~ $1 () && { echo BaseName: too few arguments >[1=2] ; return 1 }
   ~ $1 '' / && return
   x = () {
      x = ``(/) {echo -n $1}
      echo $x($#x)
   }
}

# End of stuff.

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

* builtins
  2000-05-08 23:25 ` Stephen Tell
@ 2000-05-10  0:37   ` Scott Schwartz
  2000-05-12  7:22     ` builtins Carlo Strozzi
  0 siblings, 1 reply; 43+ messages in thread
From: Scott Schwartz @ 2000-05-10  0:37 UTC (permalink / raw)
  To: rc

My $0.02:  if you have echo as a builtin, read deserves the same.

My other $0.02:  echo needs a sibling builtin, quote, to enquote it's
arguments so that they can be read by the shell.  Lisp got that right ages
ago.  Inferno got it right more recently.

Followups to the es list, I guess. :-)



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

* Re: builtins
  2000-05-10  0:37   ` builtins Scott Schwartz
@ 2000-05-12  7:22     ` Carlo Strozzi
  0 siblings, 0 replies; 43+ messages in thread
From: Carlo Strozzi @ 2000-05-12  7:22 UTC (permalink / raw)
  To: rc

On Tue, May 09, 2000 at 08:37:09PM -0400, Scott Schwartz wrote:
| My $0.02:  if you have echo as a builtin, read deserves the same.

I definitely agree. This is the single most important point IMHO.
The prolem isn't just reading one single line fron stdin, as many unix
utilities would allow that easily, but rather to make possible a construct
like:
          { while ( read a ) echo $a } <file

where 'file' is big enough to blow up the environment if swallowed
all in one go.

Just as a hint, bourne shells solve the problem by silently forking a
subshell to handle the above -- and using a builtin read, of course.

| 
| My other $0.02:  echo needs a sibling builtin, quote, to enquote it's
| arguments so that they can be read by the shell.  Lisp got that right ages
| ago.  Inferno got it right more recently.

I'm not quite sure I am understanding this ...

| 
| Followups to the es list, I guess. :-)

Well, I think the 'read' stuff pertains also to Rc. While we are at it,
I am one of those who rised also the 'export or not to export' issue.
Having a shell that exports everything by default does pose some
problems.  I use the shell to build the "outer frame" of relatively
complex Web sites (search engines, on-line auctions, ...), and I came
to pick the shell for that job after having tried every sort of other
languages, from perl to tcl, to C, to ... you name it. As chance
would have it that the Apache Web server passes an almost completely
empty environment to CGI programs, to make it harder to trick them
into doing wrong things by fiddling with env stuff. Having a shell
that allows not to have everything global by default would help a lot
with building large applications, where the possibility of de-coupling
things may be a critical factor.

Maybe an all-or-none approach would solve both the need of not exporting
and the need of not breaking backward compatibility, and it would also be
be more in-line with the clean design of Rc, which is what I like most.
Beside having a @{...} construct to run things in a subshell, we could have
also a %{...} thing (or whatever), that would pass a completely empty
environment to subprocessess. Something like 'env -', but without spawning
an extra- process. In this way it would be applicable also when calling
functions.  Does that make any sense to you ?

Apart from that, I do not think Rc needs any other stuff built-in. It is
one of the best examples of perfectly usable minimalism I've seen so far :-)

        --Carlo
-- 
I can read MIME or uuencoded e-mail attachments in PDF, Postscript, HTML,
RTF or text formats. Please do not send Word or Excel files. 


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

* Beta release rc-1.6b3 available
@ 2001-10-15 13:56 Tim Goodwin
  2001-10-17 14:13 ` Buggs
  2001-10-23  7:55 ` Carlo Strozzi
  0 siblings, 2 replies; 43+ messages in thread
From: Tim Goodwin @ 2001-10-15 13:56 UTC (permalink / raw)
  To: rc

A new beta release, rc-1.6b3, is available from the usual place.

    http://www.star.le.ac.uk/~tjg/rc/beta/rc-1.6b3.tar.gz

Please test this beta!  I'd like to turn it into rc-1.7, but it needs
a lot more testing first.  I need positive feedback (platforms where
it builds and runs smoothly) as well as reports of any problems.

The NEWS file from this release is appended: it describes significant
changes since the rc-1.6 full release.  Further details are in the
ChangeLog file in the distribution, and even more details can be found
on my new "hacking notes" page; anyone who is, or would like to be,
familiar with rc's internals is encouraged to look at this page.

    http://www.star.le.ac.uk/~tjg/rc/misc/notes

The only major missing feature that I'm aware of is support for the
4.4 BSD libedit.  This is planned, but probably not till after rc-1.7.

Tim.


Highlights of changes since rc-1.6.  See ChangeLog for further details.

Portability.  Many minor tweaks, including fixes for BeOS, CygWin, and
gcc-3.

Bug fixes.  A number of bugs have been fixed.  The serious ones were:
a core dump, triggered by `~ () '*''; premature exit, triggered by
sourcing a file which could be open()ed but not read() (such as a
directory on many systems); uninterruptible looping, triggered by
semantic errors in `fn prompt'.

New features.  The following features are new: the `$version' variable
replaces the `-V' flag; the `-I' flag (definitively not interactive)
was added for compatibility with the Plan 9 rc; ASCII SOH (^A) is now
handled transparently.

Documentation.  Distributions of this rc used to include a PostScript
paper given by Tom Duff to the UKUUG, describing the Plan 9 rc.  This
paper is no longer distributed with rc, but instead is available on
the web, both in its original PostScript version, and an updated HTML
version.

Tim Goodwin
2001-10-05


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

* Re: Beta release rc-1.6b3 available
  2001-10-15 13:56 Beta release rc-1.6b3 available Tim Goodwin
@ 2001-10-17 14:13 ` Buggs
  2001-10-17 14:34   ` Tim Goodwin
  2001-10-23  7:55 ` Carlo Strozzi
  1 sibling, 1 reply; 43+ messages in thread
From: Buggs @ 2001-10-17 14:13 UTC (permalink / raw)
  To: Tim Goodwin, rc

On Monday 15 October 2001 15:56, Tim Goodwin wrote:
> A new beta release, rc-1.6b3, is available from the usual place.

Thanks.

> Please test this beta!  I'd like to turn it into rc-1.7, but it needs
> a lot more testing first.  I need positive feedback (platforms where
> it builds and runs smoothly) as well as reports of any problems.

Suse Linux 7.2 with a CVS gcc-3.1 from last week does fine.

But there are some issues, not version dependant, that I don't understand.
This will get out of control:

; fn l {ls -l $*}
; fn l {l -a $*}
; l


And what about job control, how do I handle that?

Thanks,
Buggs


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

* Re: Beta release rc-1.6b3 available
  2001-10-17 14:13 ` Buggs
@ 2001-10-17 14:34   ` Tim Goodwin
  2001-10-17 21:13     ` Buggs
  0 siblings, 1 reply; 43+ messages in thread
From: Tim Goodwin @ 2001-10-17 14:34 UTC (permalink / raw)
  To: buggs-rc; +Cc: rc

> Suse Linux 7.2 with a CVS gcc-3.1 from last week does fine.

Thanks for the report.  (Keep 'em coming, folks!)

> But there are some issues, not version dependant, that I don't understand.
> This will get out of control:
> 
> ; fn l {ls -l $*}
> ; fn l {l -a $*}
> ; l

Your function `l' always calls itself recursively, so it rapidly runs
out of stack.

Remember that, unlike other shells, rc is not a macro processor.  In
particular, the `l' in the function body of your second definition is
*not* expanded using the previous definition of `fn l'.  (You can
always use `whatis' to see the current definition of a function.)

A simple

    fn l { ls -la $* }

is probably what you want.

Also, check out the `builtin' builtin, which allows a function to call
a builtin or external command of the same name without recursing:

    fn ls { builtin ls -F $* }

> And what about job control, how do I handle that?

This shell does not have job control.

It has been said (by Duff? Pike? Rakitzis? I forget...) that job
control adds a deal of complexity to handle just the easy part of a
hard problem.  The suggested alternative in a windowing environment is
to open a new window.

If you're not in a windowing environment, you might like the `screen'
program, which does both the easy and hard parts of the problem.
There's also a "tabbed" version of gnome-terminal around, called
`multignometerm'.

Tim.


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

* Re: Beta release rc-1.6b3 available
  2001-10-17 14:34   ` Tim Goodwin
@ 2001-10-17 21:13     ` Buggs
  0 siblings, 0 replies; 43+ messages in thread
From: Buggs @ 2001-10-17 21:13 UTC (permalink / raw)
  To: Tim Goodwin; +Cc: rc

On Wednesday 17 October 2001 15:34, Tim Goodwin wrote:
> > Suse Linux 7.2 with a CVS gcc-3.1 from last week does fine.
>
> Thanks for the report.  (Keep 'em coming, folks!)

Your welcome. I migth be able to provide a few others next week.

> > But there are some issues, not version dependant, that I don't
> > understand. This will get out of control:
> >
> > ; fn l {ls -l $*}
> > ; fn l {l -a $*}
> > ; l
>
> Your function `l' always calls itself recursively, so it rapidly runs
> out of stack.

Thougth so.

> Remember that, unlike other shells, rc is not a macro processor.  In
> particular, the `l' in the function body of your second definition is
> *not* expanded using the previous definition of `fn l'.  (You can
> always use `whatis' to see the current definition of a function.)

So my old definition is lost and it constantly calls itself.

> A simple
>
>     fn l { ls -la $* }
>
> is probably what you want.

Yes, probably. But I also wondered about the why of the failure and
why I did not receive a warning (could have been a bug after all).

[...]
> > And what about job control, how do I handle that?
>
> This shell does not have job control.
>
> It has been said (by Duff? Pike? Rakitzis? I forget...) that job
> control adds a deal of complexity to handle just the easy part of a
> hard problem.  The suggested alternative in a windowing environment is
> to open a new window.

I see. That was exactly what I wanted to know, thanks.

> If you're not in a windowing environment, you might like the `screen'
> program, which does both the easy and hard parts of the problem.
> There's also a "tabbed" version of gnome-terminal around, called
> `multignometerm'.

Never used multignometerm but that is the way KDE's konsole takes,
which I can also recommend.


Thanks again,
Buggs


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

* Re: Beta release rc-1.6b3 available
  2001-10-15 13:56 Beta release rc-1.6b3 available Tim Goodwin
  2001-10-17 14:13 ` Buggs
@ 2001-10-23  7:55 ` Carlo Strozzi
  2001-10-23 12:44   ` Tim Goodwin
  2001-10-23 15:47   ` Markus Friedl
  1 sibling, 2 replies; 43+ messages in thread
From: Carlo Strozzi @ 2001-10-23  7:55 UTC (permalink / raw)
  To: rc

On Mon, Oct 15, 2001 at 08:56:06AM -0500, Tim Goodwin wrote:
> A new beta release, rc-1.6b3, is available from the usual place.
> 
>     http://www.star.le.ac.uk/~tjg/rc/beta/rc-1.6b3.tar.gz
> 
> Please test this beta!  I'd like to turn it into rc-1.7, but it needs
> a lot more testing first.  I need positive feedback (platforms where
> it builds and runs smoothly) as well as reports of any problems.

Mine is not really a bug report, buth rather a request for a new
feature. I dunno whether it has been asked before on this list, but
are there any chances that rc will ever handle a path specification
in the form of:

; command ~/path/to/file

where ``~'' gets substituted internally with the value of $home ?
Likewise, ~user should be replaced by $home/user/. Of course this
is a-la-bash, but it would make rc much more handy to use as
a login shell. The executable that I use has been linked with the
GNU readline library, which handles the above cases correctly, but
when it passes the path to rc the latter complains, of course.

bye,
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] 43+ messages in thread

* Re: Beta release rc-1.6b3 available
  2001-10-23  7:55 ` Carlo Strozzi
@ 2001-10-23 12:44   ` Tim Goodwin
  2001-10-23 15:47   ` Markus Friedl
  1 sibling, 0 replies; 43+ messages in thread
From: Tim Goodwin @ 2001-10-23 12:44 UTC (permalink / raw)
  To: carlos; +Cc: rc

> Mine is not really a bug report, buth rather a request for a new
> feature. I dunno whether it has been asked before on this list, but

Trust me: it has been asked before :-).

> are there any chances that rc will ever handle [tilde expansion ?]

Probably not.  Before it could happen, we would need: 

i) somebody to figure out how tilde expansion can co-exist with rc's
existing interpretation of tilde; OR

ii) somebody to persuade the tilde expanders of an alternate syntax
they are happy with.

Note that if you can twist option ii) far enough, rc *already* has
tilde expansion :-).

    ; fn h {if(~ () $1){echo $home}else perl -le 'print ((getpwnam('^$1^'))[7])'}

    ; echo `h
    /h/tjg

    ; echo `{h games}
    /usr/games

You should be horrified at the use of Perl here, so compile the
program below as `homedir', and use:

    ; fn h {if(~ () $1){echo $home}else homedir $1}

Cheers,

Tim.

#include <stdio.h>
#include <sys/types.h>
#include <pwd.h>

int main(int argc, char **argv) {
	if (argv[1]) {
		struct passwd *p = getpwnam(argv[1]);
		if (p)
			puts(p->pw_dir);
	}
}


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

* Re: Beta release rc-1.6b3 available
  2001-10-23  7:55 ` Carlo Strozzi
  2001-10-23 12:44   ` Tim Goodwin
@ 2001-10-23 15:47   ` Markus Friedl
  2001-10-23 21:09     ` Carlo Strozzi
  1 sibling, 1 reply; 43+ messages in thread
From: Markus Friedl @ 2001-10-23 15:47 UTC (permalink / raw)
  To: Carlo Strozzi, rc

On Tue, Oct 23, 2001 at 02:55:57AM -0500, Carlo Strozzi wrote:
> ; command ~/path/to/file

this has been discussed 1000 times, please check
the mail archive.

-m


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

* Re: Beta release rc-1.6b3 available
  2001-10-23 15:47   ` Markus Friedl
@ 2001-10-23 21:09     ` Carlo Strozzi
  0 siblings, 0 replies; 43+ messages in thread
From: Carlo Strozzi @ 2001-10-23 21:09 UTC (permalink / raw)
  To: rc

On Tue, Oct 23, 2001 at 04:47:52PM +0200, Markus Friedl wrote:
> On Tue, Oct 23, 2001 at 02:55:57AM -0500, Carlo Strozzi wrote:
> > ; command ~/path/to/file
> 
> this has been discussed 1000 times, please check
> the mail archive.

And another 1000 times it will probably be asked again in the future
by another 1000 people who think that such a feature would make sense :-)
Joking apart, I like rc very much, also because its supporters are
so reluctant about making it a feature-packed shell. I just think that
a `--with-tilde-hack' switch at configure time would not require more
syntax-tweaking than a `--with-eq-hack' one :-)

cheers,
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] 43+ messages in thread

* Re: Beta release rc-1.6b3 available 
  2001-10-23 15:55 ` Sam Roberts
@ 2001-10-23 21:14   ` Scott Schwartz
  0 siblings, 0 replies; 43+ messages in thread
From: Scott Schwartz @ 2001-10-23 21:14 UTC (permalink / raw)
  To: Sam Roberts; +Cc: rc

> I'd like to second this. It's the only reason I don't use rc as my
> shell, other than that I really like it. Does anybody have a patch?

I use "$h" for my home instead of "~".  It's a little longer, but not
really harder to type.  I use /u/user for home directories, which is easy
if you have an automounter (or Plan 9), and which works with all programs.

It's funny to call the tilde thing "a-la-bash", since it was invented
for csh many years before bash was written.

Mail thru hawkwind is very slow these days; is there a problem?



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

* Re: Beta release rc-1.6b3 available 
  2001-10-23 21:32 Carlo Strozzi
@ 2001-10-24  3:34 ` Chris Siebenmann
  2001-10-24  8:04   ` Carlo Strozzi
  0 siblings, 1 reply; 43+ messages in thread
From: Chris Siebenmann @ 2001-10-24  3:34 UTC (permalink / raw)
  To: rc

| On the other hand, one of the nice things abot rc is that it has a
| small memory footprint, and adding features would make it worse in
| that respect.

 Tilde expansion is particularly bad in that respect because it drags
in a large collection of code from the C library. In extreme cases, it
may not be possible to statically link something that uses getpwnam()
because the mechanisms for flexible username lookups require runtime
loaded dynamic libraries.

 If you do tilde expansion through the filesystem (for example, via a
/u directory full of symlinks from usernames to their real home
directory) you can gain the benefit of GNU readline auto-completion as
well as significant universality at the price of only a little extra
typing.

	- cks


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

* Re: Beta release rc-1.6b3 available 
  2001-10-24  3:25   ` Beta release rc-1.6b3 available Chris Siebenmann
@ 2001-10-24  3:41     ` Scott Schwartz
  0 siblings, 0 replies; 43+ messages in thread
From: Scott Schwartz @ 2001-10-24  3:41 UTC (permalink / raw)
  To: Chris Siebenmann; +Cc: rc

| The only reason I recompiled rc with large
| file support (on Linux) was so that commands could have stdin/stdout
| redirected from/to large files.

Yes, that's what I had in mind.

|  I don't know if autoconf et al has a test for large file support.

It does.  We probably ought to use it.



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

* Re: Beta release rc-1.6b3 available
  2001-10-24  3:34 ` Chris Siebenmann
@ 2001-10-24  8:04   ` Carlo Strozzi
  0 siblings, 0 replies; 43+ messages in thread
From: Carlo Strozzi @ 2001-10-24  8:04 UTC (permalink / raw)
  To: rc

On Tue, Oct 23, 2001 at 10:34:14PM -0500, Chris Siebenmann wrote:
> 
>  If you do tilde expansion through the filesystem (for example, via a
> /u directory full of symlinks from usernames to their real home
> directory) you can gain the benefit of GNU readline auto-completion as
> well as significant universality at the price of only a little extra
> typing.

Yes, I agree that that is probably the best compromise. I'll revert back
to that.

thanks,
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] 43+ messages in thread

* rc 1.6 $version
@ 2002-03-14 22:37 erik quanstrom
  2002-03-27 13:27 ` Tim Goodwin
  0 siblings, 1 reply; 43+ messages in thread
From: erik quanstrom @ 2002-03-14 22:37 UTC (permalink / raw)
  To: rc

is there any way that $version could be changed either
to not be so magic (i.e. assigned at startup time) or
better something like _rc_version_. i have been discovering
scripts that no longer work with rc 1.6 ever since i installed
it because they were assigning to $version and expecting the
same value back. silly me.

erik


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

* Re: rc 1.6 $version
  2002-03-14 22:37 rc 1.6 $version erik quanstrom
@ 2002-03-27 13:27 ` Tim Goodwin
  2002-03-27 21:12   ` Carlo Strozzi
  0 siblings, 1 reply; 43+ messages in thread
From: Tim Goodwin @ 2002-03-27 13:27 UTC (permalink / raw)
  To: quanstro; +Cc: rc

> is there any way that $version could be changed either
> to not be so magic (i.e. assigned at startup time) or
> better something like _rc_version_.

The `version' variable was introduced in rc-1.6b1 (replacing the `-V'
flag, which itself was new in rc-1.5b4).  Thus, it's never been in a
full release.  Thus, I'm prepared to change it :-).

Any objections to `rc_version'?

Tim.


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

* Re: rc 1.6 $version
  2002-03-27 13:27 ` Tim Goodwin
@ 2002-03-27 21:12   ` Carlo Strozzi
  2002-03-30 18:43     ` Paul Haahr
  0 siblings, 1 reply; 43+ messages in thread
From: Carlo Strozzi @ 2002-03-27 21:12 UTC (permalink / raw)
  To: rc

On Wed, Mar 27, 2002 at 08:27:16AM -0500, Tim Goodwin wrote:
> > is there any way that $version could be changed either
> > to not be so magic (i.e. assigned at startup time) or
> > better something like _rc_version_.
> 
> The `version' variable was introduced in rc-1.6b1 (replacing the `-V'
> flag, which itself was new in rc-1.5b4).  Thus, it's never been in a
> full release.  Thus, I'm prepared to change it :-).
> 
> Any objections to `rc_version'?

rc already has a few reserved variable names, like $pid, $bqstatus,
$status, and so on. Others, like $version, could be added in the
future. It would be nice to have a naming-convention for reserved names,
so that one knows in advance what names should be left alone.
The proposed `rc_version' is ok, and my suggestion is to set the `rc_'
prefix aside for rc reserved variables. We would then have rc_path,
rc_home, rc_whatever. Of course, for backward compatibility we will
continue to have also $pid, $path and that, but from now on there
whould at least be a standard for any new rc needs, and that
could be documented in the man page. Since rc supports 'funny'
characters in names, the reserved ones could even be 'rc.something',
so that they are even more peculiar. Just my two-cent.

bye,
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] 43+ messages in thread

* Re: rc 1.6 $version
  2002-03-27 21:12   ` Carlo Strozzi
@ 2002-03-30 18:43     ` Paul Haahr
  2002-03-31 15:13       ` Carlo Strozzi
                         ` (2 more replies)
  0 siblings, 3 replies; 43+ messages in thread
From: Paul Haahr @ 2002-03-30 18:43 UTC (permalink / raw)
  To: rc

Tim wrote
> Any objections to `rc_version'?

I'd prefer $rc-version, but either should be fine.

However, making it such a magic variable feels silly.  As Eric noted,
having assignments to a variable just be eaten without warning seems,
er, surprising at best.

Why not just initialize version (provided there's none set in the
environment?), not export it, and have any assignments turn it into a
normal variable.  I think that's pretty easy to do.

Carlo wrote:
> rc already has a few reserved variable names, like $pid, $bqstatus,
> $status [...]  and my suggestion is to set the `rc_' prefix aside for
> rc reserved variables. We would then have rc_path, rc_home,
> rc_whatever. Of course, for backward compatibility we will continue to
> have also $pid, $path and that, but from now on there whould at least
> be a standard for any new rc needs, and that could be documented in
> the man page.

No!  No!  No!

I understand why one might want to prefix ``version'' -- this is rc's
version, not a system-wide version -- but your path, home directory,
etc, are exported and global properties.  (The path/PATH distinction,
etc, is just backwards compatibility, after all.)

One of the points of rc is that it uses so few special variables that we
don't need special namespaces.

--p


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

* Re: rc 1.6 $version
  2002-03-30 18:43     ` Paul Haahr
@ 2002-03-31 15:13       ` Carlo Strozzi
  2002-04-03 14:31       ` Tim Goodwin
  2002-04-04 10:04       ` Tim Goodwin
  2 siblings, 0 replies; 43+ messages in thread
From: Carlo Strozzi @ 2002-03-31 15:13 UTC (permalink / raw)
  To: rc

On Sat, Mar 30, 2002 at 01:43:31PM -0500, Paul Haahr wrote:
> 
> Why not just initialize version (provided there's none set in the
> environment?), not export it, and have any assignments turn it into a
> normal variable.  I think that's pretty easy to do.

This certainly makes sense, I agree. Just forget about my proposed
special `rc_' namespace.

	-cs-
-- 
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] 43+ messages in thread

* Re: rc 1.6 $version
  2002-03-30 18:43     ` Paul Haahr
  2002-03-31 15:13       ` Carlo Strozzi
@ 2002-04-03 14:31       ` Tim Goodwin
  2002-04-03 15:06         ` Paul Haahr
  2002-04-04 10:04       ` Tim Goodwin
  2 siblings, 1 reply; 43+ messages in thread
From: Tim Goodwin @ 2002-04-03 14:31 UTC (permalink / raw)
  To: paul; +Cc: rc

Paul Haahr wrote:
> > Any objections to `rc_version'?
> 
> I'd prefer $rc-version, but either should be fine.

(As it turns out, this is all irrelevant, but I have would two
objections to this.  First, `-' turns on free careting, so you'd have
to say things like this.

    ; whatis $'rc-version'

Not so bad, but wrap it in another level of quotes, perhaps from a
less sane shell, and it starts to get *very* ugly.

    $ rc -c 'whatis $'"'rc-version'"

Secondly, rc is meant to be C-ish, not Lisp-ish.)

> However, making it such a magic variable feels silly.  As Eric noted,
> having assignments to a variable just be eaten without warning seems,
> er, surprising at best.

Mea culpa.  I failed to realise that there are two types of special
variable in rc: 1) those that merely have a default initial value, and
2) those that invoke special code when substituted.  Till now,
$version was in category 2.  I've just moved it to category 1.

Category 2 now contains just $apids and $status, which seems about
right; they are both, of necessity, magical.  Category 1 now contains
$ifs, $path, $pid, $prompt, and $version.  (I was surprised to
discover that assignments to pid are persistent!)

As a separate matter, several variables are not exportable.  These
are: $apid, $apids, $cdpath, $home, $ifs, $path, $pid, and $*.
(Remember that $cdpath, $home, and $path are all aliased to upper case
versions, which *are* exportable.  Also, the default assignment to
$path happens before $PATH is examined: so if $PATH is set, $path will
acquire its value instead of the default.)

I think $bqstatus and $status ought to be non-exportable too.  I've
just made them so; you can all see what this breaks in the next
release candidate :-).

Tim.


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

* Re: rc 1.6 $version
  2002-04-03 14:31       ` Tim Goodwin
@ 2002-04-03 15:06         ` Paul Haahr
  0 siblings, 0 replies; 43+ messages in thread
From: Paul Haahr @ 2002-04-03 15:06 UTC (permalink / raw)
  To: Tim Goodwin; +Cc: rc

Tim wrote

> > I'd prefer $rc-version, but either should be fine.
> 
> (As it turns out, this is all irrelevant, but I have would two
> objections to this.  First, `-' turns on free careting, [...]

Yeah, I forgot about that.  (We had fixed that in es.)

> Secondly, rc is meant to be C-ish, not Lisp-ish.)

That, too, we fixed in es.

> Mea culpa.  I failed to realise that there are two types of special
> variable in rc: 1) those that merely have a default initial value, and
> 2) those that invoke special code when substituted.  Till now,
> $version was in category 2.  I've just moved it to category 1.

This seems quite sensible.

> As a separate matter, several variables are not exportable.  These
> are: $apid, $apids, $cdpath, $home, $ifs, $path, $pid, and $*.
> (Remember that $cdpath, $home, and $path are all aliased to upper case
> versions, which *are* exportable.  Also, the default assignment to
> $path happens before $PATH is examined: so if $PATH is set, $path will
> acquire its value instead of the default.)
> 
> I think $bqstatus and $status ought to be non-exportable too.  I've
> just made them so; you can all see what this breaks in the next
> release candidate :-).

Seems good to me.

Three questions:
  - Is $version exportable?
  - Is $version exported if the user doesn't assign to it?
  - Is $version inherited from the environment?

--p


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

* Re: rc 1.6 $version
  2002-03-30 18:43     ` Paul Haahr
  2002-03-31 15:13       ` Carlo Strozzi
  2002-04-03 14:31       ` Tim Goodwin
@ 2002-04-04 10:04       ` Tim Goodwin
  2002-04-04 21:42         ` Scott Schwartz
  2 siblings, 1 reply; 43+ messages in thread
From: Tim Goodwin @ 2002-04-04 10:04 UTC (permalink / raw)
  To: paul; +Cc: rc

> Why not just initialize version (provided there's none set in the
> environment?), not export it, and have any assignments turn it into a
> normal variable.  I think that's pretty easy to do.

OK, after a couple of iterations I've now done exactly that.

I've made $prompt act in the same way; I wonder if $ifs should too?
The other variables to which rc gives default values: $path and $pid;
are never exported.

All this will be in another release candidate soon...

Tim.


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

* Re: rc 1.6 $version 
  2002-04-04 10:04       ` Tim Goodwin
@ 2002-04-04 21:42         ` Scott Schwartz
  0 siblings, 0 replies; 43+ messages in thread
From: Scott Schwartz @ 2002-04-04 21:42 UTC (permalink / raw)
  To: Tim Goodwin; +Cc: rc

| > Why not just initialize version (provided there's none set in the
| > environment?), not export it, and have any assignments turn it into a
| > normal variable.  I think that's pretty easy to do.
| 
| OK, after a couple of iterations I've now done exactly that.

I dunno.  In that case calling it rc_version makes more sense to me.
Less likely to have accidental collisions.



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

* Re: rc 1.6 $version
@ 2002-04-04 21:54 Byron Rakitzis
  2002-04-05  8:35 ` Tim Goodwin
  0 siblings, 1 reply; 43+ messages in thread
From: Byron Rakitzis @ 2002-04-04 21:54 UTC (permalink / raw)
  To: paul, tjg; +Cc: rc

>I've made $prompt act in the same way; I wonder if $ifs should too?

I would have thought you'd want to export $prompt.

What about subshells?


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

* Re: rc 1.6 $version
@ 2002-04-05  1:38 smarry
  0 siblings, 0 replies; 43+ messages in thread
From: smarry @ 2002-04-05  1:38 UTC (permalink / raw)
  To: byron, paul, tjg; +Cc: rc

>I would have thought you'd want to export $prompt.

I'd rather have prompt exported as well.


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

* Re: rc 1.6 $version
  2002-04-04 21:54 Byron Rakitzis
@ 2002-04-05  8:35 ` Tim Goodwin
  0 siblings, 0 replies; 43+ messages in thread
From: Tim Goodwin @ 2002-04-05  8:35 UTC (permalink / raw)
  To: rc

> I would have thought you'd want to export $prompt.

It's exported if it's changed from the default.

The motivation for doing so was this little snippet:

    $ env - rc
    ; printenv
    PATH=/usr/local/bin:/usr/bin:/bin:.
    prompt=; ^A

No point in cluttering the environment with a value that any
descendant rc process would default to anyway.  And since I'd just
invented the mechanism to export $version only if it's assigned to
(all 3 lines of code of it!), I thought I'd use it.

So in the dev version, we get this.

    $ env - rc
    ; printenv
    PATH=/usr/local/bin:/usr/bin:/bin:.
    ; prompt=('rc$ ' '')
    rc$ printenv
    PATH=/usr/local/bin:/usr/bin:/bin:.
    prompt=rc$ ^A

(And even PATH goes away if you build with `--disable-def-path'.)

Tim.


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

end of thread, back to index

Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-09-17 15:56 are there any patches which add ~ expansion to rc Joseph Skinner
1997-09-17 21:56 ` Scott Schwartz
1997-09-17 22:08 ` Mark K. Gardner
1997-09-18 23:26 Chris Siebenmann
     [not found] ` <cks@hawkwind.utcs.toronto.edu>
1992-06-04 10:05   ` $pid malte
1992-11-04 12:45   ` set subtract malte
1992-11-06 12:03   ` rc and signal handlers malte
1997-09-19 17:21   ` are there any patches which add ~ expansion to rc Jeremy Fitzhardinge
2001-10-24  3:25   ` Beta release rc-1.6b3 available Chris Siebenmann
2001-10-24  3:41     ` Scott Schwartz
2000-04-26 15:02 building rc on QNX4 Sam Roberts
2000-04-27 16:56 Scott Schwartz
2000-04-27 20:41 ` Sam Roberts
2000-04-28  7:28   ` vrl (was: Re: building rc on QNX4) Gert-Jan Vons
2000-04-28 18:38     ` Sam Roberts
2000-05-02  8:16       ` Gert-Jan Vons
2000-04-28 19:03     ` rc not session leader? Sam Roberts
2000-04-27 17:39 building rc on QNX4 Carlo Strozzi
2000-05-02 14:41 ` Tim Goodwin
2000-05-04 15:18 Carlo Strozzi
2000-05-08  8:29 ` Tim Goodwin
     [not found]   ` <tjg@star.le.ac.uk>
2000-05-08 11:50     ` David Luyer
2000-05-08 13:28   ` Carlo Strozzi
     [not found] <tell@cs.unc.edu>
2000-05-08 23:25 ` Stephen Tell
2000-05-10  0:37   ` builtins Scott Schwartz
2000-05-12  7:22     ` builtins Carlo Strozzi
2001-10-15 13:56 Beta release rc-1.6b3 available Tim Goodwin
2001-10-17 14:13 ` Buggs
2001-10-17 14:34   ` Tim Goodwin
2001-10-17 21:13     ` Buggs
2001-10-23  7:55 ` Carlo Strozzi
2001-10-23 12:44   ` Tim Goodwin
2001-10-23 15:47   ` Markus Friedl
2001-10-23 21:09     ` Carlo Strozzi
     [not found] <sroberts@certicom.com>
2001-10-23 15:55 ` Sam Roberts
2001-10-23 21:14   ` Scott Schwartz
2001-10-23 21:32 Carlo Strozzi
2001-10-24  3:34 ` Chris Siebenmann
2001-10-24  8:04   ` Carlo Strozzi
2002-03-14 22:37 rc 1.6 $version erik quanstrom
2002-03-27 13:27 ` Tim Goodwin
2002-03-27 21:12   ` Carlo Strozzi
2002-03-30 18:43     ` Paul Haahr
2002-03-31 15:13       ` Carlo Strozzi
2002-04-03 14:31       ` Tim Goodwin
2002-04-03 15:06         ` Paul Haahr
2002-04-04 10:04       ` Tim Goodwin
2002-04-04 21:42         ` Scott Schwartz
2002-04-04 21:54 Byron Rakitzis
2002-04-05  8:35 ` Tim Goodwin
2002-04-05  1:38 smarry

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