🚀 go-pugleaf

In article <1410031@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes:
<> ...  Now, if we throw in symbolic links, this gunk
<> can effectively be ANYWHERE in the filesystem.  I can stick a serial
<> port in my devs:keymaps directory if I want just by typing
<> 	ln -s ser: "devs:keymaps/why a serial port?"
<> This isn't just an extension of UNIX links, this is something entirely
<> different, because a handler is user-installable.  In essense, as long
<> as you 'mount' the right things, you can link arbitrary processes to
<> arbitrary filenames.  If you want automatic decompression of a file,
<> just write an uncompress handler and 
<
<I did not respond to your previous posting on this subject.  Frankly
<it was mind boggling.  I was not sure it could be easily implemented
<because it assumes that the symbolic link will not just be followed
<(as happens with such links under Unix) but will be parsed and
<possibly be executed as a program.  This is definely a powerful
<concept.  However I think in this case it is too powerful.

And I didn't respond because it was old hat. The idea of processes
that get invoked to supply data when a file is read has been around
for a long time - long enough to be in the original 4.2BSD design
spec, among other places. For some reason, they don't seem to catch
on. I suspect that they just aren't that usefull.

BTW, Amiga soft links with the AREXX ability could work basically the same
way Unix soft links do: you take the file name the link contains, and
parse it from scratch. It's just that the AmigaDOS filename space lets
the user put arbitrary things into it at the device level.

<> How about a booby-trapped file?  Now much easier to write:
<> 	ln -s "AREXX:address command run <nil: >nil: format dh0: 
<> 	       name GOTCHA!" ReadMe
<
<This scares me.  I am already nervous about sticking unknown disks
<into my Amiga.  But I can protect myself with a few measures:
<  1.  Never boot from a disk I have not Installed.
<  2.  Keep CD and DIR resident so that the C: versions are effectively
<      first on the path.  (This is a frustration I have with c:Path.
<      It should NOT assume I want the current directory first on my
<      path.  In fact I NEVER want the current directory first.)
<  3.  Be selective about who's executables I run.
<With these restrictions I am free to peruse a foreign disk without
<fear of infection.  Generally what I am most interested in is looking
<at sources.

Actually, you probably don't need to change that if this facility
existed. After all, if you saw:

	readme (link to AREXX:address command 'run <nil: >nil: format dh0:')

in a directory listing, would you try and read it? Or how about

	readme (link to AREXX:address command ':scriptfile')

Surely not without reading scriptfile?

<But with your proposal I would no longer be safe to peruse these
<files.  Just LOOKING at a "file" has the possibility of infecting my
<Amiga.  No thanks.

No, you have to _read_ it. Doing a list on it shouldn't do anything
other than tell you that it's a link, and where it points to.

<> Alright!  Let's have some comments.  Please?
<> 	- Ranjit

Ok. AREXX: is overkill, unless you actually use the fact that you're
running ARexx by providing a client for the server. An AREXX: and a
SHELL: device could be used for the same things; you just preface the
AREXX: requests with 'rx' for the SHELL: device, and wrap the SHELL:
quotes and prefix it with "address command" for the AREXX: device.

Of course, if you can provide a client for the ARexx commands so run,
and something usefull for it to do, then you might have something
really new and wonderfull.

	<mike
--
Cheeseburger in paradise                                Mike Meyer
Making the best of every virtue and vice                mwm@berkeley.edu
Worth every damn bit of sacrifice                       ucbvax!mwm
To get a cheeseburger in paradise                       mwm@ucbjade.BITNET