CLI CLIPS
CLI Q & A
JIM BUTTERFIELD
By now you've heard of the introducton of AmigaDOS 2.0. This is the new operating system that succeeds AmigaDOS 1.3. Don't worry: You won't need to learn radical new rules when you switch to AmigaDOS 2.0. The Shell/CLI methods you've learned still apply, and the information given in this column is generally valid no matter what system you use.
Lately, I've been asked a number of questions by readers. Some questions are at a beginner's level; others are more advanced. Let's look at them.
Insert disk. I'm new to the Amiga, with a single-drive system. I'm having trouble dealing with any disk other than my boot disk. When I pop in another disk and type DIR DF0:, the system asks me to put my boot disk back in. A friend suggested that the command CD DF0: would fix the problem, but it doesn't.
When you enter a command, the Amiga must load it into memory from disk. Lacking any special action on your part, the program which performs the command (DIR, CD, or whatever) is obtained from the C directory of your boot disk (the Workbench disk that you inserted when you first turned on your computer). That's why the Amiga asks you to put that disk back in the drive. Once the boot disk is in place, the DIR command is loaded and goes to work on DF0:, which, unfortunately, no longer contains the disk you want to deal with.
Other than buying a second disk drive, there are several other ways to solve your problem. You could specify the name of the disk that you want to examine instead of referring to it as DF0:. If your disk is called MyDisk, for example, you could enter DIR MYDISK:. The computer will still ask you to do some disk swapping, but you'll get the results you want.
A better way is to transfer your favorite commands—such as DIR, CD, COPY, and perhaps a few others—to a location where they can be accessed more easily. The best way to do that (if you have AmigaDOS 1.3 or later) is to use the RESIDENT command. For example, type RESIDENT C:DIR and the DIR command is moved into RAM where the computer keeps track of it. The Amiga won't look for it on the boot disk anymore. You can make your other favorite commands resident, too.
If you're still using Workbench 1.2, you can't make commands resident but can copy commands to the ramdisk to achieve similar results. Enter the command COPY C:DIR RAM: to move DIR into RAM. Now tell the computer where it can find DIR by entering the command PATH ADD RAM:.
There are other solutions, too, as we'll see.
Plus sign. I have seen some scripts where lines end with a plus sign (+). When I enter a plus sign after a command, all that happens is the Amiga waits until I press Return a second time. Is there any point in this?
The plus sign isn't extremely useful; it tells AmigaDOS that the current line is not yet complete and that more information may be found on one or more of the following lines. With scripts, it helps the writer enter long lines neatly.
The plus symbol can be useful for single-drive owners. If you type a command line such as DIR +, the system will load the directory command and then wait for the rest of the instruction to be entered.
So another response to the earlier question is this: You can type DIR +, reinsert your boot disk when the computer asks you for it, wait until the DIR command has been read from that disk, insert the disk you're interested in, and, finally, type DF0: to complete the command.
Exactly the same method may be used with the question mark (?) in place of the plus sign. In this case, the computer prints a command template and then waits for more information. Once again, this two-step process gives you the chance to swap disks before the DIR command is actually executed.
DiskDoctor. I recently got the system message Disk Structure Corrupt—Use DiskDoctor. What is this DiskDoctor, and how do I use it?
DiskDoctor is a CLI command that examines and attempts to repair bad disks. If you have a hard disk or two floppy disk drives, you might prefer to use other utilities, such as DiskSalv, a freely distributable program by Dave Haynie.
The DiskDoctor command comes with your Amiga (it's in your C directory). You must use it from the CLI or Shell. You put DiskDoctor to work by typing a command such as DISKDOCTOR DF0:.
The good part about DiskDoctor is that it works on a single-drive system, so virtually anyone can use it. The bad part is that it makes changes to the disk as it attempts to correct its data. Other utilities, which copy files from the bad disk onto a separate disk, leave the original disk untouched.
If you use DiskDoctor, there are a few things to keep in mind. First, if the disk is physically defective, there's no hope that it can be fully corrected. Second, if the program cannot find the name of the defective disk, it will substitute the name Lazarus (that's the fellow who was raised from the dead). Third, if at first you don't succeed, try, try again. DiskDoctor may correct things on the second (or third, or fourth) run that it couldn't fix the first time around. Fourth, don't be surprised if some files you previously deleted come back from limbo. Finally, after your disk has been doctored, be sure to copy all of the files to a new disk with the COPY ALL command. And just to be safe, throw the old corrupted disk away.
Disabled CLI, To save time and mouse clicks, I like to load programs from the CLI and/or from the startup-sequence. I do this by typing the program name, sometimes followed by the name of a data file. But these programs seem to disable the CLI. Although the CLI seems to be in perfect working order, the commands that I type aren't executed when I hit the Return key.
When you type the name of a program (and every CLI command is a program), the CLI is put to work running that program. Because of this, the CLI isn't available for other jobs. But there's a way to free the CLI for other work, if you wish.
Simply prefix your command with the word run. The Run command sets up a fresh CLI process for the program you specify, leaving the existing CLI free to take on new tasks.
Thus, the command ED DATAFILE commits the CLI to running the editor program ED. Until it has finished, the CLI is unavailable. In contrast, RUN ED DATAFILE starts the same program but leaves the original CLI free for further use.
CLI clutter. I know that RUN starts a separate task, but that doesn't help much in some cases. For example, RUN DIR DF0: ALL pours its output into the CLI window and doesn't let me get a command in edgewise. Is there some way I can spin off commands that run in a completely separate window?
There are several ways to do this, depending on your objectives. The most obvious way is to redirect the program's output to a separate window, using a command such as RUN DIR >CON:0/0/300/150/MYWINDOW DF0: ALL. You may not find this one too useful, since the window disappears the moment the DIR program is complete. It might be better to direct the results to a RAM file with a command such as RUN DIR >RAM: MYFILE DF0: ALL and then use your favorite text reader or file editor (More, Ed, MEmacs, or whatever) to read the file at your convenience.
By the way, did you notice that the greater-than redirection symbol (>) is placed after the Dir command rather than after Run? That's important, since Run produces only a single line of output, such as [CLI 4]. No point in redirecting that We want to redirect Dir's output, so the redirection instructions must go right after the DIR command name.
There's another way we can set up a separate output window. We can build a script file and trigger it by means of a NEWCLI FROM … command. Try this: type ECHO >RAM: AA "DIR DF0: ALL". This creates a one-line script file in the ramdisk called AA. Now we invoke the script file with NEWCLI FROM RAM:AA. A new CLI window will open and the compute executes the DIR command that's found in the script file. That file, by the way, can contain many commands rather than just one.
The simplest way to open a new CLI window, of course, is with the NewCLI or NewShell command. Once open, simply start your job in that window and type ENDCLI when you've finished. The original CLI window remains free for you to use.
Killing .info files. How can I avoid getting .info files for every file saved with WordPerfect, DeluxePaint, Pagestream, or other programs? They use up quite a bit of disk space, and it's a real pain to delete them one by one. Are these files needed? If not, what can be done to avoid them?
The .info files are small compared to the data files they're associated with. I find them handy in reminding me what program created the file and what kind of file it is.
An .info file is often called a Workbench object, mostly because it holds the icon picture that you see when you access the file from the Amiga's Workbench interface. It's rarely needed, but it can contain useful information within its ToolTypes field. To see what I mean, select a Workbench icon for a data file, select Info from the Workbench menu (the Icons menu in 2.0), and examine the contents of the Default Tool and ToolTypes fields. All of this information is held in the .info file. Some .info files contain a lot of information that's used by the program that created it, such as window size, margin settings, and font information.
There are programs that allow you to save files without icons. In the case of WordPerfect, you use the program's Set-Icon option.
If your .info files are cluttering us your directory listings you don't need to delete the icons one at a time. Just use CD to go to the directory you want to clean up and type DELETE #?.INFO to remove all the .info files.
Lost dates. I often reorganize my files by moving them between directories. However, the files lose their creation date after they've been moved. This information is replaced by words like TODAY. How can I keep the integrity of all information pertaining to my files when I copy them to other disks and/or directories?
The Copy command attaches a fresh date to the file unless you use Copy's CLONE option. If you're using the standard Shell-Startup that comes on the Workbench 1.3 disk, you can enter XCOPY and save typing. For example, COPY DF0:FILEA DF2: CLONE and XCOPY DF0:FILEA DF2: both copy FILEA without affecting its creation date.
If you're moving a file within the same floppy or hard disk partition, you might prefer to use the RENAME command, which retains the file's creation date but removes the original file after copying it to its new location Choose between XCOPY and RENAME according to your objectives.
Bad start. When I load programs from the CLI (sometimes from my startup-sequence), they don't always work the same as when I start them from the Workbench. Sometimes I get a different screen size or different colors. Why is this?
Many programs look for a setup file in the computer's current directory. This is where they obtain information on how you prefer the program to look and operate. Before starting such programs from the CLI, be sure to use the CD command to set the default directory to the one in which the program is located—that's where the supplementary setup files are usually found.
When you run a program by double-clicking on its icon, the Work-bench automatically sets the current directory to the drawer in which the program is found. CLI users must set the current directory manually.