rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* Re: redirection and built-ins
@ 1993-06-07  5:23 Alan Watson
  0 siblings, 0 replies; 7+ messages in thread
From: Alan Watson @ 1993-06-07  5:23 UTC (permalink / raw)
  To: Paul Haahr; +Cc: rc

| ``echo ... | read foo'' is not the appropriate construct in rc or es.

Yeah, because it doesn't work; there is nothing intrinsicly
`inappropriate' about it.  I hadn't realised there was a lexicon of
politically correct idioms in rc, but clearly I have been badly
misinformed...

| read hasn't made it to either of these shells yet.  why are we talking
| about modifying fundamental parts of these shells to support inappropriate
| uses of (as-yet) unimplemented operations?

Sorry, I didn't actually mean to imply that read should be a built-in,
and I was actually thinking of a functionally-implemented read.  When
I mentioned rc forking to provide redirection for built-ins, I was
also thinking about functions, but it was sloppy writing on my part.


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

* Re: redirection and built-ins
@ 1993-06-07 17:10 Alan Watson
  0 siblings, 0 replies; 7+ messages in thread
From: Alan Watson @ 1993-06-07 17:10 UTC (permalink / raw)
  To: Paul Haahr; +Cc: rc

Paul writes:
> it's inappropriate because rc already has a perfectly good
> mechanism for setting variables to the output of commands:  backquotes.
> why is that not enough?  what functionality does that lack?

Oh, the ability to encapsulate the process in a function (yes, I know
that in es one could pass a program fragment, but this is the rc-list
after all), and an easy way to get at the return value (yes, I know
that may be fixed in a later version, but I'd still rather hide the
grubby details in a function).

> what does this mean?  (``functionally-implemented''?  that it works?
> that it doesn't have side effects?)

It means `implemented as a function'.

> the mechanism we came up with for doing this [redirection on 
> built-ins without forking] in
> es could be applied to rc just fine, but it seems like a lot of
> work for very little payoff.

Fine.  I'm prepared to accept that answer; as I said in my original
message, I'm only interested in exploring the possibilities, and I am
not campaigning for either of these changes.  I'm not concerned about
the performance aspects, only the functionality.

> what should happen if the command is
> 	exit 1 | exit 2 | exit 3
> ?  

There will always be pathological cases: even now, if you have an exit
in a function and run it with and without redirection, different things
happen.  I haven't heard of anyone losing any sleep about it.


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

* Re: redirection and built-ins
@ 1993-06-07 15:24 Paul Haahr
  0 siblings, 0 replies; 7+ messages in thread
From: Paul Haahr @ 1993-06-07 15:24 UTC (permalink / raw)
  To: rc

Alan writes:
> | ``echo ... | read foo'' is not the appropriate construct in rc or es.

> Yeah, because it doesn't work; there is nothing intrinsicly
> `inappropriate' about it.

i disagree.  it's inappropriate because rc already has a perfectly good
mechanism for setting variables to the output of commands:  backquotes.
why is that not enough?  what functionality does that lack?

i don't think that the goal in rc was to provide a million different
syntaxes for the same operation.

> and I was actually thinking of a functionally-implemented read.

what does this mean?  (``functionally-implemented''?  that it works?
that it doesn't have side effects?)

> When
> I mentioned rc forking to provide redirection for built-ins, I was
> also thinking about functions, but it was sloppy writing on my part.

as far as i can tell, there are two issues here:

	(1) rc forks for all redirection operations, even ones which
	    are applied to builtins and shell functions.

	(2) rc and es fork a child process for each component of a
	    pipeline, even if some of the components are builtins
	    or functions.

(1) is handled differently in es, and seems to work ok.  in my
mind, it's a performance hack, and not a very good one, because
from the bit of profiling that i've done it doesn't make that much
of a difference.  the mechanism we came up with for doing this in
es could be applied to rc just fine, but it seems like a lot of
work for very little payoff.

(2), i think, is the right thing, because it's the only symmetric
answer.  in the pipeline
	a | b | c
if all a, b, and c are shell functions, which one should run in
the context of the shell?  what should happen if the command is
	exit 1 | exit 2 | exit 3
?  i prefer the current rc/es answer which is:  the shell does
not exit, and the return status is (1 2 3).  i believe that in
Tom Duff's verion, the top-level shell exits with either 1 or 3,
and Alan seems to argue that 3 is the right answer.

paul


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

* Re: redirection and built-ins
@ 1993-06-07  0:32 Paul Haahr
  0 siblings, 0 replies; 7+ messages in thread
From: Paul Haahr @ 1993-06-07  0:32 UTC (permalink / raw)
  To: alan; +Cc: rc

> I suspect that the traditional implementation stems from the lack of
> redirection on built-ins in the orginal shell, but I could be wrong.

i don't think so.  it's the clearest and simplest implementation, and
has completely obvious semantics.

``echo ... | read foo'' is not the appropriate construct in rc or es.
the *right* way to that in one of these shells is

	foo = `{ echo ... }

or

	foo = `` () { echo ... | { read foo | echo -n $foo } }

if you really want read semantics.

read hasn't made it to either of these shells yet.  why are we talking
about modifying fundamental parts of these shells to support inappropriate
uses of (as-yet) unimplemented operations?

paul


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

* Re: redirection and built-ins
@ 1993-06-05 18:59 Alan Watson
  0 siblings, 0 replies; 7+ messages in thread
From: Alan Watson @ 1993-06-05 18:59 UTC (permalink / raw)
  To: Paul Haahr; +Cc: rc

I suspect that the traditional implementation stems from the lack of
redirection on built-ins in the orginal shell, but I could be wrong.
Binding would matter the implementation of a pipeline avoided
unnecessary forks (my order of binding would mean that the read rather
than the echo was run in the current shell).


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

* Re:  redirection and built-ins
@ 1993-06-05 18:45 Paul Haahr
  0 siblings, 0 replies; 7+ messages in thread
From: Paul Haahr @ 1993-06-05 18:45 UTC (permalink / raw)
  To: alan; +Cc: rc

> At the moment,
> 	echo bar | read foo
> is a widely known failing of sh, but with these two changes it would
> work in rc.

the issue is not bindings of pipes, but when pipe forks.  in rc and es,
(though, i've heard, not in Tom Duff's rc) all components of pipelines
are run in child processes.  this is, imho, the cleanest model.  i would
be very upset to see it change.

paul


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

* redirection and built-ins
@ 1993-06-05 18:38 Alan Watson
  0 siblings, 0 replies; 7+ messages in thread
From: Alan Watson @ 1993-06-05 18:38 UTC (permalink / raw)
  To: rc

If rc were able to perform redirected built-in commands without
forking, like a modern sh and es, would it be beneficial to change the
grammar of a pipe to bind more closely to the right, rather than the
left?

At the moment,

	echo bar | read foo

is a widely known failing of sh, but with these two changes it would
work in rc.

This is not a serious suggestion; I'm just interested exploring the
design of rc.


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

end of thread, other threads:[~1993-06-07 17:10 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1993-06-07  5:23 redirection and built-ins Alan Watson
  -- strict thread matches above, loose matches on Subject: below --
1993-06-07 17:10 Alan Watson
1993-06-07 15:24 Paul Haahr
1993-06-07  0:32 Paul Haahr
1993-06-05 18:59 Alan Watson
1993-06-05 18:45 Paul Haahr
1993-06-05 18:38 Alan Watson

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