rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* 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-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: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 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 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
@ 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-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
[parent not found: <sroberts@uniserve.com>]

end of thread, other threads:[~2000-05-11 20:55 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-04  8:45 building rc on QNX4 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
  -- strict thread matches above, loose matches on Subject: below --
2000-05-09  4:34 Smarasderagd
2000-05-11 12:26 ` Gert-Jan Vons
2000-05-08 15:23 Sam Roberts
2000-05-09  8:25 ` Carlo Strozzi
2000-05-08 15:15 Smarasderagd
2000-05-09  8:22 ` Carlo Strozzi
2000-05-08 10:19 Bengt Kleberg
2000-05-06 21:47 Byron Rakitzis
2000-05-04 13:46 Sam Roberts
     [not found] <sroberts@uniserve.com>
2000-04-26 15:02 ` 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
2000-05-08 11:50           ` David Luyer
2000-05-08 13:28           ` Carlo Strozzi

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