On Sun, Jan 25, 2004 at 10:23:03PM EST, David Champion wrote:
> * On 2004.01.25, in <20040125061915.GQ4197@xxxxxxx>,
> * "David Yitzchak Cohen" <lists+mutt_users@xxxxxxxxxxxxxx> wrote:
> > > > > This means that pretty much every shell is going to
> > > > > overwrite your input file before anyone gets to read it. If anything
> > > > > else happens, it's a scheduler fluke, and certainly not reliable.
> > > > ...
> > > >
> > > > For some reason, having only two cat(1)s doesn't do the trick nearly
> > > > as often, but you'll notice that with three cat(1)s, we get the filter
> > > > executed "in-place" more than 85% of the time - not too bad, eh?
> > >
> > > Your second processor might explain that, somewhat.
> >
> > Do you mind trying the same command on your system, to see what happens?
> > You've got me all curious now. . .
>
> With 1000 iterations of "cat <file | sed | cat | cat | cat >file", I
> get 189 successes on my usual, uniprocessor workstation,
Wow ... that's _really_ low ;-/
> and 936 on a
> 12-proc system.
Now, we're talkin' :-)
> On the 12-proc, I also got 5 cat instances erroring
> out with EFAULT on write(). I'd have to guess that this is to do with
> Solaris's memory-mapped I/O.
weird ... I wonder which write(2) is killing the pipeline. . .
> > Yup, it's a rather neat tool, if you ask me. In a former life, I'd use
> > that as the base for writing a new shell, but since I've discovered a way
> > cool program called CINT [1], I've been hard at work creating libraries
> > to make it usable as a real shell.
>
> I've actually been planning to use pipeline's design as a key feature to
> a new shell for a while, but it's one of those back-burner projects that
> just hasn't gotten off the ground yet. CINT looks interesting. I'm not
> sure whether it's something I'd want to use as a daily shell, but maybe
> that's what your scripts address. I'll have try to watch it. thanks for
> the link.
With the C preprocessor, you can do some rather nifty stuff.
Tab completion means you can start typing a command, and tab out the
rest of it (if all your commands are in a nice big structure, which can
be autosynchronized with the actual binaries in your $PATH on demand):
e.g. cmd.mutt for Mutt. Now, you ask, why the heck would you want to
type "cmd.mutt" when you can just type "mutt" in bash? Well, having to
tell the shell you want to execute a shell command means if you don't,
you can specify other stuff instead, say
print("blah") | cmd.sed("s/blah/goo/")
. Notice that doing the same in bash would require something like
echo -n blah | sed "s/blah/goo/"
and the difference in command length isn't so big anymore. Now, how about
string temp=read_to_eof < file; print(temp) | cmd.sed("s/blah/goo/") > file
instead of
cat < file > file.temp; sed "s/blah/goo/" < file.temp > file; rm -f file
? Suddenly, writing CINT code is only three chars longer than the bash
code (and with clever renaming of print() to echo(), we can make that only
two), and three characters is a rather small price to pay for avoiding a
temporary file. Also, consider the number of processes started by each
method: the CINT version does its first statement without fork(2)ing at
all, and the second one only fork(2)s once in cmd.sed() (presumably -
it could invoke a copy-pasted version of sed in a function instead -
something bash can't dream of doing, but let's assume we haven't bothered
to optimize away any common commands). Now, the bash version, as we
all now know, is going to fork once for the first statement. It's going
to fork again for the second, and it'll then fork a third time for the
third statement. Clearly, writing "shell" scripts for CINT allows you
to do much more complex stuff without having to write real "programs."
Now, for those things where you really really want to use a real shell
for some reason, no problem either:
.!echo blah
My goal, though, is to make my libraries good enough so I never have to
do that in practice. A curious possibility that's always in the back of
my mind is to use a variation on my own interceptor (or an instance of GNU
Screen) to run CINT as the backend and interact with it for me. I'll then
speak shell with it, but I'll be able to call any CINT functionality with
a construction like ~~ maybe, or something like that. (Presumably, ~~
followed by something real would interpret the following thing as CINT,
while ~~ followed by whitespace would toggle between "raw mode" and
"shell mode.") I'll still have the full power of C at my fingertips,
but I'll also have the simplicity of a shell by default. As I said
before, however, I prefer to have the full power of C by default if at all
possible, so my first attempt at libraries is aimed squarely at emulating
common shell language functionality with as few keystrokes as possible.
(That includes some stuff I've been working on to avoid having to use
CINT's shell-like redirection syntax, since it'll get awfully confusing
(and ambiguous in many cases) to mix 'em. The problem is that macros
have some annoying shortcomings, so I'm still working on it. . .)
- Dave
--
Uncle Cosmo, why do they call this a word processor?
It's simple, Skyler. You've seen what food processors do to food, right?
Please visit this link:
http://rotter.net/israel
Attachment:
pgpQTBqDisEAM.pgp
Description: PGP signature