rc-list - mailing list for the rc(1) shell
 help / Atom feed
* building rc on QNX4
@ 2000-04-26 15:02 ` Sam Roberts
  2000-04-27 16:56   ` Scott Schwartz
  2000-04-27 17:39   ` Carlo Strozzi
  0 siblings, 2 replies; 26+ 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] 26+ messages in thread

* Re: building rc on QNX4 
  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-27 17:39   ` Carlo Strozzi
  1 sibling, 1 reply; 26+ messages in thread
From: Scott Schwartz @ 2000-04-27 16:56 UTC (permalink / raw)
  To: 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)?

Years ago, Henry Spencer wrote a man-page-only-roff in awk for cnews,
for just such a contingency.



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

* Re: building rc on QNX4
  2000-04-26 15:02 ` building rc on QNX4 Sam Roberts
  2000-04-27 16:56   ` Scott Schwartz
@ 2000-04-27 17:39   ` Carlo Strozzi
  2000-05-02 14:41     ` Tim Goodwin
  1 sibling, 1 reply; 26+ messages in thread
From: Carlo Strozzi @ 2000-04-27 17:39 UTC (permalink / raw)
  To: rc

On Wed, Apr 26, 2000 at 11:02:31AM -0400, Sam Roberts wrote:
 >
 >rc looks really good to me, so I built it over the weekend, and

I agree, it is a neat shell, much better than Bourne and derivatives
for scripting. I am awful at C programming, but I think adding a few
addons to rc should be easy. The only thing that I really miss is a
'read' builtin. Using line(1) did not work, at least on Linux, apart
from the fact that being line(1) an external process it is not really
efficient, as it is often called from inside a loop.

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

cheers  -carlo
-- 
Attachments only in HTML/RTF/Postscript please !                    
Per favore solo attachments in formato HTML/RTF/Postscript !


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

* Re: building rc on QNX4 
  2000-04-27 16:56   ` Scott Schwartz
@ 2000-04-27 20:41     ` Sam Roberts
  0 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: building rc on QNX4
  2000-04-27 17:39   ` Carlo Strozzi
@ 2000-05-02 14:41     ` Tim Goodwin
  2000-05-04 15:18       ` Carlo Strozzi
  0 siblings, 1 reply; 26+ 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] 26+ messages in thread

* Re: building rc on QNX4
@ 2000-05-04  8:45 Byron Rakitzis
  2000-05-06 10:28 ` Carlo Strozzi
  2000-05-06 16:35 ` Jeremy Fitzhardinge
  0 siblings, 2 replies; 26+ messages in thread
From: Byron Rakitzis @ 2000-05-04  8:45 UTC (permalink / raw)
  To: rc, tjg

> to rc with a longer and more meaningful name, like 'rcsh'.

I guess I can't shut up -- "rcsh" seems like an abominable name.

rc has nothing to do with csh or any of the {tzck}sh family.

We may as well call it "rash".

Byron.


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

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

Previously, you (Tim Goodwin) wrote:
 
> > 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'.

I like that the name is short, personally. You can call yours
whatever you want, but rcsh sounds like the restricted C shell to me...

Sam
 
--
Sam Roberts (sam@cogent.ca), Cogent Real-Time Systems (www.cogent.ca)
"News is very popular among its readers." - RFC 977 (NNTP)



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

* Re: building rc on QNX4
  2000-05-02 14:41     ` Tim Goodwin
@ 2000-05-04 15:18       ` Carlo Strozzi
  2000-05-08  8:29         ` Tim Goodwin
  0 siblings, 1 reply; 26+ messages in thread
From: Carlo Strozzi @ 2000-05-04 15:18 UTC (permalink / raw)
  To: rc

On Tue, May 02, 2000 at 10:41:13AM -0400, Tim Goodwin wrote:
 >> 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.
 (...)
 >Sounds a bit close to `tcsh' to me :-).  But if that's what you want,
 >just say
 >
 >    sh configure '--program-suffix=sh'

Hmm ... that's not the point. What I mean is that the new additional
name should be set by the mainstream distribution of Rc, just to acquire
such name. This is especially true for Debian GNU/Linux, where whoever
acquires a name first "wins". Anyway, this is not at all a big issue,
and I am not going to insist on it :-).  Mine was just a general
concern about using too short names for programs less ubiquitous
than /bin/sh.

A more important issue IMHO is whether Rc should provide a built-in
read function, similar to the one offered by most Bourne shells; another
one is whether it will ever make it possible not to export everything to
the environment by default.

Any thoughts about this ?

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. 


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

* Re: building rc on QNX4
  2000-05-04  8:45 Byron Rakitzis
@ 2000-05-06 10:28 ` Carlo Strozzi
  2000-05-07 17:46   ` Paul Haahr
  2000-05-06 16:35 ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 26+ messages in thread
From: Carlo Strozzi @ 2000-05-06 10:28 UTC (permalink / raw)
  To: rc

On Thu, May 04, 2000 at 04:45:52AM -0400, Byron Rakitzis wrote:
 >> to rc with a longer and more meaningful name, like 'rcsh'.
 >
 >I guess I can't shut up -- "rcsh" seems like an abominable name.
 >
 >rc has nothing to do with csh or any of the {tzck}sh family.
 >
 >We may as well call it "rash".

Well, why not :-). Even calling it by it's name, that is Rc, would
be reasonable. The mixed-casing would make it unique enough.

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

* Re: building rc on QNX4
  2000-05-04  8:45 Byron Rakitzis
  2000-05-06 10:28 ` Carlo Strozzi
@ 2000-05-06 16:35 ` Jeremy Fitzhardinge
  1 sibling, 0 replies; 26+ messages in thread
From: Jeremy Fitzhardinge @ 2000-05-06 16:35 UTC (permalink / raw)
  To: Byron Rakitzis; +Cc: tjg, rc


On 04-May-2000 Byron Rakitzis wrote:
>> to rc with a longer and more meaningful name, like 'rcsh'.
> 
> I guess I can't shut up -- "rcsh" seems like an abominable name.
> 
> rc has nothing to do with csh or any of the {tzck}sh family.
> 
> We may as well call it "rash".

9sh would be consistent with some other names (9term, 9wm, etc).  But I prefer
rc.

        J


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

* Re: building rc on QNX4
@ 2000-05-06 21:47 Byron Rakitzis
  0 siblings, 0 replies; 26+ messages in thread
From: Byron Rakitzis @ 2000-05-06 21:47 UTC (permalink / raw)
  To: rc

>Well, why not :-). Even calling it by it's name, that is Rc, would
>be reasonable. The mixed-casing would make it unique enough.

Let's see, the Unix port of rc has been around for nearly 10 years.

What compelling reason is there to change its name now?

Byron.


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

* Re: building rc on QNX4
  2000-05-06 10:28 ` Carlo Strozzi
@ 2000-05-07 17:46   ` Paul Haahr
  2000-05-08  8:01     ` Carlo Strozzi
  0 siblings, 1 reply; 26+ messages in thread
From: Paul Haahr @ 2000-05-07 17:46 UTC (permalink / raw)
  To: carlos; +Cc: rc

Carlo Strozzi wrote
> Even calling it by it's name, that is Rc, would be reasonable. The
> mixed-casing would make it unique enough.

And is the absolute worst suggestion we've had so far.

Some of us have happily used Byron's rc for nearly a decade (others have
used the Plan 9 version for even longer) and the name has worked well
for all that time.

Please just forget about changing the name.  If you want to use it with
another name, you know how to do it.  But the name of the executbale is
rc, and changing that is not worth discussing.

--p


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

* Re: building rc on QNX4
  2000-05-07 17:46   ` Paul Haahr
@ 2000-05-08  8:01     ` Carlo Strozzi
  0 siblings, 0 replies; 26+ messages in thread
From: Carlo Strozzi @ 2000-05-08  8:01 UTC (permalink / raw)
  To: Paul Haahr; +Cc: rc

On Sun, May 07, 2000 at 01:46:31PM -0400, Paul Haahr wrote:
 >Carlo Strozzi wrote
 >> Even calling it by it's name, that is Rc, would be reasonable. The
 >> mixed-casing would make it unique enough.
 >
 >And is the absolute worst suggestion we've had so far.
 >
 >Some of us have happily used Byron's rc for nearly a decade (others have
 >used the Plan 9 version for even longer) and the name has worked well
 >for all that time.
 >
 >Please just forget about changing the name.  If you want to use it with
 >another name, you know how to do it.  But the name of the executbale is
 >rc, and changing that is not worth discussing.

Apart from the fact that I didn't suggest to change its name, but
just to add a symlink in the stock 'make install' stuff (9sh is the
best one I've heard so far), it's interesting to see how that admittedly
irrelevant topic spawned more replies than the other two in the
same message, i.e. how about having a 'read' builtin and not exporting
every sort of stuff to the environment by default. Even if I added such
features myself -- I'm awful at C --, they would not be part of the
standard distribution, that's why I'm asking for an opinion here.

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. 


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

* Re: building rc on QNX4
  2000-05-04 15:18       ` Carlo Strozzi
@ 2000-05-08  8:29         ` Tim Goodwin
  2000-05-08  8:58           ` Chris Siebenmann
                             ` (2 more replies)
  0 siblings, 3 replies; 26+ 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] 26+ messages in thread

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

| There is no *need* to make `read' a builtin: see the EXAMPLES file in
| the distribution for an alternative.

 Unfortunately the example doesn't work in several very useful
situations: it will badly flub the common scripting idiom of
'generate stuff | {while (read foo) {....}}', never processing
most of the actual output.

 In order to make this work, you need to find a utility that is
guaranteed to read no more than the first line of standard input.
Most utilities (eg awk) will happily eat an entire large buffer
worth of standard input and then give you the first line back.
This is unfortunate if you wanted to read the rest of the buffer's
worth of input later.

 read is the one extra command that I really think should be a
builtin. I believe there are good versions that are simple to
add (through the existing hooks) in the mailing list archives[*].

	- cks
[*: ftp://ftp.sys.utoronto.ca/pub/rc/ for new people.]


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

* Re: building rc on QNX4
  2000-05-08  8:58           ` Chris Siebenmann
@ 2000-05-08  9:15             ` Tim Goodwin
  2000-05-08 23:25               ` Stephen Tell
  0 siblings, 1 reply; 26+ messages in thread
From: Tim Goodwin @ 2000-05-08  9:15 UTC (permalink / raw)
  To: rc

>  In order to make this work, you need to find a utility that is
> guaranteed to read no more than the first line of standard input.

Yup.  What if such a utility were distributed with rc, or as part of an
rc-utils package?

>  read is the one extra command that I really think should be a
> builtin.

OK.  Any other views?

Tim.


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

* Re: building rc on QNX4
@ 2000-05-08 10:19 Bengt Kleberg
  0 siblings, 0 replies; 26+ messages in thread
From: Bengt Kleberg @ 2000-05-08 10:19 UTC (permalink / raw)
  To: rc, tjg

> From: Tim Goodwin <tjg@star.le.ac.uk>
> >  In order to make this work, you need to find a utility that is
> > guaranteed to read no more than the first line of standard input.
> What if such a utility were distributed with rc

Good enough for me. And please call it 'read' if it will help.


Best Wishes, Bengt
===============================================================
Everything aforementioned should be regarded as totally private
opinions, and nothing else. bengt@softwell.se
``His great strength is that he is uncompromising. It would make
him physically ill to think of programming in C++.''


^ permalink raw reply	[flat|nested] 26+ 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; 26+ 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] 26+ messages in thread

* Re: building rc on QNX4
  2000-05-08  8:29         ` Tim Goodwin
  2000-05-08  8:58           ` Chris Siebenmann
       [not found]           ` <tjg@star.le.ac.uk>
@ 2000-05-08 13:28           ` Carlo Strozzi
  2 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: building rc on QNX4
@ 2000-05-08 15:15 Smarasderagd
  2000-05-09  8:22 ` Carlo Strozzi
  0 siblings, 1 reply; 26+ messages in thread
From: Smarasderagd @ 2000-05-08 15:15 UTC (permalink / raw)
  To: cks, rc

Chris Siebenmann <cks@hawkwind.utcs.toronto.edu> writes:
> Unfortunately the example doesn't work in several very useful
>situations: it will badly flub the common scripting idiom of
>'generate stuff | {while (read foo) {....}}', never processing
>most of the actual output.

My usual way through this situation has been to recode it as

for (i in `{generate stuff}) {...}

replacing ` with ``($nl) if I really want lines and not tokens. If the
input is big enough to cause problems for rc, I switch to awk, sed, or
whatever.  Complicated interactive scripts I usually write in awk/gawk.
This won't work to interact with a network connection, such as the news
and FTP snarfing scripts I use (see below.)

> In order to make this work, you need to find a utility that is
>guaranteed to read no more than the first line of standard input.
>Most utilities (eg awk) will happily eat an entire large buffer
>worth of standard input and then give you the first line back.
>This is unfortunate if you wanted to read the rest of the buffer's
>worth of input later.

I wrote a tiny C program "line" that reads a character at a time to ensure
that further input doesn't get eaten, and another one "spew" to handle
the "." on a line by itself ending a block of output protocol used by
news, mail, and others.  "line" wouldn't be necessary if news didn't
respond to article requests etc. with a response code line immediately
followed by the output.  You may notice that SMTP/NNTP don't put the
server in this situation...


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

* Re: building rc on QNX4
@ 2000-05-08 15:23 Sam Roberts
  2000-05-09  8:25 ` Carlo Strozzi
  0 siblings, 1 reply; 26+ messages in thread
From: Sam Roberts @ 2000-05-08 15:23 UTC (permalink / raw)
  To: rc

Previously, you (Carlo Strozzi) 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; another
> one is whether it will ever make it possible not to export everything to
> the environment by default.
> 
> Any thoughts about this ?

Did you search the mailing list archive? Somebody might have posted
code to do this.

Sam

--
Sam Roberts (sam@cogent.ca), Cogent Real-Time Systems (www.cogent.ca)
"News is very popular among its readers." - RFC 977 (NNTP)



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

* Re: building rc on QNX4
  2000-05-08  9:15             ` Tim Goodwin
@ 2000-05-08 23:25               ` Stephen Tell
  0 siblings, 0 replies; 26+ messages in thread
From: Stephen Tell @ 2000-05-08 23:25 UTC (permalink / raw)
  To: rc

On Mon, 8 May 2000, Tim Goodwin wrote:

> Date: Mon, 8 May 2000 05:15:01 -0400
> From: Tim Goodwin <tjg@star.le.ac.uk>
> To: rc@hawkwind.utcs.toronto.edu
> Subject: Re: building rc on QNX4
> 
> >  In order to make this work, you need to find a utility that is
> > guaranteed to read no more than the first line of standard input.
> 
> Yup.  What if such a utility were distributed with rc, or as part of an
> rc-utils package?

I suppose that would be sufficient.  The workaround I've used
has been this:

 var = `{sh -c 'read t; echo $t'}  # read var

Starting up sh just to avoid the little bit of code that a read
builtin would add to rc itself or an included utility seems a bit
rediculous.


-- 
Steve Tell | tell@cs.unc.edu | http://www.cs.unc.edu/~tell | KF4ZPF
On Leave from UNC working at Chip2Chip, Inc.  tell@chip2chip.com/919-929-0991




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

* Re: building rc on QNX4
@ 2000-05-09  4:34 Smarasderagd
  2000-05-11 12:26 ` Gert-Jan Vons
  0 siblings, 1 reply; 26+ messages in thread
From: Smarasderagd @ 2000-05-09  4:34 UTC (permalink / raw)
  To: david_luyer, tjg; +Cc: rc

David Luyer <david_luyer@pacific.net.au> writes:
>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.

In some cases this limit is enforced by the operating system; execve() chokes
on Linux if the arguments plus environment exceed (I think) 128K.

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

If you don't need to export anything but non-array variables, the "-i"
or "-" option to "env" does what you want.  For the other cases:

You could have a whatis option (or a gnarly function that understands
enough rc syntax not to be fooled by newlines in quoted strings) that
spews null assignments / definitions for everything, and then eval the
result filtered for the things you want to preserve, but eeuugh.  If a
function is that big it won't be much slower if it's a script instead.


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

* Re: building rc on QNX4
  2000-05-08 15:15 Smarasderagd
@ 2000-05-09  8:22 ` Carlo Strozzi
  0 siblings, 0 replies; 26+ messages in thread
From: Carlo Strozzi @ 2000-05-09  8:22 UTC (permalink / raw)
  To: rc

On Mon, May 08, 2000 at 11:15:02AM -0400, Smarasderagd wrote:
 (...)
 >replacing ` with ``($nl) if I really want lines and not tokens. If the
 >input is big enough to cause problems for rc, I switch to awk, sed, or
 >whatever.  Complicated interactive scripts I usually write in awk/gawk.

awk and sed are great tools, but the problem with awk is that any
interactions with external utilities spawns an extra /bin/sh process,
wich sucks a hell of a lot in Web CGI scripts. That's why using a shell
in the first place, with a bit of care, tends to be more efficient.
And awk does not even have an 'exec' facility, that would also help with
saving processes.

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. 


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

* Re: building rc on QNX4
  2000-05-08 15:23 Sam Roberts
@ 2000-05-09  8:25 ` Carlo Strozzi
  0 siblings, 0 replies; 26+ messages in thread
From: Carlo Strozzi @ 2000-05-09  8:25 UTC (permalink / raw)
  To: rc

On Mon, May 08, 2000 at 11:23:57AM -0400, Sam Roberts wrote:
 >Previously, you (Carlo Strozzi) 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; another
 >> one is whether it will ever make it possible not to export everything to
 >> the environment by default.
 >> 
 >> Any thoughts about this ?
 >
 >Did you search the mailing list archive? Somebody might have posted
 >code to do this.

No, I didn't. Thanks for the suggestion. Actually I am experiencing
some delay in receiving messages from the list, and I apologize with
the other subscribers if sometimes I seem to be asking questions
that have already been replied by others.

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. 


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

* Re: building rc on QNX4
  2000-05-09  4:34 Smarasderagd
@ 2000-05-11 12:26 ` Gert-Jan Vons
  0 siblings, 0 replies; 26+ messages in thread
From: Gert-Jan Vons @ 2000-05-11 12:26 UTC (permalink / raw)
  To: David Luyer; +Cc: rc

David Luyer <david_luyer@pacific.net.au> wrote:

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

For me "whatis |wc -c" returns 3308 bytes. However, I use a lot of lazy 
function loading, as has been talked about before on this list.

In my .rcrc, I have:

># Lazy function (un)loading.
>#
>fnlib = $home/bin/rcfuncs
>fn _ld { ~ $#* 1 && builtin . $fnlib/$1 }
>fn _unld { ~ $#* 1 && fn $1 { _ld $0 && $0 $* }}
>
># init all lazy functions by scanning the $fnlib directory
>name = () for ( name in `{builtin cd $fnlib ; ls} ) _unld $name

where my $home/bin/rcfuncs directory contains a number of files with rc 
function definitions (note that the file name must match the name of the 
function defined in it)

So until I actually use my rc functions, for a lot of them there's only 
"fn somefunc {_ld $0&&$0 $*}" in my environment, which gets expanded to 
the real function the first time I call somefunc.

And instead of re-reading my .rcrc file after every change to some 
function, I just do an "_unld newfunc", and the next time I call 
"newfunc", it is automatically reloaded from file.

If your functions are really big, you could even unload them 
automatically after use. But in that case, turning those functions into 
rc shell scripts is probably simpler...



         Gert-Jan
-----
"I have every sympathy with the American who was so horrified
  by what he had read about the effects of smoking that he gave
  up reading."
     - Henry G. Strauss



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

end of thread, back to index

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <sroberts@uniserve.com>
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-27 17:39   ` Carlo Strozzi
2000-05-02 14:41     ` Tim Goodwin
2000-05-04 15:18       ` Carlo Strozzi
2000-05-08  8:29         ` Tim Goodwin
2000-05-08  8:58           ` Chris Siebenmann
2000-05-08  9:15             ` Tim Goodwin
2000-05-08 23:25               ` Stephen Tell
     [not found]           ` <tjg@star.le.ac.uk>
2000-05-08 11:50             ` David Luyer
2000-05-08 13:28           ` Carlo Strozzi
2000-05-04  8:45 Byron Rakitzis
2000-05-06 10:28 ` Carlo Strozzi
2000-05-07 17:46   ` Paul Haahr
2000-05-08  8:01     ` Carlo Strozzi
2000-05-06 16:35 ` Jeremy Fitzhardinge
2000-05-04 13:46 Sam Roberts
2000-05-06 21:47 Byron Rakitzis
2000-05-08 10:19 Bengt Kleberg
2000-05-08 15:15 Smarasderagd
2000-05-09  8:22 ` Carlo Strozzi
2000-05-08 15:23 Sam Roberts
2000-05-09  8:25 ` Carlo Strozzi
2000-05-09  4:34 Smarasderagd
2000-05-11 12:26 ` Gert-Jan Vons

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