ranjit@grad1.cis.upenn.edu (Ranjit Bhatnagar) (09/09/89)
In article <14083@netnews.upenn.edu> I wrote >If you think of a symbolic link as just a way of making a file point >at another file, you miss the more exciting possibilities of the >Amiga's device space. I find it frustrating that an argument about a technical point about links on UNIX can go on for weeks, but nobody is interested in discussing the implications of links in AmigaDOS. This IS comp.sys.AMIGA.tech, isn't it? As I pointed out in the referenced article, the presence of arbitrary gunk in the amigados filespace through the use of handlers makes the symbolic link a very different thing (I'd say 'a more powerful tool' but then everyone would attack) in AmigaDOS than in UNIX. Or it would be if there were one. With handlers, we can stick anything at all into the filesystem as a rooted tree. If you want /dev/kmem you can write a KMEM: handler, what the heck. If you want a virus, write VIRUS:. 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 ln -s UNCOMPRESS:boffo.text.Z boffo.text In my previous article, I took this a step further and proposed an AREXX: handler. All it does is convert its argument into an arexx command whose stdin or stdout is linked to the file handle the handler returns, as appropriate. So now you don't even need to write a new handler to do automatic decompression! Just write ln -s "AREXX:address command uncompress <boffo.text.Z" boffo.text Pretty mind boggling, I think - but I may be wrong, since nobody responded to the previous article except to _correct an error in my UNIX syntax._ Perhaps this is all pie-in-the-sky, because there are no symbolic links in AmigaDOS, and there's no such thing as the arexx: handler. But I'll bet my kickstart disk that there'll be symbolic links in 1.4, and if nobody else is interested in AREXX:, I'll write the handler myself. Meanwhile, here's some more amazing-but-true uses for symbolic links and AREXX: You want an disk whose icon is different each time you reload it? ln -s "AREXX:funnydisk:rexx/dumprandomicon.rexx" funnydisk:disk.info How about a booby-trapped file? Now much easier to write: ln -s "AREXX:address command run <nil: >nil: format dh0: name GOTCHA!" ReadMe How about this: a program which recompiles itself if it's not up to date: ln -s "AREXX:address command 'make <nil: >nil: FooCalc'; address command 'type FooCalc'" AutoFooCalc this one could be done more cleverly, but you get the idea. Talk about hypertext! The very directories on your disk are now as powerful as hypercard scripts, and more dangerous (see booby-trap above). Alright! Let's have some comments. Please? - Ranjit "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... "Such a brute that even his shadow breaks things." (Lorca)
peter@sugar.hackercorp.com (Peter da Silva) (09/10/89)
In article <14187@netnews.upenn.edu>, ranjit@grad1.cis.upenn.edu (Ranjit Bhatnagar) writes: > ln -s "AREXX:address command uncompress <boffo.text.Z" boffo.text I thought of this one, too, but I called it "CLI:". Never implemented it. Don't need to wait for 1.4! Then "AREXX:" becomes a simple enhancement. I thought of a "REXX:", too, but with different semantics. A program would open "REXX:name". Then from AREXX you would say "command name whatever". The next read from that file would return whatever. A minimal AREXX interface as easy as file I/O! -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` "before making up your mind, please read the book." -- sherry.mann "This is contrary to the spirit of rec.arts.sf-lovers" -- Jim Winer
charles@hpcvca.CV.HP.COM (Charles Brown) (09/12/89)
> ... 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. > 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. 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. > Alright! Let's have some comments. Please? > - Ranjit I like some of the possibilities. But on the whole I don't trust others enough to want this on my system. Its like leaving the front door of my house open when I leave. Sure, it would make it easier for the maid to get in to clean up (if I had a maid :-). But it also lets in all kinds of dishonest people. Lets just stick with the idea of regular symbolic links. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer.
new@udel.EDU (09/13/89)
I think the worries about the AREXX: device are unfounded. As I understand the original post, the AREXX: device would be a mounted non-file-system device which would parse the "filename" as a command to be sent to the ARexx resident process. In terms of the symbolic links "parsing" the link name, it would take no more work for AmigaDOS to parse "AREXX:doit.rexx args" than to parse "DF0:doit.rexx args". As far as security goes, either don't mount AREXX: if you are unsure of what you are looking at, lock your hard drive while fiddling around, or (best) issue an RXC command to shut down ARexx while fiddling around. (Obviously best as it is easily reversed without rebooting.) I think the idea of an AREXX: device is great, and very much along the "Amiga way to do things". -- Darren
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (09/13/89)
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.BITNETfilbo@gorn.santa-cruz.ca.us (Bela Lubkin) (09/13/89)
In article <23778@louie.udel.EDU> new@udel.EDU writes: >As far as security goes, either >don't mount AREXX: if you are unsure of what you are looking at, >lock your hard drive while fiddling around, or (best) issue >an RXC command to shut down ARexx while fiddling around. >(Obviously best as it is easily reversed without rebooting.) Perhaps better still: design the AREXX: handler so that the user may specify devices from which it will refuse to run scripts. One could then flag any device which isn't fully under your control -- DFn:, possibly NET: drives, etc. Bela Lubkin * * filbo@gorn.santa-cruz.ca.us CI$: 73047,1112 @ * * ...ucbvax!ucscc!gorn!filbo ^^^ REALLY slow [months] R Pentomino * Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945
pds@quintus.UUCP (Peter Schachte) (09/14/89)
In article <1989Sep13.022711.7311@agate.berkeley.edu> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >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. Gee, I'd expect this to be VERY useful. How about a COMPRESS: device that uncompresses a file as you read it. you could compress all your .h files (important to us floppy-only users) and your C compiler would uncompress as it read. And writing to, say, COMPRESS:DF0:foo.Z would write a compressed file df0:foo.Z. Sounds very useful to me. It would also be nice to have a ZOO: device that handles zoo archives. So instead of doing 1> mkdir df0:foo you could do 1> ln -s zoo:df0:foo.zoo foo and then 1> cp #?.c foo would create a zoo archive of all your .c files, and 1> dir foo would get you a listing of the contents of the archive. There are lots of things like this that would be really useful. How about SCCS: or RCS:? It would be great if all this could be done with just an AREXX: device, with scripts that invoke compress or zoo, but I don't see how the AREXX: device would tell the script it started whether it wanted to read, write, examine, exnext, delete a file, or whatever. But then, I don't know AREXX. Is this possible? -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
ranjit@grad1.cis.upenn.edu (Ranjit Bhatnagar) (09/14/89)
In article <1251@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >It would be great if all this could be done with just an AREXX: device, >with scripts that invoke compress or zoo, but I don't see how the AREXX: >device would tell the script it started whether it wanted to read, >write, examine, exnext, delete a file, or whatever. But then, I don't >know AREXX. Is this possible? Two possibilities (there are probably other better ideas that I didn't think of): 1- if you open AREXX: for writing, then the script gets your process as standard input. If you open it for reading, it gets you as standard output. If you do file functions like examine, delete, etc., you get OPERATION NOT SUPPORTED, just like if you tried to do it do SER: or PRT:. 2- the AREXX: handler creates a logical file for input or output before invoking the script, and the script can choose to use the AREXX: files or the ordinary input/output. call open rxinput "pipe:rx001742" "read" "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... "Such a brute that even his shadow breaks things." (Lorca)
filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (09/15/89)
In article <1989Sep13.022711.7311@agate.berkeley.edu> Mike Meyer writes: >In article <1410031@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: ><This scares me. I am already nervous about sticking unknown disks ><into my Amiga. [deleted] ><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. Whoa there. I'm mainly a CLI user but I often have WorkBench running for certain tasks. You may be a pure CLI user. Let's not forget those who use WorkBench -- probably a large majority of Amiga users, by volume if not by weight ;-}. What happens every time you stick a floppy in a drive, if you've run LoadWB? WorkBench reads disk.info. What happens if disk.info is a booby-trapped link? .... Bela Lubkin * * filbo@gorn.santa-cruz.ca.us CIS: 73047,1112 @ * * ...ucbvax!ucscc!gorn!filbo ^^^ REALLY slow [months] R Pentomino * Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945