Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!nbires!isis!aburt
From: aburt@isis.UUCP (Andrew Burt)
Newsgroups: net.unix-wizards
Subject: Re: comm '! sort file1' '! sort file2'
Message-ID: <1041@isis.UUCP>
Date: Wed, 24-Sep-86 10:00:27 EDT
Article-I.D.: isis.1041
Posted: Wed Sep 24 10:00:27 1986
Date-Received: Thu, 25-Sep-86 05:04:08 EDT
References: <6846@elsie.UUCP>
Reply-To: aburt@isis.UUCP (Andrew Burt)
Organization: University of Denver Math and Computer Science
Lines: 37

Rather than play with the functionality of fopen to allow for "!cmd..."
as an argument and popen it, as suggested, how about the traditional
shell script approach:

	% cat .../bin/cmd
	eval "$@" "> /tmp/cmd$$"
	echo /tmp/cmd$$
	% comm `cmd sort file1...` `cmd sort file2...`

The main flaw is that it can't know when you're done to remove the
tmp files.

On the original note, though, of modifying fopen: boo! hiss!  Some
programs do direct open(2)'s, meaning not every command could be expected
to handle the !cmd syntax.  Shades of MS-DOS and the wildcards that
not every program can handle...

And restricting the meaning of ! as a first character in a filename
at the kernel level doesn't seem true to the Unix spirit (besides which
the kernel shouldn't have to decided if you want to "csh -c" it or "sh -c"
it).

Perhaps a whimsical solution would be a new file type: when opened via
open(2) the kernel runs the command the file has as its contents.
A few syscalls to manipulate it as text (to get the commands into and
out of the file) and we're set.  Call 'em "run" files.

The 'cmd' program above would then set the command given as $* into
such a "run" file then return the name as it does.  (A "remove on close"
flag set by the special "run" file syscalls would also alleviate the
problem of the file persisting after the command finishes.  Even without
this flag, the "run" file would probably be much smaller than the tmp
files left by my 'cmd' program above.)
-- 

Andrew Burt
isis!aburt   or   aburt@udenver.csnet