mjp@spice.cs.cmu.edu (Michael Portuesi) (01/09/87)
Keywords: I've had some time to get acquainted with the 1.2 Enhancer, and all around I really like it. A lot of the "rough edges" I disliked in 1.1 are gone, including the ugly icons, the ram: driver running out of memory and crashing the system (now it tells me it's full), system requestors automatically bringing the workbench screen to the front, etc. But the one command I was looking forward to so much, PATH, is not behaving the way I expect it to. Since I only have one disk drive, I spend lots of time swapping disks in and out to load programs and data files. I put the programs I use 90% of the time on my Workbench disk, in a directory called newcommands (following a suggestion I picked up in the manual). My startup-sequence currently looks like the following: addbuffers df0: 25 path add sys:newcommands sys:system sys:utilities sys:c echo " " prompt "Ok, Mike %N> " echo "moving common commands to ram:..." makedir ram:c copy c:copy ram:c assign c: ram:c ; ; lots of commands to copy files to ram:c go here... ; run popcli What I want to do is set up a search path such that, if I have some random disk in the drive and I type the name of a command or a program that resides on the Workbench disk, the machine will pop up a requestor saying "Insert Disk Workbench 1.2 in any drive". Then it will load the command and program and I can go about my business. Right now, when I attempt this feat, the CLI barks something like "Unknown command foobie.bletch". When the Workbench disk is in the drive, however, it searches the directories on the path and finds anything I can type. If this system worked, I could have my cake and eat it too. When I type the name of an oft-used command, the system retrieves it from ram:c. When I type the name of a an obscure command, the system would automatically request me to insert the disk, then load and execute it. Also, I regularly use MicroEmacs 3.7 (until I can get my hands on microGNU 1.0). From what I can tell, it searches the current directory and c: for the init file. When I run Emacs from the top-level directory with the .emacsrc file in newcommands, Emacs doesn't find it. Newcommands is on the search path. Why isn't it found? Is it my expectations that are too high or does the PATH command do more than the manual leads me to believe? -- +----------------------------------------------------------------------------+ | Mike Portuesi / Carnegie Mellon University Computer Science Department | | | | ARPA: mjp@spice.cs.cmu.edu | | UUCP: {harvard | seismo | ucbvax | decwrl}!spice.cs.cmu.edu!mjp | | | | "Salt and pepper people, stirred not shaken" | | --Big Audio Dynamite, "C'mon Every Beatbox" | +----------------------------------------------------------------------------+
robertw@hpcvc0.HP (Robert Williams) (01/10/87)
Since you are not assigning the rest of your system to RAM:,
it would make more sense to leave c: assigned to the boot disc.
(Also, WorkBench will like it better.)
So do this:
makedir RAM:c
copy c:copy RAM:c
path RAM:c c:
{This makes your PATH:
current dir
RAM:c
c:}
{Note that you will now use the RAM:c version of copy so the rest of
your script will be considerably faster.}
.
.
{copy the rest of your files}
.
.
-robertwjohn13@garfield.UUCP (01/11/87)
In article <1115@spice.cs.cmu.edu> mjp@spice.cs.cmu.edu (Michael Portuesi) writes: > >What I want to do is set up a search path such that, if I have some >random disk in the drive and I type the name of a command or a program >that resides on the Workbench disk, the machine will pop up a >requestor saying "Insert Disk Workbench 1.2 in any drive". Then it >will load the command and program and I can go about my business. > >Right now, when I attempt this feat, the CLI barks something like >"Unknown command foobie.bletch". There is a whole range of stuff like this that should probably be looked at: - if I have path set to look at c: and drive_a:, and drive_a: is in the drive, it should look there first instead of having to <cancel> at the "Insert Workbench" prompt (after which it will work) - it would be great to have directories like devs: on a path basis too; ie before forcing me to insert Workbench to load up the ser:, par:, ram: etc drivers, it should do something akin to an "if exists dfX:devs..." - if I have many K tied up with addbuffers, then this should function something like a "partial virtual disk drive"; it should know when I try to access track foo of disk bar: that the info is available from the buffer, even though the disk may have been removed On a completely unrelated topic, does Intuition actually eat right-Amiga-N/M sequences, as well as left-Amiga ones? I thought I was doing something wrong in the menu structure for "New (A)N", but all the other (identical) ones work perfectly. I realize, of course, that only the left-Amiga ones work for WBenchToFront and WBenchToBack. John
aaron@uwmacc.UUCP (Aaron Avery) (01/13/87)
In article <3388@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: > >- if I have many K tied up with addbuffers, then this should function something > like a "partial virtual disk drive"; it should know when I try to > access track foo of disk bar: that the info is available from the buffer, > even though the disk may have been removed > >On a completely unrelated topic, does Intuition actually eat right-Amiga-N/M >sequences, as well as left-Amiga ones? I thought I was doing something wrong >in the menu structure for "New (A)N", but all the other (identical) ones >work perfectly. I realize, of course, that only the left-Amiga ones work >for WBenchToFront and WBenchToBack. > >John As near as I can tell, when you remove a disk from the drive (unmount it), AmigaDOS throws out the buffer. So, if I do a list, and the next time I do a list and it loads it from ram, if I put in a different disk and try to list it, the Amiga demands the Workbench disk. I think they should at least keep the buffer full until the next disk access. I have a menu element with (A)N assigned to it, and it works fine, and I can't imagine what your problem may be. Aaron Avery ({seismo,harvard,caip,topaz,allegra,ihnp4}!uwvax!uwmacc!aaron) (aaron%maccunix@rsch.wisc.edu) (aaron@unix.macc.wisc.edu)
glee@cognos.UUCP (Godfrey Lee) (01/14/87)
In the operating system QNX (on IBM/PC), it has a very good scheme. It has two things you can set, path and search. Path is where the system looks for commands, and is a list of directories (without the disk drive portion), and search is the search order of the drives for all file references without the drive portion specified. So, if we adopt this for Amiga, the search order for 2 floppy system might be "ram: df0: df1:", and for hard disk system might be ram:/dh0:. The path might be "c myc" -- on the drives in the search list -- or whatever. Very nice scheme as long as you treat the drive specification above as "whatever disk happens to be in the drive at the time the file open is made", and not as "whatever disk happens to be in the drive when the search list is set". By the way, I am not sure my postings are getting out, so I wouldn't mind some flames!! drive -- ----------------------------------------------------------------------------- Godfrey Lee, Cognos Incorporated, 3755 Riverside Drive, Ottawa, Ontario, CANADA K1G 3N3 (613) 738-1440 decvax!utzoo!dciem!nrcaer!cognos!glee -----------------------------------------------------------------------------