rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* Re: forking builtins
@ 1993-09-24 21:19 Tom Culliton x2278
  0 siblings, 0 replies; 5+ messages in thread
From: Tom Culliton x2278 @ 1993-09-24 21:19 UTC (permalink / raw)
  To: rc

While this discussion about forking builtin's to do redirection is all
well and good, it seems like a fairly odd way to use read.  As I've said
in the past, the reasons you would usually use read are to:

1) Get a single line of input from a user.  In this case performance
isn't an issue and the user is presumably talking to fd 0 and there's no
problem.  (There may be a case for using /dev/tty but performance still
isn't going to be an issue.)  For example:

	echo -n 'Where do you want logfile written? '
	read logfilename

2) Chewing through a whole input stream or datafile.  In this case
performance is an issue but since the data is presented as a stream
presumably on fd 0 and again there's no problem.  For example:

	here = `pwd { find . -type d -print | while (read dirname) {
	 if (cd $here/$dirname) ls -l >.contents }}

I can only think of one case where you might do something like (get only
the first line of a file):

	read bgcolor <.background

and in that case you'd be crazy to do it more than once, so again
performance shouldn't be an issue.

Tom


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

* Re: forking builtins
@ 1993-09-24 16:40 Alan Watson
  0 siblings, 0 replies; 5+ messages in thread
From: Alan Watson @ 1993-09-24 16:40 UTC (permalink / raw)
  To: rc

Of the suggestions I have seen so far, Malte's `line is clearly the
suggestion most in line with the rc philosophy.  However, it isn't
going to satisfy the performance demands (needs?) of many people.

At first glance a builtin read will be no faster than line because of
the way rc handles the redirection of builtins.  However, all one needs
to do is the following:

	exec <file
	while (read LINE) {
		...
	}

The same trick can be used with whatis -s.

The only impediment is choice of a fd on which to save stdin/stdout.
Anyone for adding $newfd to rc?

I can support the following course of action:

(a) add Malte's builtin line and rewrite UNIX so that fork is fast.

(b) add builtin read and rewrite rc's redirection on builtins.

(c) add builtin read and add $newfd to allow stdin/stdout to be safely moved.

(d) doing nothing rather than doing a half-baked job.

I favour (c), as it seems the most return for the least effort, but I
appreciate the attraction of (d).  rc is about as perfect as one could
hope, and meddling with near perfection is dangerous.

And, yes, a hypothetical read MUST do IFS splitting but should only
take one argument -- we have lists, let's use them.  The only question
is whether it should also allow one to specify the character which
terminates a record (IRT -- internal record terminator?).  I will even
promise to write a version which does this before the end of October.

And now, back to work.

Alan.


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

* Re: forking builtins
@ 1993-09-24  0:03 Tom Culliton x2278
  0 siblings, 0 replies; 5+ messages in thread
From: Tom Culliton x2278 @ 1993-09-24  0:03 UTC (permalink / raw)
  To: arnold, haahr; +Cc: rc

> >i am not advocating that byron rework rc or anything like that. except for
> >read, it's not a major problem with the other builtiins, i'm just remarking
> >upon it.
> 
> echo could also use it.

It would also make "whatis -s >handlers" work! :-)  Right now thats the
only glitch in being able to capture your current environment.

Tom


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

* Re: forking builtins
@ 1993-09-23 22:02 Paul Haahr
  0 siblings, 0 replies; 5+ messages in thread
From: Paul Haahr @ 1993-09-23 22:02 UTC (permalink / raw)
  To: Arnold Robbins; +Cc: rc

>althouh i'm sure to be flamed for mentioning the name 'ksh', much of that
>shell's performance comes from strenous effort to avoid forking of builtins
>upon redirection.

it's not that hard conceptually, it just takes some effort to make sure
you catch every reference to file descriptors.  Byron and i came up with
a strategy for es that works.  see es's fd.c for details.

but strenuous it is not.

>i am not advocating that byron rework rc or anything like that. except for
>read, it's not a major problem with the other builtiins, i'm just remarking
>upon it.

echo could also use it.



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

* forking builtins
@ 1993-09-23 18:57 Arnold Robbins
  0 siblings, 0 replies; 5+ messages in thread
From: Arnold Robbins @ 1993-09-23 18:57 UTC (permalink / raw)
  To: rc

althouh i'm sure to be flamed for mentioning the name 'ksh', much of that
shell's performance comes from strenous effort to avoid forking of builtins
upon redirection.

i am not advocating that byron rework rc or anything like that. except for
read, it's not a major problem with the other builtiins, i'm just remarking
upon it.


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

end of thread, other threads:[~1993-09-24 22:00 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1993-09-24 21:19 forking builtins Tom Culliton x2278
  -- strict thread matches above, loose matches on Subject: below --
1993-09-24 16:40 Alan Watson
1993-09-24  0:03 Tom Culliton x2278
1993-09-23 22:02 Paul Haahr
1993-09-23 18:57 Arnold Robbins

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