Almathera Ten Pack 3: CDPD 3

home *** CD-ROM | disk | FTP | other *** search

/ Almathera Ten Pack 3: CDPD 3 / Almathera Ten on Ten - Disc 3: CDPD3.iso / scope / 051-075 / scopedisk52 / tutor / ci < prev next >

Wrap

Text File | 1995-03-19 | 17.5 KB | 437 lines

Well, you've gotten this far so you're on the right track. /* At this time, give thanks to Ken Goecke for having written the excellent program READER that you'll be using for these sessions!! */ You can use it's menu to change to colors and scroll speed. The buttons are self-explanatory. ________________________________________________________________________________ Getting started Wouldst that there was a single string we could take hold of at this point, one that would take us all the way through to the end: your understanding how to make your Amiga "sing" from the CLI. There's not! I, for one, wish this had been the case for I have dearly struggled! Also, if this had been the case, there probably wouldn't have been any need for all this and it would have saved me hours of typing, a skill I also lack. So we're faced with a sort of electronic Gordian Knot. We have to start somewhere and have to get to the end, somehow. The beginning is the worst since there are several things that interrelate and form the basis for enlightenment, as we are forced to deal with it. I've used "The AmigaDOS Manual, Second Edition", Bantam Books, 1987 and "AmigaDOS User's Manual", Commodore-Amiga, 1985 ,both by Tim and Jessica King as general references throughout my experience with the Amiga and would suggest that if you don't have these books already, buy them!! This tutorial cannot go into everything, frankly I'm doing this out of love of the Amiga and it's cutting deeply into my messing around time. I suspect that places where I may be ambiguous could be cleared up with a little reading and some time experimenting at the keyboard. During the testing of this tutorial, various comments were made that I should install one or another "SunMouse" or automatic window activator programs to make it easier. Well, sorry! You're going to have to activate the window you want to type in manually. Even though I have one of the aforementioned style programs installed on my workbench, one still has to remember to move the pointer into the right window. Therefore, pay attention! Read the instructions and follow them. If they say to type a command into the top window, please do it and don't type it into the bottom one. This is primarily due to the fact that READER doesn't have a drag bar and will cause you more problems than simply making sure you're typing into the right window before you hit <RETURN>. If you don't already know, to activate a window, simply put the pointer in it and click the left mouse button. For those of you who wish I'd used shorter textfile names...it's good practice making sure you type the right thing. Due to the other demands on my time while writing this, I didn't always reconstruct the entire section I was working on in RAM:. Therefore there may be a place or two that I forgot to mention a file in the list of what you should expect to find. Well, aren't you glad we're not doing brain surgery? But, if you bring the specifics to my attention, I'll correct them. It's surprising that in spite of proof-reading something, after a while you SEE what it's SUPPOSED to say and not's what's actually there. I've done my best to present these concepts and MY experiences with them as best I can. If you're more experienced than I and discover errors or have a better way to explain something while looking over the shoulder of one of your charges, please let me know. I can be reached either by E-mail to Hemonculus, on PLINK, or by "rainorshine" express to: Jeff Petermann 151 Bunker Hill Rd Fayetteville NC 28314 So, let's get on with it... ________________________________________________________________________________ So here are the ground rules... ...and some funky syntax I've used.. Phrases with "/*" and "*/" around them like /* this */, are comments and as such will only cause error messages if typed in at the CLI prompt. /* Obviously, you shouldn't do it then! */ Phrases that begin with ">>" are meant to be typed in at that prompt in your LOWER window! They will be as exact as I can make them allowing for the fact that I don't know specific names of disks and files that you might have. That shouldn't be too much of a problem since we'll be working with this disk only. Phrases that begin with "BS>" should NOT be typed into the CLI. They illustrate syntax only. Phrases enclosed by "<>" should be considered representations of the literal key. ie: <ESC>-the escape key, <SPACE>-the space bar, <CTRL>-the control key, etc. Some basic definitions: FILENAME: a wildcard /* a symbolic representation that's used to match anything */ that matches a specific, but unnamed file we may use as an example. Files can be machine language instructions /* binary, hexadecimal, etc */ or text. Amigas use ASCII /* American Standard for Computer Information Interchange */ key codes. These codes tell the computer what letter to "print" on the screen as it "reads" a text file..it's rather stupid, it only knows 1's and 0's. So when it reads the number "65" it will print "A", etc. /* Some word processors save their files in their own format and therefore aren 't pure ASCII /* pronounced "ass-key" or "ask e", if you prefer */. Files, no matter what the format, are the molecules of our world and the smallest unit of data we can retrieve at this level of skill. DIRECTORY is a user-definable area of storage. Though not REQUIRED for your work, just like the drawers /* which IS another term you might hear referring to a directory */ in a filing cabinet, they almost always simplify you're being able to locate and recover data. A directory can contain both files and sub-directories. The disk itself is a directory /* !!! */ and therefore the maximum size of any one directory, given the current technology is 880k bytes /* minus the various overhead */. DISKNAME is a generic wildcard used to match the name of any disk we might be talking about EXACTLY as it appears under the disk icon /* upper right-hand corner of the workbench screen, unless you've changed it's position */ or as it appears in the far right-hand column if you type in the command INFO at the prompt. Try that in your lower window now: >> INFO /* you'll notice that RAM: doesn't have anything in the far right column. So we'll just call it RAM: */ CLI: what it is and what it isn't What the CLI is is the interface between you and the operating system. All computers have some sort of operating system (OS) that enables them to store data somewhere and, probably more importantly, find it again. That's all it is. No one "programs" in CLI! In spite of the necessity to carefully think out what you're trying to accomplish with any BATCHFILE and making sure that the steps are in the right order, you're only practicing for the moment when you spread your wings and start writing in assembly language, C, or Basic (or whatever!). A single line from any of the programming languages, typed into the CLI, will not generate usable results. A single line taken from a batchfile will...almost all of the time. Programming languages require an intermediary process to make them useable. C needs to be compiled, assembly needs to be assembled, basic needs it's interpreter. CLI commands were written in BPCL /* Basic Combined Programming Language, a predecessor of C */ and have already been through the process, as a user, you're just stringing several programs together to create the desired end result. There will be times, while gnawing at your fingernails and wondering why a certain batchfile doesn't react the way you think it should, when you really do believe you're a programmer. Just don't tell someone that makes a living at it. To continue, Whenever you type in a command at the ">>", an Amiga goes through, roughly, the following steps: 1. It "reads" the line you've typed in 2. It looks along the PATH /* not to be confused with PATHNAME!! */ to find the command you specified. The command is the first word in your line. 3. When it finds the command, it copies it to RAM: and performs whatever operations are required. 4. Upon completion, it erases the command from memory and checks to see if you've given it something else to do..if there's nothing, the prompt comes back. /* From here forgive me if I seem to be skipping around but there are a lot of interrelated points to bring up. */ Current Directory The first concept to consider is "current directory". This is simply the directory that AmigaDOS is currently considering "home". It's sort of an electronic "bookmark" maintained by AmigaDOS to keep it's place and so it knows what it can "see" at any given time. This is important for several reasons. First, AmigaDOS looks in this directory for any command given through the CLI before going further along the path (ya, I remember, we're getting to it!). Secondly, some programs write the results of their labors to the current directory. This may or may not be where you want them and you'll have to plan your attack accordingly. And some programs require that they be able to find certain data in the current directory. Conveniently enough, the command that allows you to determine the current directory or change it is called "CD". >> CD /* After boot-up, should have been told "DF0:" */ Whenever you type in "DIR", you get a listing of the current directory. >> DIR /* you'll get a listing of everything that's in the root directory of Tutor: */ >> CD examples >> DIR First (dir) /* See what I mean? */ text >> CD df0: Two quick items of interest here. First notice "examples" doesn't have any ":" or "/". Since it's in the current directory, it doesn't need them. Second, the CD status can be changed back to the root directory either by DISKNAME or by simply using the device name. >> CD Tutor: /* I'm going to begin putting in the results you should expect rather than keep repeating "You should have gotten..." */ One more point, if you forget to specify the proper PATHNAME AmigaDOS will only look in the current directory and if it fails to find the object of the search there, it will give you an ERROR 205 message (object not found) PATHNAMES "PATHNAME" refers to the name of the disk, any and all directories, and the FILENAME. /* the FILENAME might be tacked on the end like PATHNAME/FILENAME if I happen to know what we're looking for */ For a computer to be able to find anything, you have to tell it where to look. It's only fair. The way your Amiga knows how to find things is that you tell it by means of punctuation where it has to look. A colon ":" is used to tell it when it's supposed to be looking for/on a device /* like df0:, df1:, ram:, etc) */. Directories are followed by a slash "/" /* it's the one on the key with the question mark not to be confused with the backslash "\" next to <BACK SPACE> */ These two characters are the ones you'll need to be concerned with when entering commands in the CLI. All the other characters can be used in valid FILENAMEs, though experience might steer you away from some of them. Spaces <SPACE> can be used, but you'll have to enclose the lines in quotation marks """ and since they're way more painintheass than they're worth, should be avoided. The underscore "_" is a good replacement if you want to separate words in a name like: My_Directory/This_File. Upper and lower cases are ignored except when COPYing something /* COPY will name the destination file whatever you type in */. And while we're talking about typing. Spelling is of paramount importance!!! There is a world of difference between /* look at them closely */ "df0:" and "df0"!!! "df0:" means a device whereas "df0" could be anything, but "DF0:", "dF0:", Df0:", and "df0:" all mean exactly the same thing. So by PATHNAME, I mean: device:directory/subdirectory/subdirectory/filename or whatever combination will get you to the file you're going after. Some examples of various PATHNAMEs on the workbench disk we're using: df0:devs/printers/generic df0:s/startup-sequence Tutor:CLI You can tell they all start with a device (or drive) or diskname, some have one or more directories in them, but ALL of them end with a single FILENAME. Now consider Tutor:. How many different ways are there to find out what's on that disk? Or how many different PATHNAMEs do we have to it? >> CD df0: >> CD Tutor: /* just making sure! BTW, notice that when you first typed in CD AmigaDOS told you "DF0:" and now even after CDing TO DF0: it tells you the DISKNAME */ >> DIR /* looks at the current directory */ /* You should have gotten a listing of what's on the disk. Since a disk meets all the requirements of a directory, this is some times referred to as the "root" directory. */ >> DIR Tutor: /* looks by DISKNAME */ >> DIR sys: /* looks at assignment */ >> DIR df0: /* looks in the device */ That took a while but it proved my point. Those are all valid PATHNAMEs to the same place, but not all things are that easy...but you expected that. Now try: >> CD examples/first >> DIR Hi_there In this second instance, I might have said PATHNAME/Hi_there if YOU knew what the PATHNAME was. >> CD Tutor: /* so I don't get confused */ BATCHFILE is a textfile that contains a series of CLI commands that performs some certain operation/operations. Although similar to a program, a BATCHFILE is stored as text that can be edited at will where programs are, generally, stored as hexadecimal or binary numbers. The startup-sequence in the Tutor:s directory is a BATCHFILE. Accepted Conventions [] square brackets indicate optional information, but can provide useful data to AmigaDOS as to how you want an event handled. | vertical bars indicates alternatives. On-Line Assistance The AmigaDOS commands are written so that if you don't remember the correct syntax for a command, you can type the command followed by a question mark "?" in at the prompt and get a usage message: BS> COMMAND ? This sounds great, but the messages are sometimes pretty cryptic. For example: >> LIST ? DIR,P=PAT/K,KEYS/S,DATES/S,NODATES/S,TO/K,S/K,SINCE/K,UPTO/K,QUICK/S: We're not going to get into this particular command right now, but we will have a quick look at what information can be extracted from the help statement. At the start of the line, you'll see "DIR", that means "what directory do you want to have LISTed. If you wanted to know about df0:s, you'd type: BS> LIST df0:s The equal sign "=" between the "P" and "PAT" is used to denote an abbreviation that AmigaDOS will recognize. The rest of the line is taken up by words followed by a slash "/" and a single letter. The "/letter" tells you how the preceding word is treated by the command. /S means a switch. If you use the word in the command line, without the "/S", that tells AmigaDOS to "turn on" that particular option. A "/S" option is not required for the command to work and takes no additional information. /K means a keyword. This will tell AmigaDOS that it needs to process the result in a certain manner, as specified by the word you use. A keyword MUST be followed by additional information for the command to function properly. For example, the keyword "TO", how could you expect the command to work if you didn't tell it where you wanted the information sent? /A means an argument. This is used to indicate information that will assist AmigaDOS in determining what to do. These are your parameters. The "/A" WORDS are usually optional and function primarily to make it easier for the USER, not AmigaDOS, to know what's going on, The information that is requested by a "/A" IS NOT OPTIONAL!! Even though LIST doesn't have any "/A" words, they do exist. Let's look at the help line from FILENOTE. BS> FILENOTE ? FILE/A,COMMENT/A: This means that FILENOTE requires that you tell it both the file to want to attach the comment to and the comment you want to attach. BS> FILENOTE [pathname/]filename [COMMENT] your_comment_here I have the "[pathname/]" as an option, since if the file was in the current directory, it wouldn't be necessary. Otherwise, it would be! One last thing before we move on, in the helpful hints catagory, if you TYPE a file and want to be able to read it before it scrolls off the top of the screen, use <SPACE> to stop it. Use <BACK SPACE> to start it scrolling again. That should at least get us off on the same foot. ________________________________________________________________________________ /* get some popcorn time */ If you feel like you need a little visual stimulation at this point, there's a little film on this disk you can watch. Here's how... >> CD film >> projector CLI.film /* or you can just forget it, if you've been following along so far */ ________________________________________________________________________________ Now we'll get into the commands: /* Read the rest of the file BEFORE you perform the actions, if you quit the Reader BEFORE you read the command you'll need to type in, you'll have to scan through this whole file again */ Now, all you need to do is: Select "Return to Main Screen" from the upper window menu /* click on READER somewhere to be sure it's active */ When the screen returns to the normal color, click in the UPPER window and type: Reader CLI_tutorial.1 at the prompt.