) (09/14/89)
I bought some weeks ago a PD program for Amiga. This does not work from WB (You can open the disk but you don't see the content). Thus it must be used from CLI. That was not however possible, because (assume that the name of the original disk is XXX) the name of the disk was of the style "copy 2 of XXX". CLI does not understand or accept the command "DIR copy 2 of XXX:" and if you write DIR DF0: it won't give you the content of any other disk than that one which was used when the system was booted or the CLI opened. Copy 2 of XXX did not have WB or CLI on it. We also don't have any external disk station. It worked when I renamed the disk to for example "XXXX", but I don't understand why the CLI should not accept the same names as WB. Is CLI really so dumb ? The swedish and finnish manuals do not at least give any answer to that ? What is the explanation and how is the format of a working CLI -command to get the directories of other disks ? Jan
ewout@cbmvax.UUCP (Ewout Walraven - CATS) (10/03/89)
In article <3831@vtt.vtt.fi> lucenius@vtt.vtt.fi (Jan, puh 4566511, Lue heti !) writes: >I bought some weeks ago a PD program for Amiga. This does not work >from WB (You can open the disk but you don't see the content). Thus >it must be used from CLI. That was not however possible, because >(assume that the name of the original disk is XXX) the name of the >disk was of the style "copy 2 of XXX". CLI does not understand or >accept the command "DIR copy 2 of XXX:" and if you write DIR DF0: Try DIR "copy 2 of XXX:" If arguments contain space(s), you need to embrace them with quotes, since arguments are normally separated by a space. Since you included both the command (DIR) and the argument in quotes, you specifically indicated just one argument, instead of a command with argument (and you got a "Please insert volume DIR copy 2 of XXX" requester). Each argument (or command for that matter) should have it's own set of quotes, if needed. >it won't give you the content of any other disk than that one which >was used when the system was booted or the CLI opened. Copy 2 of XXX >did not have WB or CLI on it. We also don't have any external disk >station. It worked when I renamed the disk to for example "XXXX", but >I don't understand why the CLI should not accept the same names as >WB. Is CLI really so dumb ? The swedish and finnish manuals do not >at least give any answer to that ? What is the explanation and how >is the format of a working CLI -command to get the directories of >other disks ? > >Jan dir volumename: (or dir "volume name:" if the name has spaces) You may want to copy the commands you need (dir, cd type, etc) to your ramdisk and assign c: to ram:, so you can swap disks more easily (note that if you want to use a command not in ram: you either have to assign c: back to Workbench1.3:c again or include the volume and pathname in the command. I.e. Workbench1.3:c/ed or df0:c/ed if the Workbench is present in the internal drive. ) You'll find more information about this in the AmigaDOS manual, published by Bantam. .ec
cmcmanis%pepper@Sun.COM (Chuck McManis) (10/04/89)
In article <3831@vtt.vtt.fi> lucenius@vtt.vtt.fi writes: > ... CLI does not understand or accept the command "DIR copy 2 of XXX:" > and if you write DIR DF0: it won't give you the content of any other > disk than that one which was used when the system was booted or the > CLI opened. When you want to get a directory listing of a disk whose name has embedded spaces in it, use quote marks. If you had typed : 1> dir "copy 2 of XXX:" It would have worked properly. Also if you will use that disk a lot and you get tired of typing the spaces, you can first assign it a different name with the command : 1> assign XXX: "Copy 2 of XXX:" And then you can look at it with : 1> dir XXX: --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "If I were driving a Macintosh, I'd have to stop before I could turn the wheel."
king@cell.mot.COM (Steven King) (10/04/89)
In article <8057@cbmvax.UUCP> ewout@cbmvax.UUCP (Ewout Walraven - CATS) writes: >You may want to copy the commands you need (dir, cd type, etc) to >your ramdisk and assign c: to ram:, so you can swap disks more >easily (note that if you want to use a command not in ram: you >either have to assign c: back to Workbench1.3:c again or include the >volume and pathname in the command. I.e. Workbench1.3:c/ed or >df0:c/ed if the Workbench is present in the internal drive. ) There are easier ways of accomplishing the same thing. The first (and best) way to put commands into RAM is to use the "resident" command. Type "resident c:commandname" to install the command "commandname" from your c: directory as resident. Resident commands are always there when you need them (no need to swap in your boot disk!) and they take less room in memory than putting the same command on a RAM disk. "Resident" is only available on Workbench 1.3. The second method is to copy the files to your RAM disk like Ewout says, but then to use the command "path ram: add" instead of re-assigning your c: directory. This will add the volume "ram:" to the path AmigaDOS searches when you type a command. If your c: directory isn't on-line (or the command isn't in there) the other entries in the searchpath will be checked for it. This is a LOT easier and less kludgy than re-assigning c: to ram:. PLUS, you can use any command that's in c: but that you didn't put in ram: without another "assign" command. The default startup-sequence ("StartupII" in the sys:s directory) on Workbench 1.3 automatically adds ram: to the searchpath, so all you need to do is copy the desired commands there. /-----------------------------------------------------------------------------\ | I'm very good at giving directions, especially | Steve King (312) 991-8056 | | if I'm giving them to myself, 'cause I know | ...uunet!motcid!king | | what I'm talking about. | ...ddsw1!palnet!stevek | \-----------------------------------------------------------------------------/
tron1@tronsbox.UUCP (HIM) (10/04/89)
>accept the command "DIR copy 2 of XXX:" and if you write DIR DF0:
The correct command would then be
DIR "copy 2 of XXX:"
The reason workbench will understand and CLI does not (without the ""'s) is
that Wokbench is reading that data from the ICOM as one string , ignoring
anythjing in that string until it hits a HEX 00. Sinceyou click on a icon,
there is no way to mistake which disk you mean.
CLI has to work with TYPED commands. Now , the space is commonly used to
seperate commands and options ... so, cli see's
DIR copy of XXX:
as
DIR copy OPTIONS of XXX:
By using the ""'s , yiou tell CLI that everything between them is one word.
****************************************************************************
So Lord, I'd think you more than wise, (and me much less a jerk)
if only once you might supply.....
SOME PENGUIN WINGS THAT WORK!" Opus '83 - 89 R.I.P.
UUCP: tron1@tronsbox.UUCP uunet!mimsy!oddjob!clout!ddsw1!tronsbox!tron1
Sysop, The Penthouse ]I[ BBS - (201)759-8450 / (201)759-8568
****************************************************************************fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (10/04/89)
In article <198@grape3.UUCP>, king@cell.mot.COM (Steven King) recommends
using "path ram: add" to access commands copied to RAM: instead of
re-assigning C:.
That's fine, but be aware that new shells opened from Workbench icons or
PopCLI won't be aware of that path. Path isn't global, although it will be
inherited if you issue a NewCLI or NewShell command from a shell that
already had a path assignment.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3djohnson@beowulf.ucsd.edu (Darin Johnson) (10/05/89)
In article <762@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: >That's fine, but be aware that new shells opened from Workbench icons or >PopCLI won't be aware of that path. Path isn't global, although it will be >inherited if you issue a NewCLI or NewShell command from a shell that >already had a path assignment. However, if you put the PATH statement before the LOADWB, it will be inherited by the WorkBench. I don't know about PopCLI, but getting a CLI from dmouse won't inherit it though. >--Fabbian Dufoe Darin Johnson djohnson@ucsd.edu
marksm@syma.sussex.ac.uk (Mark S Madsen) (10/05/89)
\\\ does the line-eater like straw? /// In article <762@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: >In article <198@grape3.UUCP>, king@cell.mot.COM (Steven King) recommends >using "path ram: add" to access commands copied to RAM: instead of >re-assigning C:. >That's fine, but be aware that new shells opened from Workbench icons or >PopCLI won't be aware of that path. Path isn't global, although it will be >inherited if you issue a NewCLI or NewShell command from a shell that >already had a path assignment. I don't think that this is quite correct. It is true that PopCLI and DMouse certainly DON'T inherit the complete path when you press Left-Amiga Escape. BUT: If you set your path in your startup-sequence, then any Shells which are started from the WorkBench will inherit the complete path, including directories on your boot disk. However, if you issue a command which requires something from an assign directory on the boot disk (say) from a shell, the command will not be found unless that disk is actually in a drive. DISCLAIMER: Not only am I not a guru, but I don't even own an Amiga 879500 with an '09990 card and a 549736546 Gb hard drive, so I am obviously unqualified to make statements about anything more fancy than a TRS-80. >--Fabbian Dufoe Hope this helps, Mark.-- ####################################################################### ## Mark S. Madsen #### marksm@syma.sussex.ac.uk ################### #### Astronomy Centre, University of Sussex, Brighton BN1 9QH, UK. ## #################### Life's a bitch. Then you die. #################
new@udel.edu (Darren New) (10/10/89)
Unfortunately, the IconX program does not seem to inherit the path from the WorkBench. -- Darren