* 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
* 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
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-23 18:57 forking builtins Arnold Robbins
1993-09-23 22:02 Paul Haahr
1993-09-24 0:03 Tom Culliton x2278
1993-09-24 16:40 Alan Watson
1993-09-24 21:19 Tom Culliton x2278
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).