UNCKNG@UNC.BITNET ("Kevin N. Gunn") (01/27/89)
Jeremy G. Mereness <jm7e+@ANDREW.CMU.EDU> writes: > BTW if you ever use DOS 3.3, you should precede the Ctrl-D with a linefeed, li > > 120 PRINT CHR$(13);CHR$(4);"CATALOG" : REM dos 3.3 only > I've come across this problem before (and fixed it by issuing a print chr$(4) twice, the first of which is, of course, terminated by a carraige return, thus solving the problem). What I'd like to know is WHY DOS 3.3 NEEDS that carraige return. Carraige return sure is a strange anachronism when applied to a video screen, isn't it? Thanks in advance! -Kevin N. Gunn unckng@unc
labc-3dc@e260-4g.berkeley.edu (Andy McFadden) (01/28/89)
In article <8901270945.aa15170@SMOKE.BRL.MIL> UNCKNG@UNC.BITNET ("Kevin N. Gunn") writes: [previous stuff brutally scrubbed] > What I'd like to know >is WHY DOS 3.3 NEEDS that carraige return. DOS 3.3 only looks for DOS commands at the start of a line. If ctrl-D isn't the first character, the command gets ignored. ProDOS tried to be more intelligent about it; it finds the commands anywhere. However, I believe that issuing a chr$(13)chr$(4)"catalog" while get you nowhere under ProDOS. >-Kevin N. Gunn >unckng@unc -- labc-3dc@widow.berkeley.edu (Andy McFadden) c60c-3aw@widow.berkeley.edu (expiring soon)
patrick@chinet.chi.il.us (Patrick A. Townson) (01/28/89)
In article <8901270945.aa15170@SMOKE.BRL.MIL> UNCKNG@UNC.BITNET ("Kevin N. Gunn") writes: > I've come across this problem before (and fixed it by issuing a >print chr$(4) twice, the first of which is, of course, terminated by >a carraige return, thus solving the problem). What I'd like to know >is WHY DOS 3.3 NEEDS that carraige return. > >Carraige return sure is a strange anachronism when applied to a >video screen, isn't it? It isn't that it needs a LF or CR, but rather, a DOS command <must> be the first command on a multi-command line. A CR insures that the command which follows immediatly is the first command on a line. It is common in Applesoft to print something, and terminate the print statement with a semi-colon, which then will suspend the CR/LF and force the next print statement to begin right at the end of the first one. Depending on the complexity of the code, somewhere along the line you may have left a print statement unclosed in this fashion. If so, and you hit a line of code with a DOS command, then that command will not execute correctly. Setting up D$ = CHR$(13);CHR$(4) right from the beginning of your program insures a new line will be started when you need one in this context. -- Patrick Townson patrick@chinet.chi.il.us / US Mail: 60690-1570 (personal zip code) FIDO: 115/743 / AT&T Mail: 529-6378 (!ptownson) / MCI Mail: 222-4956
AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (01/29/89)
>Date: Thu, 26 Jan 89 15:05:00 EST >From: "Kevin N. Gunn" <UNCKNG%UNC.BITNET@CUNYVM.CUNY.EDU> >Subject: Chr$(4) and Linefeeds > >I've come across this problem before (and fixed it by issuing a print >chr$(4) twice, the first of which is, of course, terminated by a >carraige return, thus solving the problem). What I'd like to know is >WHY DOS 3.3 NEEDS that carraige return. The DOS 3.3 parser just watched characters as they were printed and went into different modes depending on what it saw. Seeing a carriage return (Ctrl-M) made it go into a mode where a Ctrl-D would make it go into collect-a-DOS-command mode. I don't know of a really good reason to require a return right before a command, except that it lets you put Ctrl-D's into your files if you want, as long as they aren't at the beginnings of lines. BASIC.SYSTEM does things in a much more complicated way: It turns on TRACE mode and intercepts all the "#" signs and line numbers that Applesoft prints; when it finds a "#" it checks the stack & zero page to see what's going on, so it always knows what BASIC command is being executed. Things like TRACE and NOTRACE are handled specially, and most importantly it remembers whether a PRINT is in progress or not. Under BASIC.SYSTEM a command is collected only if the Ctrl-D was the first character printed by a PRINT statement. By the way, just PRINT by itself prints a CHR$(13). "PRINT" and "PRINT CHR$(13);" are identical. "PRINT CHR$(13)" (no semicolon) prints _two_ returns. So PRINT:PRINT CHR$(4);"xxxxx" is sufficient to make sure DOS 3.3 sees a command. >Carraige return sure is a strange anachronism when applied to a video >screen, isn't it? > >-Kevin N. Gunn >unckng@unc Yes. So are Line-feed (Ctrl-J) and formfeed (Ctrl-L) (nothing really gets fed on the screen), and Bell (Ctrl-G) (there's no physical bell in most equipment; just a speaker & an electronic noise of some sort). Shift keys no longer shift a tray of keys up or down to let a different part of the metal hit the paper, either. Well, not on the screen or most printers, anyway. --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons
STEIN@UCONNVM.BITNET (Alan Stein) (01/30/89)
>In article <8901270945.aa15170@SMOKE.BRL.MIL> UNCKNG@UNC.BITNET ("Kevin N. > Gunn") writes: >[previous stuff brutally scrubbed] >> What I'd like to know >>is WHY DOS 3.3 NEEDS that carraige return. > >DOS 3.3 only looks for DOS commands at the start of a line. If ctrl-D isn't >the first character, the command gets ignored. ProDOS tried to be more >intelligent about it; it finds the commands anywhere. However, I believe >that issuing a chr$(13)chr$(4)"catalog" while get you nowhere under ProDOS. > >>-Kevin N. Gunn The carriage return is only needed after something is outputted without a carriage return at the end, eg if you have a print statement ending with a semicolon, or after a GET. Unfortunately, the time honored trick of letting D$=chr$(13)+chr$(4) doesn't work with Prodos, since prodos looks only for a ctrl-D at the start of a print statement. (That was an attempt to correct the problem of needing the CR before the ctrl-D, but inadvertantly ruined the time honored fix.) Alan H. Stein Department of Mathematics The University of Connecticut at Waterbury 32 Hillside Avenue, Waterbury, CT 06710 (203) 757-1231 Internet: stein%uconnvm.bitnet@mitvma.mit.edu BITNET: STEIN@UCONNVM UUCP: {rutgers psuvax1 ucbvax & in Europe mcvax} !UCONNVM.BITNET!STEIN Compu$erve: 71545,1500 Genie: ah.stein