bmacintyre@watsol.waterloo.edu (Blair MacIntyre) (04/01/88)
In article <871@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >But I have been convinced that the behaviour should be: > >1> mount PATH: >1> Assign C: PATH:df0:c!df1:c!ram:c Actually, I prefer the 1> addpath PATH:c df0:c df1:c ram:c for one reason: with that above scheme, aren't you limited to having paths only as long as amigados filenames? Also, another article I posted today for a few variations on the possible path elements ... >1> list c: >Directory "c:" on Thursday 23-Mar-00 >Run 2324 rwed Future 14:18:53 >Fault 2728 rwed Future 14:18:54 >Install 1800 rwed Future 14:18:55 >stack 296 rwed Future 14:18:55 >... <contents of df0:c>... >More 8640 rwed Future 14:21:28 >viewilbm 11472 rwed Future 14:21:30 >disksalv 12796 rwed Future 14:21:33 >unshar 9884 rwed Future 14:21:35 >dmp 8008 rwed Future 14:21:36 >... <contents of df1:c>... >c:copy 8128 rwed Future 14:19:14 >c:cd 496 rwed Future 14:19:17 >c:list 8440 rwed Future 14:19:16 >... <contents of ram:c>... >247 files - 2700 blocks used Exactly the way it should work! :-) >1> assign >... >c PATH:df0:c!df1:c!ram:c or c PATH:c >1> Assign include: PATH:df0:include!vd0:include!Aztec:include As above, 1> setpath PATH:include df0:include vd0:include Axtec:include 1> assign include PATH:include >1> set INCLUDE=include: > >Let's go back and look at your problems in context of this variant... > >> What happens when someone opens c:filename for write if a) it exists in one >> of the directories, b) exists in more than one, c) exists in none? > >The safest thing would still be to refuse the packet, and have open return >an error, just as if it was a read-only file system. I think I agree with this ... to dangerous: say you have a source path so that the compiler uses your modified files first, then the 'originals'. If you delete the 'modified' file twice, you could mess yourself up ... >> What does one get back when one Examine()s the result of Lock("c:",...)? >> Or when one ExNext()s it? > >Examine returns something that looks like a directory. ExNext returns each >file in turn. Really, it behaves much like Matt Dillon's sample RAM: driver. Hmmm ... where can I get the RAM: driver source ( or is it possible )? ---------------------- In another article, someone suggested some things about the PATH: driver using an AREXX port for communication, etc ... I think this is getting to complicated. The device should simply be a read-read-only file system ( a suggested above ) which allows multiple paths to be scanned together. The article did mention some important concerns, such as making sure that the same filename is not returned more than once, etc. The are definately important points. But as for all this added complication, why bother? In this case, the KISS principle is very appropriate... :-) -- ===========================================================================///= 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/====
bts@sas.UUCP (Brian T. Schellenberger) (04/07/88)
You don't want the path to require an "addpath" because you want this path-
style device to work the same for all possible assignments. On the other
hand, the objection to "assign" that it limits you AmigaDOS path sizes seems
legitimate, so why not just do paths like ENV: (or even get them out of env:?):
assign c: path:c
echo > path:c "vdk:c, df0:system, df0:utilities, !df0:c"
(the `!' to indicate that this is where a file should be added if the user
attempts to create a file in c:).
Of course, if this is all that the mythical "addpath" command does, fine.
But I, for one, like the property of the "env"-type approach that allows all
my traditional file-maninpulation tools to work on the environments/paths/&c.
--
--Brian.
(Brian T. Schellenberger) ...!mcnc!rti!sas!bts
PET PEEVE: remember to keep included text small for us 1200-bauders . . .