NOTE: This file represents notices addressed to CHEATH and the responses thereto. The notices are up to April 23, 1989. Theme: ARP MOUNT To : CHEATH (r) By : FREDS Title: COULD THERE BE A PROBLEM I've run into a problem using the ARP mount command with RAD. My RAD will not survive a warm boot when mounted with the new mount command, but it works fine under C-A mount. Another friend also noticed the same problem. We are both using A1000's with Insider memory boards. Also, wanted to say nice job on the total package and shell features. Thanks, Fred Theme: ARP MOUNT To : FREDS (r) By : CHEATH Title: R#47196 V1.3 ARP Fred - I've been using the V1.3 ARP Mount with RAD: and it survives reboot here. Could be there's a problem related to either the Insider or to your specific mountlist entry, though. If you'll send me a copy of your mountlist entry I'll see if I can figure anything out- ...cheath Theme: ARP MOUNT To : CHEATH (r) By : FREDS Title: R#47223 ARP 1.3 MOUNT CONTINUED Well, here's my rad: mountlist: device = ramdrive.device unit = 0 flags = 0 surfaces =2 bpt = 11 reserved = 2 interleave = 0 low = 0 hi = 9 buffers = 5 bufmemtype = 1 excuse the abbreviations but this mountlist has worked fine for a few months now using C-A mount. Any help would be appreciated and everything else is working juust fine. Thanks, Fred p.s. As I said, the rad: works as advertized (warm booting from there) except when using the new 1.3 arp mount. Theme: ARP MOUNT To : FREDS (r) By : CHEATH Title: R#47226 ADD BOOTPRI Fred - it turns out you'll need to add a BOOTPRI= line to your mountlist to get RAD: to autoboot with the ARP Mount - by default the ARP V1.3 MOUNT is setting a minimum boot priority. If you stick in a line "BOOTPRI=5" you should be OK. I'm not sure about the abbreviations, you may need to use the full keywords rather than abbreviations, if so you'd get an error message something like "unrecognized keyword" when you try to Mount something. ...cheath Theme: ARP MOUNT To : CHEATH (r) By : FREDS Title: R#47289 BOOTPRI FIXES PROBLEM I tried the bootpri =0 and all is working fine now. Thank you very much, Fred Theme: ARP MOUNT To : CHEATH (r) By : SKEEVE Title: R#47223 MOUNT VS RAD: REBOOT Charlie, I can confirm the RAD: lack of reboot with the ARP mount (on a 1000 with a Spirit Technology Inboard). Noticed it not working yesterday, but did not connect it with my installation of ARP until Fred posted his experience. Jim Theme: ARP MOUNT To : SKEEVE (r) By : FREDS Title: R#47243 HARD DISK? Do you have a harddisk hooked up to your system? I was wondering if my supramount was interfering with the arp 1.3 mount. Fred Theme: ARP MOUNT To : FREDS (r) By : SKEEVE Title: R#47245 NO SPECIAL HD MOUNT Fred, Yup, I have a Spirit HDA-506 attached to my 1000. Uses normal mount though. The Mount DH0: has given me no problems at all. Jim Theme: ARP MOUNT To : SKEEVE (r) By : FREDS Title: R#47284 IT WASN'T THE HD MOUNT I don't know if you saw Cheath's message, but a BOOTPRI = 0 or higher is needed in the rad mountlist entry for the Arpf1.3 mount. It works as advertised now! Fred Theme: APR AND SKIP COMMAND To : CHEATH (r) By : SUBXO Title: ARP AND SKIP COMMAND I am running the startup sequence uploaded by Jeff Marks awhile back, the one with JEFFSMOUNT and 5 options. When I use the disk that I installed the ARP commands on, all commands in ARP install, I get a skip failed return code 10. When I put the regular Amiga DOS SKIP command back in the problem goes away. First time I have tried using ARP so maybe there is something I should know??? Any help would be appreciated. Theme: APR AND SKIP COMMAND To : SUBXO (r) By : CHEATH Title: R#47293 SKIP? I'm not aware of any problems with ARP SKIP, but if you'll point me to the Startup-Sequence file I'll take a look at it- ...cheath Theme: APR AND SKIP COMMAND To : CHEATH (r) By : SUBXO Title: R#47294 ARP AND SKIP COMMANDS Cheath, I couldn't find the file that I downloaded from PLINK. The read file with it said the author was on PLINK, name of Jeff Marks. Scanned the USER base with his name and got no matches. I will leave a message to ALL to see if anyone else knows the library number SUBXO Theme: ARP 1.3 INSTALL To : CHEATH (r) By : J DUBLER Title: SLIGHT PROBLEMS... Charlie: I don't want to be the first to bug you with problems on ARP, but I had a bit of a problem getting past the install you may want to look into. I dl'd ArpRel3.zoo last night and attempted to run ArpInstall. After successfully copying the new library, about 3/4 through the copy of the Standard ARP Commands, the install program stopped with an... "ARP installation failed! Cause of failure was... UNKNOWN ERROR". Well, I *had* gotten a checksum on the download, but was so close to the end of the transfer when it happened I hoped just a doc file would be bad. So I figured I took the chance and lost, and proceeded back to the Zone to get the file again. After two more tries to download, and two more checksums 7/8's through the transfer (this file isn't small, and this is taking precious time! Thank god for 2400 baud! :-) ), a third try FINALLY got the file clean. I ran ArpInstall once again, with the same results. I skipped the Standard and tried doing Extended ARP Commands, and this time the error came sooner. I re-booted my machine and stopped the Startup- Sequence from beginning my regular Circus of Programs, re-ran ArpInstall and got the SAME RESULTS! If it helps, each time after the error my CLI mysteriously seemed to point to a directory on the system disk, even though the prompt continued to show the value RAMBO:, my directory *before* running ArpInstall (i.e, the prompt agreed with my former CD, but no longer agreed with the actual CLI current directory after exiting the install). I finally installed successfully on a copy of the original CBM Workbench, and copied the programs over manually. About the main customization I have is the addition of ARexx and support libraries, but otherwise notice nothing *that* strange with my boot disk! (I know, easy for me to say, since *something* was wrong!) I do like the convenience of the install program, but I have no idea what I may have done to my boot disk to get this UNKNOWN ERROR. Just thought you might like to know. I'll be happy to try it again if you need more information. And thanks once again for ARP! John Theme: ARP 1.3 INSTALL To : J DUBLER (r) By : CHEATH Title: R#47305 DELETE PROTECTED FILE? Taking a wild guess, you may have a delete-protected copy of LoadLib, which comes with the AREXX package ... apparently when ArpInstall tries to write over a delete-protected file, you'll get the "Unknown error" error message, and since you've said the problem occurs installing the extended commands that's the most likely file to check- or just list C: and look for any with the D bit missing from protection- ...cheath Theme: ARP3 ASHELL To : CHEATH (r) By : JACKJ Title: R#47290 MORE ON ARP3 cheath - thanks for the offer, but it's under control for now... after a little more playing around, I found that the initial CLI *IS* terminating, but its window is not being closed...why beats me...however, I just run xoper when I open my first ashell & have it automatically close the AmigaDOS window...poof! I would be interested in figuring out why this happens...I have installed all the arp stuff, I'm using conman as newcon & pip on a 1MB A500 w/68010 & decigel, dual floppy, original ROMs...pretty vanilla...any thoughts? thanks for your interest, Jack Theme: ARP3 ASHELL To : JACKJ (r) By : CHEATH Title: R#47317 STICKY WINDOW Do you mean you've got CONMAN installed as NEWCON:, or that you use "CON:" with conman? I'd probably have to see your startup-sequence to make a guess of why the window has somebody holding on to it, can't think of anything that might do that- ...cheath Theme: ARP3 ASHELL To : JACKJ By : ANDYFINKEL Title: R#47317 LOCK ON THE WINDOW That indicates that some command has an output lock on the initial CLI window. I hope that task is really dead, and isn't planning to send a message to the window....or you'll see the GURU quickly. andy Theme: ARP 1.3 To : CHEATH (r) By : DJJAMES Title: ARP.LIBRARY PROBLEM? Charlie: Now that I'm using the new arp.library, I can't get TxED to print the Clipboard. It simply gives the error requester stating TXPRINT error. If I go back to the last version of arp.library, PrintClip works. I'm using the new patched TxED. I'll have to try it with the vanilla right out of the box TxED. Djj Theme: ARP 1.3 To : DJJAMES (r) By : CHEATH Title: R#47318 TXPRINT + ARP V1.3 DJ - TXPRINT with V2.0/V2.01 of TxEd and arplib V1.3 won't work, we fixed a specification for the ARP process calls to make sure all command line strings would be properly terminated the same was as if run from CLI ... and TxEd+ was relying on a NULL string, which was a side-effect. We decided it was better to fix the problem in the library, since I will be releasing V2.02 of TxEd+ shortly which will solve the problem with TxEd+. ...cheath Theme: ARP 1.3 To : CHEATH (r) By : JOHN*VIG Title: R#47369 TXED+ 2.02 INCLUDES ARP 1.3? Charlie, will Arp 1.3 be included on the TxEd+ 2.02 disk? (i.e., do registered TxEd owners need to DL Arp 1.3 from the LIB?)...........John. Theme: ARP 1.3 To : JOHN*VIG (r) By : CHEATH Title: R#47378 TXED+ V2.02 , ARP V1.3 John - the V1.3 ARP release will be included with the V2.02 TxEd+ release, it's been one of the things holding up the TxEd+ release. V2.02 still won't be complete for a while, so you may want to go ahead and download ARPREL3 anyhow- ...cheath Theme: ARP 1.3 To : CHEATH (r) By : WALRUS Title: R#47369 'COPY ALL' Charlie, some time ago I had read somewhere that the 1.2 Arp COPY command had a minor problem when used to 'COPY ALL' a bunch of stuff to another disk. Maybe not really a problem, just that it didn't do as good a job as the AmigaDOS COPY at placing the files on the new disk to minimize fragmentation and speed up access. (Sorry, I can't remember where I read this, it was either here, CIS, Usenet, or one of the countless Amiga mags I subscribe to.) Has this changed with Arp 1.3? (Or, maybe it was never a "problem"?) Joel Theme: ARP 1.3 To : WALRUS (r) By : CHEATH Title: R#47436 SHAVES AS CLOSE AS A BLADE Joel - with the V1.3 COPY, we switched to using key order rather than alphabetic ordering. That was what the inefficiency was; if you copy with key ordering, the directory and block layout is closer to optimal than in a random or alphabetic order. The order copied now should be identical to what the ADOS Copy gives ... or your money back! ...cheath Theme: ARP 1.3 COMMANDS To : CHEATH By : HOWARD A Title: ARP COMMANDS Just a quick comment question. Is there going to be a problem with the ARP 1.3 commands when WorkBench 1.4 comes out? I know I may be jumping the gun, but within a week of getting my c: directory and s/startup-sequence the way I wanted them using old ARP commands (The ones that came with TxEd Plus) Workbench 1.3 came out and it took me some thinking to realize that mount wasn't exactly compatible or how to use the old ARP resident with WB 1.3. I know ARP 1.3 commands are excellent replacents for WB 1.3 commands but I was just curious. Thank you, Howard Theme: ARP 1.3 BUG REPORT To : CHEATH (r) By : OPS289 Title: EXECUTE COMMAND BUG Bug Report - pgm EXECUTE I have observed a bug or at least an incompatability with AmigaDos in the Execute command. This problem appears when using Superbase Professional but can probably be duplicated with any program that calls execute similarly. When attempting to run the SBFORMED program from within Superbase, a System requester appears stating: PLEASE INSERT VOLUME "HDISK IN ANY DRIVE (The open quote appears in the requester) I have ASSIGNed SBFORMED: HDISK:Superbasepro in my startup sequence. When I cancel the Requester, the superbase output window displays the message: Cannot open path/filename.tmp Execute failed (returncode 20) I hope this report helps to improve an already great package. THANKS for ARP! Theme: ARP 1.3 BUG REPORT To : OPS289 (r) By : CHEATH Title: R#47377 SBFORMED? Hmm ... I can't tell from your description exactly what is being executed. Is there an AmigaDOS script file that you're running - perhaps do you or someone else know what the SBFORMED program does? It sounds like a path name is being parsed differently by something. Are you using the ARP Shell, ASH, or if not, what is your setup? Thanks- ...cheath Theme: ARP 1.3 BUG REPORT To : CHEATH (r) By : -DAVE- Title: R#47379 SBFORMED IS... I just caught the tail end of this, but SBFORMED is the filename for SuperBase Professional's Form Editor. -Dave- Theme: ARP 1.3 BUG REPORT To : CHEATH (r) By : OPS289 Title: R#47379 ARP1.3 BUG REPORT Charlie, I did a little checking into what was going on in the Superbase program to bring this bug to light. Here is what happens. When chosing the menu item EDIT FORM, Superbase writes a short script file to the current directory. The script goes like this: run SBFORMED "pathname" "formname" (the quotes do appear in the script to enable paths and forms to contain spaces ) I have not had any problem with this when using CBM's 1.3 EXECUTE command. I tried using ARP EXECUTE with ARP run, ARP EXECUTE with CBM RUN and CBM EXECUTE with ARP RUN. The last combination works fine. I am sure you are correct in saying the parsing is different although one would think that the RUN command would be at fault. Tis not the case however. Since my last message to you I have found a new problem with EXECUTE. When I launch Superbase via a script EXECUTEd via a MACHII hotkey, I get a visit from the Towel Headed Wonder of 81000009. Again, I have had no problem launching the program this way with CBM EXECUTE. FYI, I am running William Hawes WSHELL, FFS on a hard disk through the WEDGE. 1/2 meg of Chris Irving's piggyback hack and 1meg of Microbotics Starboard. I hope this information is useful to you. ARP is a fine project. Thank you for your (et al) efforts. Theme: ARP 1.3 BUG REPORT To : OPS289 (r) By : ALLEGRO Title: R#47490 QUOTING INCOMPATIBLITY WITH ARP Regarding a visit from the guru when executing something from a MACHII hotkey.... When I switched to ARP1.3 a few days ago, I had some difficulty with running Qmouse from my startup sequence. I was setting up two hot keys on the Qmouse command line, and the Guru would come when I hit one of the hot keys. The problem turned out to be the way I was quoting the hot key strings. The ARP1.3 readme (or ASH doc file) explains that quoted strings may have to be done differently: standard CBM run command takes quotes "like this" while the ARP run needs them "\"like this\"". When I changed it, the gurus went away. I don't use MACHII, but perhaps your problem is similar. By the way, CHEATH, ARP1.3 was well worth the wait! Thanks! Theme: ARP 1.3 BUG REPORT To : ALLEGRO By : CHEATH Title: R#47577 QUOTATIONS Guess I'd better go read the docs on quoting, I wasn't aware of this difference! If you can give the exact sequence which was causing a problem with QMouse, I'd appreciate it so I can try to track down if there's an ARP problem or if the GURU's in QMouse, thanks- ...cheath Theme: ARP 1.3 BUG REPORT To : CHEATH By : JVM Title: R#47598 QMOUSE & ARP1.3 Make sure you have the latest version of QMouse, (1.52?) and even then, suspect QMouse. I had quite a few problems using the hotkeys to execute things on some of the older versions, and I don't much like the way Lyman clobbers the hardware sometimes...but hell, I use it! If he fixes some more bugs, I might even send him a donation. 8-) Justin Theme: ARP 1.3 LIB... To : CHEATH (r) By : LENW Title: WON'T RECOOGNIZE LIB... Just downloaded ARP 1.3, ran the install program (which is excellent), and immediately ran into problems. Specifically, arp.library seems to get into libs: okay (size = 17100), but when I run some commands (INFO and EXECUTE at least), I get a message saying I need arp 39+. When I do "version", I get 34.(something). Any ideas? Thanks, I look forward to finally using ARP again. Len W. Theme: ARP 1.3 LIB... To : LENW (r) By : APL Title: R#47384 REBOOT AFTER ARP INSTALLATION 1. You need to re-boot for the new library to take effect. 2. Make sure the new arp.library is on your initial boot-disk, as well as any disk to which you switch LIBS: control... --apl Theme: ARP 1.3 LIB... To : APL (r) By : LENW Title: R#47387 FORGOT DF0:LIBS... Thanks for the help. Gosh I hate it when I make dumb mistakes. Everything I did would have worked, if I actually booted from the hard disk, and not df0: Oh well, public humiliation is character-building... Thanks, Len W. Theme: ARP 1.3 LIB... To : LENW (r) By : CHEATH Title: R#47539 ARP.LIBRARY IN DF0:LIBS No problem, Len, this is actually one of the most prevalent problems in getting ARP installed, is to actually get arp.library into the LIBS: directory before the first ARP command runs. I forgot to stick a note about this into ArpReadMe, or to get Martin to put a mention of this in the library installation page of ArpInstall ... I 'spect that if the mention had been there when you ran through ArpInstall you'd have probably caught the problem immediately, so we'll definitely want to add this the next time ArpInstall gets revised. }i ...cheath Theme: ARP 1.3 LIB... To : LENW (r) By : APL Title: R#47539 CHECK DF0: Don't worry - it's a common mistake... --apl Theme: ARP 1.3 LIB... To : LENW (r) By : NY*JIM Title: R#47384 YOU NEED TO FLUSH THE OLD LIBRARY... I see at least one answer to your question (You need to reboot), but there is another option. If you normally load Workbench with the command "loadwb -debug", you have a menu with an option entitled "flushlibs." Select this option. The problem is this: arp.library has *already* been loaded, if you have been using either the old ARP or anything that needs arp.library. Before you can load the new version of arp.library, you need to flush the old one. I got bitten by this one too, and used flushlibs. Jim Theme: ARP 1.3 LIB... To : NY*JIM (r) By : CHEATH Title: R#47396 FLUSHING LIBS/DEVICES Sometimes the "flush libs" will work, but if you're running some program which keeps arp.library open that won't do the trick ... so the easiest thing to do is usually to reboot, particularly if you get the "you need arp.library V39+" message, after installing the new Arp library. This will be true of most libraries/devices which you might replace in the system; the system's not really set up anticipating a need to open a more recent version of a lib/device once any version has been opened- ...cheath Theme: ARP 1.3 LIB... To : NY*JIM (r) By : LENW Title: R#47396 FORGOT DF0:LIBS Thanks for the help. I didn;t know flushlibs was there under -debug. Very helpful! Theme: ARP 1.3 COMMANDS To : CHEATH (r) By : NY*JIM Title: R#47370 RAD COMMENTS AND CONGRATS >if you want to reboot with RAD:.. make sure there is a "BOOTPRI=0"... Just to clarify this, if you use the ARP mount command to mount rad:, you will need that statement. (Which only makes sense, since the mountlist is only needed when RAD: is mounted, but I digress..) Since *any* BOOTPRI entry in the RAD: mountlist seems to lead to the mysterious "double entry in INFO for DF0: bug", I boot with the regular AmigaDOS command set and stuff the ARP stuff into RAD:. With *no* bootpri entry in my mountlist. I hate seeing those two entries for df0:.... By the way, Charlie - congratulations on an *excellent* package! The new installation interface is particularly nice, and should go a long way toward getting those "on the verge of CLI" to use ARP. What is most interesting is the fact that I haven't noticed that I've installed ARP. In fact, I'd forgotten... I installed it while approving it the day it was uploaded, and forgot it was there for a day or two. If that's not transparent, I don't know what is! Knowing it's there, though, makes it easier for one to take advantage of the ARPian differences, of course.... Jim Theme: ARP 1.3 COMMANDS To : NY*JIM (r) By : FREDS Title: R#47395 NO PROBLEM HERE What bug are you referring to? I just tried both c-a info and arp info and did not get a double entry listing of df0:. And I'm am mounting with the arp mount for rad. Fred Theme: ARP 1.3 COMMANDS To : FREDS (r) By : NY*JIM Title: R#47404 IT WAS SO LONG AGO... This was thrashed around some time back. As I recall, if you had a bootpri entry for rad:, df0: would get validated twice and would show up twice in info. I'm *not* going to do a remrad and edit my mountlist, so unless someone verifies that this no longer happens or still happens or nobody cares, I dunno what to tell you. It wasn't exactly a fatal bug, anyway. Jim Theme: ARP 1.3 COMMANDS To : NY*JIM (r) By : DENNY Title: R#47406 A RAD IDEA Jim, You can always do an ASSIGNDEV RAD: after rebooting from the RAD: disk and ^OOPS! -- ASSIGNDEV DF0:, that is presto! Only one entry for DF0:! ...Denny Theme: ARP 1.3 COMMANDS To : FREDS (r) By : CHEATH Title: R#47404 RAD: REBOOTS Sometimes when you reboot from RAD: (with C= or ARP commands), there is a race condition which causes two entries for DF0: to be entered into the system, which will show up if you run Info. Actually I shouldn't say "sometimes", it'll happen consistently when it happens, I just forget the details on why/when it happens. ...cheath Theme: ARP 1.3 COMMANDS To : NY*JIM (r) By : CHEATH Title: R#47395 TRANSITION Thanks, Jim. I think that, for the most part, once you get past some startup things most people shouldn't be able to tell if they're running under ARP or under the Commodore V1.3 commands. Most of the problems that do occur are likely to be in the actual switch over, when things like the required BOOTPRI for RAD: come up. The install program, hopefully, will help alleviate a lot of the problems we'd had before in which people would not get the library installed, etc. ...cheath Theme: ARP AND SKIP COMMAND To : CHEATH (r) By : SUBXO Title: ARP AND SKIP COMMAND Cheath, The startup-sequence I am using is in the ZONE, #15015 STARTUP.ARC . To refresh your memory, I get a SKIP failed return code 10 using that startup-sequence but I don't with the DOS 1.3 SKIP command. GEorge Straight (SUBXO) Theme: ARP AND SKIP COMMAND To : SUBXO (r) By : CHEATH Title: R#47409 SKIP OK, thanks George - I'll take a look at Startup.arc- ...cheath Theme: ARP AND SKIP COMMAND To : SUBXO (r) By : CHEATH Title: R#47409 SKIP LAB & WHITESPACE George - as best I can tell, the problem is that the ARP Skip expects to see the "LAB" statement at the beginning of the line, without any whitespace before the LAB command. I'm not sure about the C= SKIP; I think the V1.2 SKIP required LAB to be at the start of the line but it sounds like the V1.3 SKIP allows whitespace. Can you try editing the Startup-Sequence file, and remove whitespace at the start of each LAB command, and let me know if that solves the problem? Thanks- ...cheath Theme: ARP AND SKIP COMMAND To : CHEATH (r) By : SUBXO Title: R#47426 ARP AND SKIP AND LAB Cheath, Edited the s/u sequence to move LAB to the head of the line, rebooted and now have no more problem with the ARP SKIP Command. Thanks for your quick response. SUBXO Theme: ARP AND SKIP COMMAND To : SUBXO (r) By : CHEATH Title: R#47458 SKIP WHITESPACE Ah, good, glad we at least know what the problem is. I'll add that to the bugs database for next time, thanks for pointing out the problem. ...cheath Theme: TXED+ ARP AREXX To : CHEATH (r) By : GENEH Title: SUGGESTIONS FOR TXED+ 2.02 Dear Charlie Heath, I just bought TxEd+ as my new editor to replace DME for three main reasons including: excellent magazine reviews, your full ARexx interface, and your work with ARP. I've only been using it a few days and I look forward to learning more about it. I know about the TXPRINT incompatibility with ARP 1.3 and I'll wait until 2.02 is ready. I would like to suggest that when 2.02 ships that you include several example startup files showing how it can have different configurations. With 2.01 there aren't enough examples (for me anyway) to figure out exactly how I want TxEd configured. Maybe fellow Plinkers could upload their startup files for others to downloads. Theme: TXED+ ARP AREXX To : GENEH (r) By : CHEATH Title: R#47471 TXED / AREXX MACROS There will be more AREXX examples with V2.02, this is definitely needed. I've been collecting my own macros, and also there are a lot of good examples available now on BBS's some of which I'll be putting on the release diskette. Thanks for the suggestion- ...cheath Theme: ARP LIST & LFORMAT To : CHEATH (r) By : RTSHAW Title: PROBLEM First I must say that arp 1.3 was worth the wait. Its everything I thought It would be & more. I do have a problem with the List cmd, running a script That generates directory icons... Script .... List >ram:test DIRs LFORMAT ="Mkddir %s" This by its self doesnt generate an error. but if I put it in a script file, it doesnt seem to be able to recognize the LFORMAT portion of the scrip. aand the ram:file isn't built. Waithing for the docs, but Arp is very very nice. Add me to the list of Arp users who always wanted arp to be a part of the Wbench pkg. Cbm ( a love/hate relationship) Theme: ARP LIST & LFORMAT To : RTSHAW (r) By : CHEATH Title: R#47523 NO =EQUALS Hmm ... I don't have any }iproblem with LFORMAT here, though I think I see the problem - the ARP LIST doesn't recognize the "=" }iwhich you've shown in your message, just use LFORMAT }i"Mkddir %s" without the equal sign. Looks like an oversight in GADS(), I'll put this on the list to verify for bug reports. ...cheath Theme: ARP LIST & LFORMAT To : CHEATH (r) By : RTSHAW Title: R#47548 LFORMAT Thanks much. Arp1.3 is dynamite ! (I probably already said that) Ron Theme: ARP 1.3 COMMANDS To : CHEATH (r) By : HOWARD A Title: R#47370 ARP RUN In the Amiga conference last Sunday, CBM*HARV said that DiskMaster was having trouble with the ARP "run" command when performing functions such as ARC x. I forget what exactly the problem was but I do remember that it did abnormal (bad) things. I don't know if you have heard of this subsequent to your reply to my posting, but I just thought I would bring it to your attention. Howard Theme: ARP 1.3 COMMANDS To : HOWARD A (r) By : CHEATH Title: R#47551 RUN Harv mentioned the problems with DiskMaster and SupraMount and the ARP Run, but I don't have either so I can't verify what might be happening. Most problems with RUN will be caused by different interpretations of the BCPL operating environment for processes, of which there are many. MANX's make was one of the more unusual/unexpected, but we got that working since Scott and I were both using MANX make. If you have a program which has a problem with the ARP Run, probably your best choice now is to stick with the BCPL RUN, let us know about the problem, and get in touch with the company whose program doesn't work and let them know they're likely to need to revise when V1.4 ADOS arrives - ...cheath Theme: ARP 1.3 COMMANDS To : CHEATH (r) By : DLAURI Title: R#47563 RUN >NIL: ?? One problem I had with the Ashell run was that it ignores i/o redirection. When I would say "run >nil: program" it still would output the shell process number. I fixed it by aliasing run to C:run, which does redirection properly. David Theme: ARP 1.3 COMMANDS To : DLAURI By : CHEATH Title: R#47576 WHEN ISN'T REDIRECTION Hmm, AShell does redirection OK, but doesn't know about redirection when the process number is being displayed in a couple cases. Glad you found a suitable workaround with the Alias to C:RUN. ...cheath Theme: ARP 1.3 COMMANDS To : CHEATH (r) By : HOWARD A Title: R#47563 I'LL TRY ARP RUN Thanks for the quick response I also have SupraMount, I will give the ARP run a try in DiskMaster and post the results Howard Theme: ARP RUN To : CHEATH (r) By : HOWARD A Title: I TRIED ARP RUN I loaded ARP run into c: (after renaming AmigaDOS run and making sure run was not resident). I then used DiskMaster to ARC and un'ARC some files. There were no problems! Howard Theme: ARP RUN To : HOWARD A (r) By : CHEATH Title: R#47583 THANKS Thanks for the report with DiskMaster, Howard ... sounds like it's time to get DiskMaster and check in with Harv to see if we can figure out what's up. I was a bit suprised to've heard of a problem there, since one of our beta-testers works for PP&S, but maybe something else caused the problem... ...cheath Theme: ARP RUN To : CHEATH By : CBM*HARV Title: R#47599 ....DUH The problem I had with DiskMaster after installing ARP 1.3 was most likely due to "user stupdity." I replaced ARP's "run" with AmigaDOS 1.3 "run" and then left you that note. I put ARP's "run" back on and see if the problem is gone or not. Harv Theme: ASHELL To : CHEATH By : LENW Title: '?' AND CLI EDITING Still getting into ARP 1.3, and have just two more questions (I hope). When I start "AShell", and type '?' to find built-in commands, all I get is 'Invalid Command'. Also, the Commodore shell had command line editing. It doesn't seem to be in ASH. Do I need to use ConMan for this? Thanks for the help. Len W. Theme: ASHELL To : LENW By : NY*JIM Title: R#47627 USE NEWCON: OR CONMAN I could kick myself for not remembering what you did wrong to get an ashell that doesn't respond to ? - I did the same thing myself when I first installed ARP. I *think* that may be due to not having ASH in L: - for line editing, though, you need either conman or Commodore's newcon: console handler. Jim Theme: ASHELL To : NY*JIM (r) By : XTAL007 Title: R#47653 KEEPING CONMAN I just installed Arp1.3 myself, which is the first time I've ever used an Arp. That install program is fantastic! Now my only question is, and I've seen it answered before (I think), is how I retain the nifty Conman history and line editing when I open a new window. (Or shell, which I haven't used yet.) Thanks. Theme: ASHELL To : XTAL007 (r) By : MINOTAUR Title: R#47673 KEEP CONHANDLER... XTAL: Keep conman's ConHandler in your L: directory, and in your MountList, make your NEWCON entry "Handler = L:ConHandler". Your command history will be retained, even though you aren't using Conman itself. Mine is working that way, at any rate. Frank Theme: ASHELL To : MINOTAUR (r) By : WALRUS Title: R#47676 CONMAN VS. NEWCON Frank, see the message I just posted to LGREEN. -Joel Theme: ASHELL To : XTAL007 (r) By : WALRUS Title: R#47673 CONMAN DOESN'T NEED NEWCON John, if you have ConMan installed correctly and call it in your startup-sequence, any new CLI or Arp Shell will have ConMan's command history and line editing features. Don't need NEWCON: anymore. Joel Theme: ? To : CHEATH By : STEVE*G Title: R#47600 THNAKS Thanks for the help. I'll give it a try and let you know what happens. Steve Theme: ? To : CHEATH By : STEVE*G Title: R#47600 YOU WERE RIGHT. You were right. It was the time stamp. Now I just have to figure out why it is doing it. (Although I got around the immediate problem by copying over files.) Seems, like it gives an stamp only occasionally. The things I am learning with a harddrive. Thanks, STeve Theme: RUNBACKGROUND RESIDENT? To : CHEATH By : OHS825 Title: WHEREFORE ART THOU RUNBACK?? Chas: Will you explain something for me? I downloaded Arp1.3, ran the ArpInstall on it with a pristine copy of a WB 1.3 disk. I've used it hard for a week and like you say, it is completely transparent so far. The power it affords, ie: wildcards, Move, and the pipe operator, sort of makes the CBM 1.3 set look very MSDOS-like by comparison. I took the PD "RunBackGround" program, made it resident with ARes, and used Protect to set the pure bit. I cause ARes to make about 8 commands resident very early in the startup script, including RunBackGround. During the script, I call RunBackGround at least 4 times, sometimes just because of its built-in delay. After booting, I employ QMouse (priority doctored to 5) to bring up an AShell. If I type "ARes ", there on the list is RunBackGround with all the others. Only it reports it was never "called". I know darn well it was used several times. Other commands, mount, cd, assign, are properly reported. Why can't RunBackGround be found? I took the liberty of putting J. Goodnow's REZ program and its library on my disk, and used a call to REZ instead of Ares. Guess what?? Same phenomena. I'm not complaining. I just want to learn something if I can. Thanks and regards. Tom Eshelman OHS825 Theme: NEW ARP COMMANDS To : CHEATH By : HOWARD A Title: NEW ARP COMMANDS I have just successfully installed the new ARP 1.3 commands. Maybe you can answer a couple of questions On Page 2 of the ASH manual it mentions replacing Resident CLI L:Shell-Seg... with Resident CLI L:ASH... I left out this line and when I type newcli or newshell, ashell kicks in (which it is supposed to do). The question is why would someone want to put in the "Resident CLI L:ASH..." in the startup-seq? Doesn't anything that looks for newshell work fine (or better) with ashell? I also noticed that I can now use TimeSaver (Help up-arrow) in ashell. This was not possible in newshell. The nice thing about it is newshell only remembered commands that were typed in that specific shell. The other question is what are: BaseName, Cmp, Read, TackOn? Thanks Howard