Re: [OT] Re: Changing Headers in the Compose screen
* 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, and 936 on a
12-proc system. 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.
> 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.
--
-D. dgc@xxxxxxxxxxxx ** Enterprise Network Servers and Such
** University of Chicago
We are the robots. ** North America's southernmost seasonal glacier