[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: es decompression hack



# Define a function that'll allow us to declare that certain commands
# take filearguments (as opposed to, say, commands whose arguments
# are hostnames/IP addresses, like telnet -- boy are we having fun
# now, anyone for DNS-based spelling correction?)

you know, this reminds me a lot of tcsh/zsh command completion,
which is aware the types of arguments to programs, for similar
reasons.  that's not a judgement, that's just an observation.
it's surprising to me how willing i am now to look at ideas i
used to dislike.

as to the specifics of John's suggestions, i agree that the < hack
is inadequate, because you really want to be able to have any file
automatically do the decompression, but you certainly don't want to
make the kernel know rules like
	$file : $file.Z := zcat $file.Z
(adjust notation to taste, of course)  what we really need, of course,
is kernel hooks, similar to the hooks in es, so you can catch calls
to open() rather than just the calls to open in the shell.

of course, this is what the newcastle connection folks did.  they
replaced libc with one that ``knew'' that /../kremvax/etc/passwd
really meant /etc/passwd on host kremvax, well before sun's nfs
or even pjw's v8 rfs.  the only hitch was that you have to recompile
(or at least relink) all your programs so that they would understand
the new notations.  (actually, the main reason i've been so resistant
to ~-expansion in shells is that it's not understood by open(), but
this sort of hack would work for that as well.)

anyway, dynamic libraries make the newcastle trick easier to pull off,
and there were a couple of perfectly awful papers along those lines
at the latest usenix, and at one point i'll have to tell you about my
dwimming nfs file server (it's a bad idea, but that doesn't mean it
doesn't run).  anyway, all these things are possible, and the shell
preparsing command lines and figuring out which applications take
which kind of arguments is one of the possible ways, but it's discussions
like this that make me want something more than unix.

anyway, i've rambled on for too long and am probably getting myself
into trouble...

thank you, John, for a stream of consciousness provoking note,
paul