🚀 go-pugleaf

In comp.unix.internals, article <1992Jul26.165838.1278@news.eng.convex.com>,
  tchrist@pixel.convex.COM (Tom Christiansen) writes:
< 
<     $ diff (tail file1) (tail file2)
< 
< which sometimes is implemented using temporary named pipes, or sometimes
< with the /dev/fd stuff if you're lucky enough to have it.  I'm not 
< sure why on systems without either you couldn't use a regular temp file.
< 
End of file. You'd have to wait for both tail processes to finish before you
could start the diff. That doesn't really make sense because you want to wait
for the file to be closed, not for the processes to end. These two conditions
are somewhat unrelated.

You could probably create the temp files, mandatory-lock them, and then 
exec the tail processes. If the diff waits for the lock correctly (that's why
the lock has to be mandatory) you have a workable lockout.

Are there any systems with mandatory locking but without either named
pipes, unix-domain stream sockets, ptys, or ... well, anything else that
could do the job?

< Named pipes also used when someone wants a program to intercept I/O calls,
< allowing a file to produce more interesting output.  This is the case when
< people replace their dot-plan with a pipe, for instance.

Or their .signature. ;-)

< Furthermore, I believe that under both Plan9 and SunOS that you can have a 
< filesystem type that does the right thing, so if people did this:
< 
<     ln -s ~/.plan /plans/$USER
< 
< Then have /plans be a special filesystem type that triggers invocation
< of the right code.
< 
I don't know about SunOS, but Plan 9 can do it.
You don't even need the symlink, just mount your personal signature server
over your home directory.

< What programs would break drastically if we changed the library fopen()
< call to either accept "rx"/"wx" to indicate a popen(), or else for the
< sake of transparency, to have it stat() the file and check for the execute
< bit?  (Should we to do it for open() as well?  Probably.)  Certainly editors
< would prefer the former solution, but most general purpose programs the
< latter one.
< 
Ugh. I'd include almost every development tool. Or take cp for instance --
do you still want to be able to copy executable files?  ;-)

-- 
If you happen to be one of the fretful minority who can do creative work,
never force an idea; you'll abort it if you do. Be patient and you'll give
birth to it when the time is ripe. Learn to wait.
                -- Lazarus Long
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/