lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/24/89)
[Devil's Avocado for the line eater] In <624@tardis.Tymnet.COM>, jms@tardis.Tymnet.COM (Joe Smith) writes: >Here's a suggestion that would make toolpath unnecessary. It's an idea that >is at least 12 years old on TOPS-10 that MS-DOS has only recently >implemented. (And Unix doesn't have yet, as far as I know.) > >The idea is to have a directory (or list of directories) to be searched >if a file is openned for input and not found in the current default >directory. TOPS-10 called this the LIB PPN and/or the LIB: pathological >device. MS-DOS 3.20 calls it the APPEND command. (I don't like that name.) Is this A Good Thing or has April Fool's day come twice this year? Aren't naming conflicts a problem if for no other reason than that your data file names must then be unique within any given 'LIB PATH'? If an explicit path is given as a file name, wheter it be absolute or relative, by physical or logical device, does it really make sense to assume that a file found via a path can be written over or appended to? Yow! >The major difference between this idea and the current PATH is that PATH is >for command/script files only, implemented in the CLI/SHELL, whereas the >extended default directory would be implemented in the OS, available to >all programs for any type of file. We have much the same functionality now, with the system-assigned directories. Libraries are searched for in LIBS:, handlers in L:, environment files in ENV:, and so forth. For general data files, programs can pretty well count on the existence of S:, T:, and so on. Programs that are interested in a file can look in currentdir and in any system-supplied directory, leaving the choice up to the user as to where it is. I can't see this as being something the OS should get involved with. File names tend to be hard coded into programs, and unless there is some sort of 'registration' for them, you are bound to run across conflicts, which on the Amiga can be handled quite nicely, with less chance of losing that config file you just spent an hour setting up. >TOPS-10 has options as to what to do if the file is not found in the current >directory but does exist in one of the alternate directories. They are: > Open for Default Alternate > ------- ------------- ---------------- > reading return file found return "file not found" > writing create new file supersede existing file > update return error update file in other directory >The other directories were searched whenever an attempt to lookup a file >failed, even when an explicit directory path was provided on the open call. >In Amiga terms, this would include attempts to find files in L:, DEVS:, and >FONTS:, if desired. > >Workbench would benefit from this, by having a list of directories to search >when locating the default tool when double-clicking an icon. Wouldn't this be best implemented in the icon's INFO fields? I have always wanted to have icons point anywhere I want them to point, for tools and projects alike, but I want to be the one to point them there. When I click on an icon for a doc file, I don't want it to find the first README it comes across if I have deleted or renamed the README I really wanted, by accident or otherwise. I want it to tell me the file isn't there. Always. >What I am asking for would need to be integrated into the OS, not tacked on >like the PATH: pseudo device. And, since a program could be loaded from >any one of many directories, the OS would need to provide a call that would >return the full path name of where the executable was really found. Aha! A glimmer of hope here.... in this, you seem to be saying that one of the directories in the LIB PATH would be the directory the application resides in. I think this might be A Good Thing. Sort of an 'alternate current dir'... can't see much wrong with it, and it would provide a nice way to keep things separated without having to CD to a particular directory, and to reduce problems of naming conflicts. >Ending on a humorous note, I can say "the other guys have it, we want it too!" In that same spirit, I will ask you the same question my mother used to when I said something like that. "If the other guys jumped off a cliff, would you want to jump off it too?" -larry -- The Mac? Oh, that's just like a computer, only slower. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jms@tardis.Tymnet.COM (Joe Smith) (09/25/89)
Here's a suggestion that would make toolpath unnecessary. It's an idea that
is at least 12 years old on TOPS-10 that MS-DOS has only recently
implemented. (And Unix doesn't have yet, as far as I know.)
The idea is to have a directory (or list of directories) to be searched
if a file is openned for input and not found in the current default
directory. TOPS-10 called this the LIB PPN and/or the LIB: pathological
device. MS-DOS 3.20 calls it the APPEND command. (I don't like that name.)
The major difference between this idea and the current PATH is that PATH is
for command/script files only, implemented in the CLI/SHELL, whereas the
extended default directory would be implemented in the OS, available to
all programs for any type of file.
TOPS-10 has options as to what to do if the file is not found in the current
directory but does exist in one of the alternate directories. They are:
Open for Default Alternate
------- ------------- ----------------
reading return file found return "file not found"
writing create new file supersede existing file
update return error update file in other directory
The other directories were searched whenever an attempt to lookup a file
failed, even when an explicit directory path was provided on the open call.
In Amiga terms, this would include attempts to find files in L:, DEVS:, and
FONTS:, if desired.
Workbench would benefit from this, by having a list of directories to search
when locating the default tool when double-clicking an icon.
What I am asking for would need to be integrated into the OS, not tacked on
like the PATH: pseudo device. And, since a program could be loaded from
any one of many directories, the OS would need to provide a call that would
return the full path name of where the executable was really found.
Ending on a humorous note, I can say "the other guys have it, we want it too!"
--
Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com
McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P,"
San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"usenet@cps3xx.UUCP (Usenet file owner) (09/25/89)
In article <624@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: > >The idea is to have a directory (or list of directories) to be searched >if a file is openned for input and not found in the current default >directory. TOPS-10 called this the LIB PPN and/or the LIB: pathological >device. MS-DOS 3.20 calls it the APPEND command. (I don't like that name.) It would be nice if this happened automatically, at least for workbench. This would eliminate the problem of projects not finding their tools becuase the tool was moved. It could be added to a disks .info file. It would also greatly simplify installing new programs by eliminating the need to move L: and LIBS: and DEVS: files to a central place. REAL NAME: Joe Porkka jap@frith.egr.msu.edu
new@udel.EDU (09/25/89)
Actually, I thought it was kind of elegant how the Mac works/worked this: The FINDER (which includes the COPY command and the Execute() call, both) keeps track in a separate file of where the tool for each icon gets copied to. A neat idea, completely unworkable on the Amiga. Maybe something like that could at least be added to Workbench, maybe as an option. How about a command that runs through all the .info files on a disk and fixes the default tool entry to have the right info? That seems easy enuf. -- Darren
glamdrng@pnet51.orb.mn.org (Rocky Lhotka) (09/27/89)
While the argv[0] as it stands serves a function, I do feel that it is
important for a program to determine from where it was run. Maybe not
manditory, but certainly nice. For instance, under VMS you can find the name
of your executing image, thereby allowing you to look at that location for
data and/or configuration files, etc.
Most Amiga programs put config files in s: and other files in various
'standard' (though not really...) locations, but wouldn't installation of a
program be much easier (nicer for a non-techie user) if you could just move
the drawer icon to your hard drive or whereever and run the program, the
program of course can get the pathname under which it was run and thereby can
automatically find it's config and data files?
While this is just one possible situation where this might be useful, I am
sure there are other situations where it would be very useful. Persoanlly I
use this feature under VMS quite a lot for the above stated reason - ease of
use and ease when moving the files.
UUCP: {amdahl!bungia, uunet!rosevax, crash}!orbit!pnet51!glamdrng
ARPA: crash!orbit!pnet51!glamdrng@nosc.mil
INET: glamdrng@pnet51.orb.mn.orgjms@tardis.Tymnet.COM (Joe Smith) (09/27/89)
In article <780@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >Is this A Good Thing or has April Fool's day come twice this year? No, it is a serious suggestion. The feature of having an 'alternate current directory' for finding files is something I use all the time on TOPS-10. >Aren't naming conflicts a problem if for no other reason than that your >data file names must then be unique within any given 'LIB PATH'? No. The place where I used this feature the most was in creating test versions of software. All the production sources were in one directory, and the test directory had only the files that had been modified. By setting the default directory to the test directory and the alternate directory to the production directory, unchanged files would not have to be duplicated into the test directory. When doing a "make", only the changed sources would be recompiled. The new object files are created in the default (test) directory, and never overwrote the old object files in the production directory. When the linker, compiler, or make programs ran, the OS acted as if all the appropriate input files were in the current directory. All this was done without having to create a symbolic link for each and every unchanged file. >does it really make sense to assume that a file found via a path can be >written over or appended to? Yow! The path is searched only for input files, not output files. >We have much the same functionality now, with the system-assigned directories. >Libraries are searched for in LIBS:, handlers in L:, environment files in >ENV:,and so forth. For general data files, programs can pretty well count on >the existence of S:, T:, and so on. Programs that are interested in a file >can look in currentdir and in any system-supplied directory, leaving the >choice up to the user as to where it is. I agree with everything above, but that doesn't help for locating *.c and *.o when compiling. (*.h and *.lib are already handled OK.) >>And, since a program could be loaded from >>any one of many directories, the OS would need to provide a call that would >>return the full path name of where the executable was really found. > Aha! A glimmer of hope here.... in this, you seem to be saying that one > of the directories in the LIB PATH would be the directory the application > resides in. I think this might be A Good Thing. Actually, I was talking about static lists of LIB PATH directories. But it would be nice to have the OS automatically include the tool's directory in the list of automatically searched alternate directories. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
peter@sugar.hackercorp.com (Peter da Silva) (09/27/89)
In article <1153@orbit.UUCP>, glamdrng@pnet51.orb.mn.org (Rocky Lhotka) writes: > program be much easier (nicer for a non-techie user) if you could just move > the drawer icon to your hard drive or whereever and run the program, the > program of course can get the pathname under which it was run and thereby can > automatically find it's config and data files? That's the way it works for the workbench. sm_Args[0] contains the name of the program and a lock on the directory it lives in. In many ways the workbench environment is MUCH nicer, and certainly better documented, than the CLI. -- 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
gregg@cbnewsc.ATT.COM (gregg.g.wonderly) (09/27/89)
The way that VMS does this seems to be the most logical. Following in the steps of TOPS-10, VMS allows the following. 1. Process private logical names 2. Job private logical names 3. Group wide logical names 4. System wide logical names 1) Allows a process to store things in logical names or to receive parameters, such as filenames, in logical names. 2) Allows all related processes to share a logical name. This is used to either minimized copies (the job table is shared while the process table is copied per process) of the table or allow mulitple processes of a single "job" to share/exchange information, such as filenames. 3) A group refers to a users login identity. A group table is typically used to give a group of users access to something without all users having to either have the information or know how to get to it. Things in a group logical table are usually root directories of packages that one particular group of users are interested in. 4) System logicals are for use by all users. They contain things like which disks contain the roots of which directory structures etc. Now, any of these logical name classes may contain a comma separated string of directories when used in the context of a filename. For example, I am using TeX to write a document, and I have some private macros that I want TeX to load with my document. If I use a filename of the form, TEX$INCLUDES:mymac and TEX$INCLUDES was defined as define TEX$INCLUDES MY$HOME:[TEX.MACROS],TEX$ROOT:[MACROS] The file open request would search each of those directories and return a handle to the first file found. The translation is recursive so that TEX$ROOT could be defined in the system table, and MY$HOME in the job table (the translation of logical names starts at 1 above and moves towards 4, looking for a definition). Open for read requests return the first file found. Open for write requests return the first file found unless the file does not exist in which case the first directory in the list is where the file is created. This is not so bad given the above ordering of directories. In VMS this comes in most handy in the multi-machine cluster where several machines share the use of a package, but also have site specific files for that package (executables verses configuration scripts are a good example). For Amiga-Dos, per-icon INFO would equate to process or job logicals. There is no group simularity, and system logicals are already implemented. Having opens look through a list could be implemented as a library routine that sets in front of the standard open. That way, executable open requests would be rewritten as opens for PATH:progname in the exec code. Presto, each icon can have its own PATH and not interfere with others. If I want a particular package to be able to make use of its own private library of programs, I don't have to have a global PATH that holds everything. -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)
trantow@csd4.csd.uwm.edu (Jerry J Trantow) (09/30/89)
In article <24791@louie.udel.EDU> new@udel.EDU () writes: >keeps track in a separate file of where the tool for each icon gets copied >that could at least be added to Workbench, maybe as an option. How about a >command that runs through all the .info files on a disk and fixes the >default tool entry to have the right info? That seems easy enuf. > -- Darren Darren, although this doesn't directly address your needs, I manage to side step quite a few problems with a little utility called ToolChange that I wrote. ToolChange allows you to set the default tool of any icons. It can also be used to add tooltypes. When I first wrote it I thought I would be using it to interchange files between different programs. (example, select all the files in a dpaint directory and change them to use digipaint) but instead I find myself using it when I change the program name or the program path. Another item I have added to my programs in general is that whenever I write out a project Icon I optionally send out the entire path name to the default tool of the project. This ensures that if I change the path or even the name of the program, the default tool will reflect this change.
new@udel.EDU (09/30/89)
In article <271@uwm.edu> trantow@csd4.csd.uwm.edu (Jerry J Trantow) writes: >Darren, although this doesn't directly address your needs, I manage to side >step quite a few problems with a little utility called ToolChange that I wrote. Actually, I was just offering a relatively simple solution to the problem. Earlier in the thread many people proposed all kinds of bizzarre hacks to WorkBench et al to "fix" the default tools, like "tool paths" and soft links and so on. It seemed that my solution was much easier to implement quickly than patches to workbench. Thanks anyway. Maybe you could send this to comp.sources.amiga as an example. >Another item I have added to my programs in general is that whenever I >write out a project Icon I optionally send out the entire path name to the >default tool of the project. This ensures that if I change the path or even >the name of the program, the default tool will reflect this change. Maybe you should send this portion of your programs also as an example to comp.source.amiga. I think this would help many would-be brain-dead programs. I always disliked programs that clobber the icon when it isn't needed; especially ones that put the WRONG default tool into a newly created icon! Didn't CSA publish a list of "how to set up the default tool and when to change it"? It seemed to make much sense when I read it. A Loyal CLI Programmer -- Darren