spencer@eris (Randal m. Spencer [RmS]) (02/18/88)
Ok, here is an interesting point. Who out there is using sys:c or sys:l or any variation on that in their programming. I'll tell you who is Bill Hawes! that's who. ConMan looks for the handler in sys:l. I don't think I can tell you what a pain that is. It took me forever to figure out that that was the reason my Startup-Sequence failed. But on top of that it made me realize that the idea of workbench keeping its files (diskcopy and format) in sys:system and not system: is also quite annoying. I guess that I have to post this to Bix or something, but tell me this, why do I have to create a directory in ram called system when I want to run diskcopy and format out of ram? I want to just copy the files and then assign System: to Ram:, or is that just me that feels this way? Lecture over... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)222-7595 spencer@mica.berkeley.edu I N F I N I T Y BBS: (415)222-9416 ..ucbvax!mica!spencer s o f t w a r e AAA-WH1M -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
andy@cbmvax.UUCP (Andy Finkel) (02/20/88)
In article <7025@agate.BERKELEY.EDU> spencer@eris.berkeley.edu (Randal m. Spencer [RmS]) writes: >Ok, here is an interesting point. Who out there is using sys:c or sys:l >or any variation on that in their programming. I'll tell you who is >But on top of >that it made me realize that the idea of workbench keeping its files >(diskcopy and format) in sys:system and not system: is also quite annoying. Are you advocating keeping all such files in the root ? Workbench keeps its files in the System drawer so a) it can find them, and b) so they don't clutter up the root directory. Many other operating systems find the idea of splitting up the commands into different directories useful, as well. Among other things, it minimizes name collision. >why do I have to create a directory in ram called system when I want to >run diskcopy and format out of ram? I want to just copy the files and >then assign System: to Ram:, or is that just me that feels this way? Well, one more logical name wouldn't be too bad. Of course, you could no longer name a disk (or volume) System. But where to stop ? That's the question. -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Never test for an error condition you don't know how to handle." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
john13@garfield.UUCP (John Russell) (02/21/88)
In article <7025@agate.BERKELEY.EDU> spencer@eris.berkeley.edu (Randal m. Spencer [RmS]) writes: > >why do I have to create a directory in ram called system when I want to >run diskcopy and format out of ram? I want to just copy the files and >then assign System: to Ram:, or is that just me that feels this way? This used to bug me a little too. It's only with the Workbench (so you can path ram: from the CLI) but these are about the only things I use the Workbench for now. It should be possible to change, eg patch the sys:system/diskcopy that must be in "format" somewhere (so it can stick it in disk.info), and write a little program to 'convert' the default tool entries of old disks. This would of course have the possibility of confusing novice users. However the way it is now is confusing, especially when you are trying to explain it to said novice using his WB disk, which is invariably a commercial program with commands like 'makedir', 'assign' etc left out. John -- "Fanaticism is all right... as long as you're ALONE! HAHAHAHA!" -- Pat Robertson shares a gem of wisdom told to him by Richard Nixon, and thus becomes the first politician to whom I can honestly apply the term "scares the willies out of me"
louie@trantor.umd.edu (Louis A. Mamakos) (02/21/88)
Actually, another logical name to add would be one that the clipboard.device to use. Currently, it seems that it uses DEVS:clipboards as the directory it stores clips in. Because of this, I can't write protect the device that has the DEVS: directory in it. It might be handy for those with large amounts of RAM to assign the, say, CLIP: device to something in RAM:. Just a thought. louie Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
jesup@pawl22.pawl.rpi.edu (Randell E. Jesup) (02/21/88)
In article <3343@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >In article <7025@agate.BERKELEY.EDU> spencer@eris.berkeley.edu (Randal m. Spencer [RmS]) writes: >>But on top of >>that it made me realize that the idea of workbench keeping its files >>(diskcopy and format) in sys:system and not system: is also quite annoying. > >Are you advocating keeping all such files in the root ? >Workbench keeps its files in the System drawer so a) it can >find them, and b) so they don't clutter up the root directory. As far as I know, SYS: has no real purpose in life. All the useful directories (until 1.2 and system) had assigns so you could move them elsewhere, or rename the directories. Looking for a specific subdirectory off of SYS: violates this standard. >>why do I have to create a directory in ram called system when I want to >>run diskcopy and format out of ram? I want to just copy the files and >>then assign System: to Ram:, or is that just me that feels this way? >Well, one more logical name wouldn't be too bad. Of course, you >could no longer name a disk (or volume) System. But where to stop ? All "special" directories should have assigns, as l, libs, fonts, c, s, and devs do. I think that t: should be added as well, but that's no where near as important. I think applications should be wary of counting on having their own special assigns. They may conflict with disk names in the system, other appications, and make people startups slower. Perhaps applications should check relative paths first, then look for files relative to some assign/disk name. This isn't always possible, especially for things like compilers, but you can limit the number of assigns needed (Lattice needs LC:, INCLUDE:, QUAD: and LIB:.) With the arp library, shell variables can take the place of many assigns, avoiding at least the conflicts with disk names. Of course, you must still have and set the shell variable, but.... // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup
pds@quintus.UUCP (Peter Schachte) (02/23/88)
In article <3343@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) writes: > In article <7025@agate.BERKELEY.EDU> spencer@eris.berkeley.edu (Randal m. Spencer [RmS]) writes: > >Ok, here is an interesting point. Who out there is using sys:c or sys:l > >or any variation on that in their programming. I'll tell you who is > > >But on top of > >that it made me realize that the idea of workbench keeping its files > >(diskcopy and format) in sys:system and not system: is also quite annoying. > > Workbench keeps its files in the System drawer so a) it can > find them, and b) so they don't clutter up the root directory. > > Many other operating systems find the idea of splitting > up the commands into different directories useful, as well. > Among other things, it minimizes name collision. > > >why do I have to create a directory in ram called system when I want to > >run diskcopy and format out of ram? > > Well, one more logical name wouldn't be too bad. I haven't seen this topic beaten to death here, so I thought I'd try it. Why not allow ASSIGNs to PATHs (lists) of directories? You could do something like ASSIGN C: ., ram:c, sys:c, sys:system, sys: ASSIGN S: ram:s, sys:s ASSIGN FONTS: sys:fonts, fontdisk:fonts ASSIGN INCLUDE: ., ram:include, sys:include You get the idea. There are so many more things that one might want search a path for than just executables. Notes: I don't know of any amigados way to say "the current directory," so I used "." above. And in the FONTS: example, the idea is that when you ask for a font that isn't loaded, and isn't on the system disk, you would be prompted to insert the "fontdisk" disk. Of course, you would also be prompted to insert it when the system is just trying to decide what fonts you have available, so it had better cache this info once computed. This would also solve the problem of WB tools being unable to find their programs (when, e.g., you try to move the program to your sys:c or dh0:c directory, where you think it should be. The problem is that paths are local to a CLI (correct me if I'm wrong), so a WB tool can't count on a path allowing it to find its program. But ASSIGNs are global. A tool could always find C:program, if C: was a path ASSIGN including the sys: directory. I don't think having one's path be global is much of a disadvantage, and it does have the mentioned advantage for WB tools. There is also the issue of where to create a file in an ASSIGNed path. One could take the simple approach of creating it in the first directory listed in the path. Perhaps it would be better to extend the syntax for ASSIGN to allow the specification of this information, e.g., ASSIGN C: ., ram:c, sys:c, sys:system, sys: CREATE sys:c How about it? I heard someone mention this at a recent BADGE meeting, so I know it's not a new idea. But it sure seems like a good one. This is what I was hoping they would do in 1.2, rather than adding the PATH command. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
jdh@bsu-cs.UUCP (John Hiday) (02/24/88)
In article <3343@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >[...] >Well, one more logical name wouldn't be too bad. Of course, you >could no longer name a disk (or volume) System. But where to stop ? >That's the question. Why not put a special character in all system defined logical names to help avoid such conflicts with commonly chosen names? For example instead of FONTS: make it something like $FONTS:. Of course for backwards compatibilty the old definitions would have to be doubly defined (both with and without the special character), but all new logical names could follow the new convention. I don't really think that we can expect to see the number of standard logical names decrease or even stay the same. Something has to be done about possible conflicts. Such problems can really confuse the hell out of an inexperienced user. While I'm on the subject, I would like to add my name to the list of people who have requested some form of late-binding logical names. Maybe the need for these will decrease if and when environment variables are officially supported, but they still have their uses at times. -- == John Hiday UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!jdh == Ball State University / University Computing Services GEnie: JDHIDAY == Muncie, IN 47306
bts@sas.UUCP (Brian T. Schellenberger) (02/28/88)
. . . And why can't AmigaDos put temp files in t: intead of @#*%!
<drive>:t for crimenie sake? It's durned annoying having to hear the
drive go crank-floppa-jing-grind-will-this-take-the-rest-of-the-day-or-what
when it could run from ram: in a flash.
--
--Brian.
(Brian T. Schellenberger) ...!mcnc!rti!sas!bts
DISCLAIMER: Whereas Brian Schellenberger (hereinafter "the party of the first peter@nuchat.UUCP (Peter da Silva) (02/28/88)
> How about ASSIGNing to a PATH of directories?
I suggested something like this, back in 1.1.
The simplest would be to have a handler named "PATH"
Then you could do this:
assign C: PATH:vd0:c;sys:c;...
assign DEVS: PATH:vd0:devs;sys:devs...
Modulo any problems with the syntax wedging on colons in names. When you got
a lock on it, it'd squirrel away the string somewhere. Then when you used the
lock in an open or examine call it'd search all the directories. Voila.
Doesn't require changing AmigaDOS at all. Something else to put on the "to-do"
list, right after VT100:, DEV:, and CLI: :->.
--
-- a clone of Peter (have you hugged your wolf today) da Silva `-_-'
-- normally ...!hoptoad!academ!uhnix1!sugar!peter U
-- Disclaimer: These aren't mere opinions... these are *values*.andy@cbmvax.UUCP (Andy Finkel) (03/01/88)
In article <365@sas.UUCP> bts@sas.UUCP (Brian T. Schellenberger) writes: >. . . And why can't AmigaDos put temp files in t: intead of @#*%! ><drive>:t for crimenie sake? It's durned annoying having to hear the For many things, yes it can. And will. Some, however, are best put in :T , like file backups that move about via Rename. -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Never test for an error condition you don't know how to handle." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
adam@lamont.Columbia.edu (adam levin) (03/02/88)
In article <365@sas.UUCP>, bts@sas.UUCP (Brian T. Schellenberger) writes: > . . . And why can't AmigaDos put temp files in t: intead of @#*%! > <drive>:t for crimenie sake? It's durned annoying having to hear the > --Brian. > (Brian T. Schellenberger) ...!mcnc!rti!sas!bts I asked myself this same question, and found that the cause of this problem is c:Execute. If you have a file-zapping program, here are the changes. First rename c:Execute to c:Execute_tru (or whatever you like), then file- zap c:Execute like so: 1) Change the one reference to ":T/Command-0-Tnn" to "TT:Command-0-Tnn" 2) Change the one reference to ":T" to "T:". And, each time you boot (preferably include this in your Startup-Sequence): 3) Assign T: RAM: (or wherever you like) 4) Assign TT: T: Note that in step one, zapping it to "T:/Command-0-Tnn " (note the trailing space) or " T:/Command-0-Tnn" (now note the leading space) will not work. A trailing space won't work because the "nn" in the string gets modified (it receives the "unique" tag for this execute job) and everything has been shifted left one character. The leading space won't work because it is considered to be part of the filename. Hmmm, now that I think about this, you may need to have an undoctored c:Execute on your boot diskette. I know I do! :-) Adam Levin -- Phone: (914) 359-2900 x340 Post: Lamont-Doherty Geological Observatory / Palisades, NY 10964 USENET: {ihnp4, decvax, seismo} philabs!lamont!adam ARPA: lamont!adam@columbia.edu