wfh58@leah.Albany.Edu (William F. Hammond) (08/16/90)
In article <4562@jato.Jpl.Nasa.Gov> is asked: > > The CLI/New Shell environment supports a search path that can be >altered via the 'Path' command. Is there such a way to get Workbench to >follow a similiar convention? > I don't understand just what it is you want to know. The command path applies only to the use of commands like "dir", "cd", and (good old) "ed" entered in a shell or CLI. Most of the time when a program is run from WorkBench by double-clicking on an icon, that program will not be using such commands. If it wants to use system libraries, it will access them directly without going through commands. (After all, the programmer has no way of knowing what commands will be available in the user's set-up.) Perhaps you are concerned about the default path in a shell or CLI that is started from WorkBench. Absent "path" instructions in "s:CLI-Startup" or "s:Shell-Startup", the path will be the path in force in the CLI from which WorkBench was loaded, i.e., in which the command "loadwb" was run. For example, if "loadwb" is run by your "s:Startup-Sequence" script, then you can create a default command path for CLI's and reasonably standard shells launched from WorkBench by inserting appropriate "path" instructions in your startup script before the "loadwb" command. (Most CLI's and shells launched with "hot keys" also will by default inherit the path in force at the time the "hot key" program is started if it is started in a CLI or shell.) Any such default path may be wiped out by a "path reset" (for example, in your scripts "s:CLI-Startup" or "s:Shell-Startup"). ---------------------------------------------------------------------- William F. Hammond Dept. of Mathematics & Statistics 518-442-4625 SUNYA, Albany, NY 12222 hammond@leah.albany.edu wfh58@albnyvms.bitnet ----------------------------------------------------------------------
jap@convex.cl.msu.edu (Joe Porkka) (08/17/90)
wfh58@leah.Albany.Edu (William F. Hammond) writes:
-
->In article <4562@jato.Jpl.Nasa.Gov> is asked:
->>
->> The CLI/New Shell environment supports a search path that can be
->>altered via the 'Path' command. Is there such a way to get Workbench to
->>follow a similiar convention?
->>
-
->I don't understand just what it is you want to know. The command path
->applies only to the use of commands like "dir", "cd", and (good old) "ed"
->entered in a shell or CLI.
I think that the idea is to allow a data file to simply give the name
of the tool. Then all of those #?.doc files would have "More" as
their default tool, rather than ":more" or "sys:utilities/more".
It would allow project to find their applications - instead of having
to fulling specify their path.
- joe porkkanew@ee.udel.edu (Darren New) (08/17/90)
In article <1990Aug16.204607.24642@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes: >I think that the idea is to allow a data file to simply give the name >of the tool. Then all of those #?.doc files would have "More" as >their default tool, rather than ":more" or "sys:utilities/more". The easiest way to do this would be to have an icon that has in it's ToolTypes a list of directories where WorkBench tools might be found and a list of equivalent programs (less==more, uShow==ShoWiz, ...). Then that tool, when double-clicked, would go through you disk and do the following: 1) If the file is a directory, recurse 2) If the file is not a project .info file, iterate 3) If the file has a complete path in the default tool, check that the pointed-to file is an executable. If not, strip off the path. 4) If the project can be found in the same directory as the tool, save the full path and iterate. 4) If the resulting name is on the left side of an assignment in the ToolTypes list of the fixer program, replace it with the right-hand side and iterate. Hence, I could change all the "less" programs to "more" with LESS=SYS:UTILITIES/MORE 5) If the resulting name is not on the left side, look through the list of directories to see if can be found. Hence, we don't need to list every program in the Utilities directory as an alias. 6) If the tool for this project still isn't found, look in parent directories for it. Hence, any ILBMs saved in (say) subdirectories of DPaint will be able to find DPaint as their tool. It really bugs me that programs insist on clobbering stuff in the icons when saving files. For example, I carefully save the complete path to the VoRecOne recognizer (which works much better with one of those little foam wind blockers, BTW), and the next time I save the file, the path gets screwed. Especially years after CBM came out with the guidelines on when to muck with the path in an icon. As usual, if I had all the time in the world, I would do this myself. :-( -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
lclausen@lckaos.UUCP (Lars R. Clausen) (08/18/90)
>In article <27722@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: >In article <1990Aug16.204607.24642@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes: >>I think that the idea is to allow a data file to simply give the name >>of the tool. Then all of those #?.doc files would have "More" as >>their default tool, rather than ":more" or "sys:utilities/more". > >The easiest way to do this would be to have an icon that has in it's >ToolTypes a list of directories where WorkBench tools might be found and >a list of equivalent programs (less==more, uShow==ShoWiz, ...). > -- Darren Another way to solve much of this problem, and a few others besides, is to have default icons for, say, Docs, ILBM, SMUS, ANIM etc, where your favorite viewer/reader/player is listed. That way, you'll get: 1) No problems with finding the viewer/.. 2) The same viewer/.. no matter where the file comes from. 3) The same icon for the same class of objects. 4) Less diskspace used for the icon, as this could be stored in a separate file. 5) Less time used when opening a drawer, as many items would be found in a little file, containing only the type, name and position (maybe more?) I proposed this idea to Commodore in the Spring, and the first parts of it seems to be coming up (WBDISKCACHE f.ex.) Problem is, several icon routines would have to be rewritten to get this effect. -- +-----------------------------------------------------+---------------+ | Lars R. Clausen (Fido: 2:230/22.34) | \S\ | | ..{pyramid|rutgers}!cbmvax!cbmehq!lckaos!lclausen | Thi\O\space | | 42 - the answer to the ultimate question of * | for\L\ale | | Claimer: Representing Sirius Cybernetics Coperation | \D\ | +-----------------------------------------------------+---------------+