rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* Re: Another vote for a built-in read function
@ 1993-09-19 19:59 Tom Culliton x2278
  1993-09-20  2:44 ` Scott Schwartz
  0 siblings, 1 reply; 7+ messages in thread
From: Tom Culliton x2278 @ 1993-09-19 19:59 UTC (permalink / raw)
  To: rc, schwartz

> | Boyd's famous comment that a shell should run commands not have them
> | built into it.
> 
> Well, just to throw some oil on the fire, check out alt.os.multics for
> some relevent and incisive thoughts on this topic.

I suspect that there are a lot of us without easy access to that news
group.  (or just too busy to look)  Could you summarize for us?  Or at
least indicate which way the discussion was leaning?

Tom


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

* Re: Another vote for a built-in read function
  1993-09-19 19:59 Another vote for a built-in read function Tom Culliton x2278
@ 1993-09-20  2:44 ` Scott Schwartz
  0 siblings, 0 replies; 7+ messages in thread
From: Scott Schwartz @ 1993-09-20  2:44 UTC (permalink / raw)
  To: Tom Culliton x2278; +Cc: rc


| I suspect that there are a lot of us without easy access to that news
| group.  (or just too busy to look)  Could you summarize for us?  Or at
| least indicate which way the discussion was leaning?

Sure. There are two basic points, which I'll try to explain as best I
can given that I've only read about multics, but used some of its
descendants (prime's primos and apollo's domain).

One is that multics has pervasive dynamic linking.  The fundamental unit
of sharing is the procedure.  Any procedure in any file in your search
path can be called at any time.  Your environment is one big process,
you don't fork to run programs, you just call their entry points as
subroutines.

The second is that there is a convention of using "active functions" in
the command language.  That means that commands see of they are being
called interactively, in which case they print their output, or being
called as subroutines, in which case they pass their output back by
returning a pointer to a buffer.

The upshot is that in multics, if you have a command to read a line
named >bin>line, and >bin is in your search path, you can call it from
your program by calling a routine named line_ and it will be exactly as
if it were a "builtin", because it is.

There was an interesting discussion between Peter da Silva and Olin
Sibert over the find command.  Olin pointed out that ``find ... -exec
...'' is more multics-like than unix-like, but unix has to use xargs as
yet another performance hack, with concomitant correctness problems. 

I can post Olin's whole article or forward it to anyone who's
interested.  

(As an aside, the word "glob" in unix comes from a command in multics
named "global", making it more like globbing in zsh.)

In my view, and the reason I brought this up at all, a real problem in
Unix, and in posix like systems, is that the unit of sharing is wrong.
The best you can do is write text down pipes to forked processes.
Sometimes that is fine, but very often it is not enough, or just plain
wrong, and the rc community has encountered a perfect example of this.
Similar issues came up in comp.lang.tcl a while back.  In a unix
setting, having a language primative for doing dynamic loading is about
the best compromise you can achieve.

And now for a diatribe; please skip to the end if I'm annoying you. :-)
This wrongness is very bad because it distorts programmers ideas of what
should be reusable; in the end, nothing is.  Consider, why does ftp have
its own subroutine for doing globbing?  I mean, if you can't just call
the globbing routine in the shell, why can't you at least use the same
damn library routine?  There isn't any!  You don't need system sources
to get it right, just a libsh.a with a sensible api!  (The latter is
complicated by the fact that we insist on using a '70s vintage
programming language that has basically no support for code reuse, and
still manages to be an improvement over its "successor".)



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

* Re: Another vote for a built-in read function
  1993-09-17 19:29 Tom Culliton x2278
@ 1993-09-17 23:18 ` Scott Schwartz
  0 siblings, 0 replies; 7+ messages in thread
From: Scott Schwartz @ 1993-09-17 23:18 UTC (permalink / raw)
  To: rc

| Boyd's famous comment that a shell should run commands not have them
| built into it.

Well, just to throw some oil on the fire, check out alt.os.multics for
some relevent and incisive thoughts on this topic.  



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

* Re: Another vote for a built-in read function
@ 1993-09-17 19:29 Tom Culliton x2278
  1993-09-17 23:18 ` Scott Schwartz
  0 siblings, 1 reply; 7+ messages in thread
From: Tom Culliton x2278 @ 1993-09-17 19:29 UTC (permalink / raw)
  To: rc

I'm for adding builtin read, even if it's just to cut down on the amount
of discussion here about adding it as builtin, and/or how to implement a
read function. ;-) ;-) ;-)

On a more serious note, I tend to flip-flop on whether read should be
builtin or not.  It's definitely the strongest contender of all the
proposals that have been made, but at the moment I lean towards the
"Not" side.  My current thinking is along the lines of, "rc is supposed
to be a shell, not a text filter", which seems at least as compelling as
Boyd's famous comment that a shell should run commands not have them
built into it.

Tom


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

* Re: Another vote for a built-in read function
@ 1993-09-17 18:17 gjv%atlas%cesar
  0 siblings, 0 replies; 7+ messages in thread
From: gjv%atlas%cesar @ 1993-09-17 18:17 UTC (permalink / raw)
  To: rc%hawkwind.utcs.toronto.edu%m_internet%m_mailnow%hermes.DECnet


 |The last thing rc needs is MORE quoting. One of the core design features
 |is that the quoting rules are simple, regular, predictable, and minimal;
 |adding \ as another quoting operator is none of the above.

It remains simple and predictable, it's just not minimal anymore.
But since it is actually a question of convenience, I could think about
other solutions (e.g. automatic quoting of '=' and '#' in readline(),
if I'm really desperate :)

 |                                                           If we're going
 |to make any changes to quoting, we should remove \'s special magic at the
 |end of lines.

Well, at least it would be consistent. More or less assuming that the
backslash won't make it, it is worth considering.

But what about a builtin read function ?

	Gert-Jan

---------------------------------------------------
J.G. Vons   E-Mail: vons@cesar.crbca1.sinet.slb.com


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

* Re: Another vote for a built-in read function
  1993-09-17 13:10 gjv%atlas%cesar
@ 1993-09-17 16:58 ` Chris Siebenmann
  0 siblings, 0 replies; 7+ messages in thread
From: Chris Siebenmann @ 1993-09-17 16:58 UTC (permalink / raw)
  To: rc

 The last thing rc needs is MORE quoting. One of the core design features
is that the quoting rules are simple, regular, predictable, and minimal;
adding \ as another quoting operator is none of the above. If we're going
to make any changes to quoting, we should remove \'s special magic at the
end of lines.

	- cks


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

* Another vote for a built-in read function
@ 1993-09-17 13:10 gjv%atlas%cesar
  1993-09-17 16:58 ` Chris Siebenmann
  0 siblings, 1 reply; 7+ messages in thread
From: gjv%atlas%cesar @ 1993-09-17 13:10 UTC (permalink / raw)
  To: rc%hawkwind.utcs.toronto.edu%m_internet%m_mailnow%hermes.DECnet


Hello all,

When processing text files in sh scripts, I often use something like
the following:

    while read a		<some multistage pipe> | while read a b
    do			or	do
    # some sh stuff		# some sh stuff
    done < /some/file		done

This works fine, but how do you do something like that in rc ?  It works
if you write (don't care about the tab-char for the moment):

    ifs=($nl) {
        for(line in `{cat /some/file})
        {
	    ifs=(' ' $nl) eval 'word=('$line')'
	    a=$word(1) b=$word(2)
	    # do rc stuff
        }
    }

	    or

    while (read line)    # using the read function from the FAQ
    {
        eval 'word=('$line')'
	a=$word(1) b=$word(2)
        # do rc stuff
    } < /some/file

IMHO, having to fork&exec a cat to read from a file is a sad thing, not
to mention the ugly hack to get at the words. The second one with the read
is simply terribly slow, about a 100 times slower than a similar sh script.

Can't we just add a builtin read which uses the $ifs when converting
the input line to a list ?

Something like

    echo a b | {read words; echo $#words ; echo $words(1); echo $words(2) }

would give
	2
	a
	b

Of course I could write a function for this, but that basically means
that the ugly hack is moved elsewhere.

And another thing, just try 'read lines' with the read function from
the FAQ. It returns an empty string because there is a private variable
with the same name inside the read function. This means that you must
always be aware of what is going inside the read().

It is not just speed here, there is some simplicity and/or elegance
involved as well. Same as the builtin echo, you know what it does, no
problems with external bsd/sysv echo differences, \-escapes and all that.
And the speed is a nice extra of course.

What do you al think of this ?

	Gert-Jan

PS: I think that a \-escape would be a good idea too. We have some
    company tools here that usually have an '=' in the argument list,
    while others (and lpr as well) use the '-# <number>'. Putting these
    chars between quotes works of course, but simply prefixing them with
    a \ is much simpler/nicer.
    And don't forget that the \ is already in use in order to escape a
    newline, so it is not completely new anyway. It is just confusing
    when you know about the backslash mechanism, in rc it continues to
    work at end-of-line but stops doing so in other cases.

---------------------------------------------------
J.G. Vons   E-Mail: vons@cesar.crbca1.sinet.slb.com


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

end of thread, other threads:[~1993-09-20  2:45 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1993-09-19 19:59 Another vote for a built-in read function Tom Culliton x2278
1993-09-20  2:44 ` Scott Schwartz
  -- strict thread matches above, loose matches on Subject: below --
1993-09-17 19:29 Tom Culliton x2278
1993-09-17 23:18 ` Scott Schwartz
1993-09-17 18:17 gjv%atlas%cesar
1993-09-17 13:10 gjv%atlas%cesar
1993-09-17 16:58 ` Chris Siebenmann

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