Path: utzoo!utgpu!watmath!watcgl!electro!ignac From: ignac@electro.UUCP (Ignac Kolenko) Newsgroups: comp.sys.atari.st Subject: Re: TOS bugs. Disk related. Message-ID: <465@electro.UUCP> Date: 7 Apr 89 16:29:09 GMT References: <763@stag.UUCP> <1426@atari.UUCP> <460@electro.UUCP> <1435@atari.UUCP> Reply-To: ignac@electro.UUCP (Ignac Kolenko) Organization: Electrohome Ltd., Kitchener, ON Lines: 89 In article <1435@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >In article <460@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: >> ie: the commandline buffer in the base page will contain the length byte, >> the the filename clicked on, and then a carraige return before the null >> termination byte. the carraige return does not appear when you run the >> program from the numerous commandline shells in existence. > >The command line is not null terminated. The nulls just happen to be there. ^^^^^^^^^^^^^^^ >The only correct assumption to make is that the command line length byte >tells how many valid characters there are in the command line. You will >notice that an argument like "foo" will give a command line length byte >of three, and the CR is the fourth byte in the command line space. that's interesting. no null termination byte??? here's another tidbit of information to increase the mondo confusion over command lines: In article <1405@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes: > Please excuse the length of this message (nearly a hundred lines - > sheesh!) but I consider Atari's role in setting software standards [stuff deleted] > To quote the Pexec Cookbook (yes Virginia, there is a Pexec Cookbook), > the command tail string is a "null-terminated Pascal-style string." ^^^^^^^^^^^^^^^ > This means that the maximum theoretical length of a GEMDOS command line > is 126 bytes (128 bytes in the basepage minus length byte minus null > terminator). In fact, the *actual* maximum length of a GEMDOS command > line is 125 bytes, because that's the maximum number of bytes that oh well, there's nothing like consistency!!! :-) :-) i hope this new extended commandline standard will properly define what the *normal* commandline is supposed to look like now back to Alan Pratt ... [stuff deleted] >Your current directory when the program starts is the directory where >the file was double-clicked. The argument you find on your command line >is the name of the file which was double-clicked, with no path or drive >information. This has always been true, and it is still true. > >If you use the right button to double-click a document from a window >which is not the top window (did you know you could do this?), I don't ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ yup! >know what happens in original TOS or Mega TOS, but TOS 1.4 "tops" that >window before starting the installed application, making that the [stuff deleted] so basically, the desktop will use the full pathname to the application specified in the desktop.inf file to run the program, and since the current directory is the one where the file resides, there is no need to place the full pathname in the commandline. is that right?? >TOS 1.4 has a new feature in this area: shell_find (which rsrc_load uses >to find resource files) now looks in more places, including the place >where the application was loaded from, even if that's not the current >directory. Therefore an "installed" application will find its resource >file no matter where it lives, as long as the resource file and the >application are in the same place. There are more details in this >area; see the TOS 1.4 release notes for full details. on the topic of this shel_find() call, will rsrc_load() calls from now on in tos 1.4 use the PATH environment variable to search for resource files. is so, thank you. there's nothing more irritating than having a program not able to locate its resource file: up until now, it seemed to have searched only the current directory, then drive A. anyways, thanx for the info Alan. -- Ignac A. Kolenko (The Ig) watmath!watcgl!electro!ignac "Those who can't, criticize" (author unknown) "ain't it ironic that according to Rushton, Suzuki is right!"