* building rc on QNX4 @ 2000-04-26 15:02 ` Sam Roberts 2000-04-27 16:56 ` Scott Schwartz 2000-04-27 17:39 ` building rc on QNX4 Carlo Strozzi 0 siblings, 2 replies; 19+ 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] 19+ 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 ` building rc on QNX4 Carlo Strozzi 1 sibling, 1 reply; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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 2000-05-04 15:18 ` Carlo Strozzi 0 siblings, 1 reply; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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 2000-05-08 11:50 ` building rc on QNX4 David Luyer 2000-05-08 13:28 ` Carlo Strozzi 2 siblings, 1 reply; 19+ 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] 19+ 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; 19+ 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] 19+ messages in thread
* Re: building rc on QNX4 2000-05-08 9:15 ` Tim Goodwin @ 2000-05-08 23:25 ` Stephen Tell 2000-05-10 0:37 ` builtins Scott Schwartz 0 siblings, 1 reply; 19+ 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] 19+ 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; 19+ 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] 19+ messages in thread
* Re: builtins 2000-05-10 0:37 ` builtins Scott Schwartz @ 2000-05-12 7:22 ` Carlo Strozzi 0 siblings, 0 replies; 19+ 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] 19+ 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 11:50 ` David Luyer 2000-05-08 13:28 ` Carlo Strozzi 2 siblings, 0 replies; 19+ 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] 19+ 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 11:50 ` building rc on QNX4 David Luyer @ 2000-05-08 13:28 ` Carlo Strozzi 2 siblings, 0 replies; 19+ 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] 19+ messages in thread
* Re: builtins @ 2000-05-12 5:49 Smarasderagd 0 siblings, 0 replies; 19+ messages in thread From: Smarasderagd @ 2000-05-12 5:49 UTC (permalink / raw) To: rc, schwartz Scott Schwartz <schwartz@bio.cse.psu.edu> writes: >My $0.02: if you have echo as a builtin, read deserves the same. Should it honour escaped newlines the way Bourne shell read does? Wouldn't it be nice if you could read arrays? But what we really want is to generalize all of the hidden goo that reads input until we can reimplement the main loop as "while () {read a; eval $a}", and optionally also "echo $a >> $history", and a replacement for - and -- that lets you do structural editing... >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. Oh, I guess that IS where you want to go. :) Seriously, I don't see any real reason why a quoting function doesn't make sense, since whatis already does this... ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2000-05-14 5:34 UTC | newest] Thread overview: 19+ 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-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 2000-05-08 8:58 ` Chris Siebenmann 2000-05-08 9:15 ` Tim Goodwin 2000-05-08 23:25 ` Stephen Tell 2000-05-10 0:37 ` builtins Scott Schwartz 2000-05-12 7:22 ` builtins Carlo Strozzi 2000-05-08 11:50 ` building rc on QNX4 David Luyer 2000-05-08 13:28 ` Carlo Strozzi 2000-05-12 5:49 builtins Smarasderagd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).