Path: utzoo!utgpu!water!watmath!watcgl!watsol!bmacintyre
From: bmacintyre@watsol.waterloo.edu (Blair MacIntyre)
Newsgroups: comp.sys.amiga
Subject: PATH: device
Keywords: path, help
Message-ID: <3827@watcgl.waterloo.edu>
Date: 31 Mar 88 18:50:54 GMT
Sender: daemon@watcgl.waterloo.edu
Reply-To: bmacintyre@watsol.waterloo.edu (Blair MacIntyre)
Distribution: world
Organization: Centre for the OED, 2nd Edition
Lines: 56

< Eat Hot Death, LineEater >

A couple of days ago I read an article about creating a PATH: device and
using it to implement paths.  There has been no more talk about it and, since
I would like to try to write one, but I don't really know anything about
DOS devices ... I've looked at the PIPE: device, and thus the coding part
seems straight forward enough.  I'm just not sure what kind of messages the
device would receive for certain actions.  For example, when I do a DIR 
command, what kind of packets does dir send to WHERE?  I realize that
I'm probably being obtuse, but if anyone out there ( at CATS for example )
could give me a little tutorial on the subject, I'd really appreciate it.

By the way, I have the original (?) AmigaDOS Technical Reference and have
read the info on DOS packets, etc.  I'm just not sure who sends what where,
and how I would handle the packets, etc.

To be more specific: say I have a 'file' PATH:c which 'contains'
  . vd0:c ram:c sys:c  
and I get a "open path:c/fred" command, well I want to look, in order, for
. (current dir)/fred, vd0:c/fred, ram:c/fred and sys:c/fred.

So, where do I 'pass through' the packets do this action.  This is the
majority of what the actions in this device would do.

Also, I'm not quite sure what to return as filehandles and locks on 'files'
for this device ... ( I'm going to look into this a bit more )

Finally, here are some ideas I have for the device:
- as the originator of this idea suggested, I'll write an addpath command
  with options to manipulate the PATH: file ( through special packets, or
  perhaps using read, write, seek packets ).
- various special meaning can be used in the path:
  .   - current dir 
  [dxx]: - any device that is specified (via the program) with its name in
        square brackets can be taken to be that device, not what is mounted
        on it currently ( ie. search whatever disk is in [DF1]: when the path
        is used )  This could cause problems during use, except when
        combined with the next option
  (xxx) - by surrounding a path (directory, actually) name in parenthesis,
        this could mean "search if it exists", so ([DF1]:c) would mean search
        the c directory on the disk in df1:, if it has one.


These are just some suggestions ... any comments?  I really think I could
write this if I just knew a bit more ( I want something to write in my spare
time, and this is a reasonable project ... )

HELP! ( please :-)

Blair

--
===========================================================================///=
Blair MacIntyre (bmacintyre@watsol.waterloo.edu) ( Long live the Amiga!! )///
"Violence is the last resort of the incompetent" - Issac Asimov       \\\///
=Have you hugged your dragon today??=(how about your SO??)=============\XX/====