to_stdnet@stag.UUCP (04/01/89)
From: omni!emh@stag.UUCP (Eric Hopper)
Organization: Omnifarious software.
When using a shell program on the ST, I can't seem to delete a
directory without going into it first. Before I go into the directory, it
gives me a "directory not empty" message. I know the directory is empty
though, because when I do go into it, and then back out, I can delete it
just fine.
I am pretty sure this is a TOS bug, and not a bug in the shell I'm
using, could anybody enlighten me?
Thanks,
Eric Hopper (Omnifarious) Don't try to send to emh@omni.uucp, because omni
is completely unkown to any system except stag.
omni!emh@stag.UUCP or ....{rosevax, ems, umn-cs}!pwcs!stag!omni!emh
/*****************************************************************************/
/* All opinions presented here are the result of my enviroment, or heredity. */
/* If you don't like them you only have yourselves or my parents to blame. */
/*****************************************************************************/
\**************************/ /)
__ \* "I went insane to */ //
/ ') \* preserve my sanity */ // __. __ o ____. . _
/ / ______ ____ o \* for later." */_//__(_/|_/ (_<_(_) (_/_/_)_
(__/ / / / <_/ / <_<_ \* Ford Prefect */ />
\****************/ </
/****************************************************************************/apratt@atari.UUCP (Allan Pratt) (04/04/89)
In article <763@stag.UUCP> to_stdnet@stag.UUCP writes: > From: omni!emh@stag.UUCP (Eric Hopper) > Organization: Omnifarious software. > > When using a shell program on the ST, I can't seem to delete a > directory without going into it first. Before I go into the directory, it > gives me a "directory not empty" message. I know the directory is empty > though, because when I do go into it, and then back out, I can delete it > just fine. Yes, this is a GEMDOS bug. In fact, if you try to delete the subdirectory twice, the second time will work, even if you don't "go into" the subdir. It's fixed completely in TOS 1.4. In fact, lots of trouble can happen if you get a disk error or even disk full during a mkdir operation; now those things are not harmful (or at least much less harmful). ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
ignac@electro.UUCP (Ignac Kolenko) (04/05/89)
while we're on the subject of TOS bugs, here's a couple that i find peculiar: when you install an application on the desktop (you know, click on a program, go to the menu entry for install application, type in the extender for the program and click install), and then click on a file with the correct extender for that application, the desktop seems to stick in a carraige return into the commandline for that application. 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. is this something that is always gonna be there, or is it a bug in the original TOS roms?? TOS 1.4 fix/change it??? also, say you were in a couple of subdirectories deep on a drive, and click on a file with the correct extender for that application. what seems to happen now is that the desktop will do a pexec load call to load the program into memory, change directory back to the directory containing the file you clicked on, and do a pexec go call. is this a correct assumption?? (this is based upon the fact that only the filename appears in the commandline in the basepage, NOT the complete path to the filename!!) if it is true, will this mannerism change in the future?? it is a nice feature if it is true! -- 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!"
apratt@atari.UUCP (Allan Pratt) (04/06/89)
In article <460@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: > when you install an application on the desktop (you know, click on a program, > go to the menu entry for install application, type in the extender for the > program and click install), and then click on a file with the correct > extender for that application, the desktop seems to stick in a carraige > return into the commandline for that application. > > 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. Note that this convention is violated by MWC: they put $7f in the command line length byte (and null-terminate the real command line) to indicate that ARGV is in the environment. See the discussion going on in this newsgroup for more on that. > also, say you were in a couple of subdirectories deep on a drive, and click > on a file with the correct extender for that application. what seems to > happen now is that the desktop will do a pexec load call to load the program > into memory, change directory back to the directory containing the file you > clicked on, and do a pexec go call. is this a correct assumption?? > (this is based upon the fact that only the filename appears in the commandline > in the basepage, NOT the complete path to the filename!!) if it is true, > will this mannerism change in the future?? it is a nice feature if it is true! Your reverse-engineering of what goes on is admirable for its complexity. The truth is that you can call Pexec (or any other GEMDOS function) with a full-blown pathname to the file in question, so no changing of directories is required. What you see on the screen or in your command line and what got passed to GEMDOS can easily be two different things. 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 know what happens in original TOS or Mega TOS, but TOS 1.4 "tops" that window before starting the installed application, making that the current directory. This is for clicking documents for installed applications only: if you use the right button to double-click an application outright, the current directory is still the top window. 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. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
sylvia.jumaga@canremote.uucp (SYLVIA JUMAGA) (04/07/89)
Talking about TOS bugs... I'm not certaibn exactly how well known this bug is, but anyways... While in a GEM driven program (E.g. MicroSoft Write. Excellent word processor- I use it all of the time.) get an Item Selector. Cursor up to the drive path line, and type an underline character. Nice little bombs, eh??? Note- Don't try this BEFORE you save your current file!!! This causes a complete system crash, and forces you to re-boot. 'Till later, -Sylvia Jumaga... "The visible creates a work in form- The invisible defines its worth" Lao Tse - Tao Te King * QNet 1.03a2: Bert's Bulletin Board. Brandon, Man. --- MaS Relayer v1.00.00 Message gatewayed by MaS Network Software and Consulting/HST Internet: sylvia.jumaga@canremote.uucp UUCP: ...!tmsoft!masnet!canremote!sylvia.jumaga
ignac@electro.UUCP (Ignac Kolenko) (04/07/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!"
saj@chinet.chi.il.us (Stephen Jacobs) (04/08/89)
In article <465@electro.UUCP>, ignac@electro.UUCP (Ignac Kolenko) writes: [A lot of good stuff from Ignac, Allan & Ken] > >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. This brings up the question of where a program really should search for its resource file. The question doesn't have a self-evident answer. As stated, present behavior seems to be 1)current directory; 2)A:\. On the surface, it looks reasonable to search the path, but suppose there's another resource file with the same name earlier in the path? (this is easy to do while programming--one tends to experiment in subdirectories). So maybe find the first program in the path with the same name as the program doing the search, and look for the resource in the directory that contains it. Or maybe there should be an environment variable (like PATH=) (maybe RSPATH= ?). Anyone have any strong feelings? Steve J.
ignac@electro.UUCP (Ignac Kolenko) (04/09/89)
In article <8170@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: > This brings up the question of where a program really should search for its >resource file. The question doesn't have a self-evident answer. As stated, >present behavior seems to be 1)current directory; 2)A:\. On the surface, it >looks reasonable to search the path, but suppose there's another resource >file with the same name earlier in the path? (this is easy to do while >programming--one tends to experiment in subdirectories). So maybe find the >first program in the path with the same name as the program doing the search, >and look for the resource in the directory that contains it. Or maybe there >should be an environment variable (like PATH=) (maybe RSPATH= ?). Anyone >have any strong feelings? > Steve J. as far as i have heard, tos 1.4 is supposed to search the PATH= environment variable to do a resource load. i think this is why it searched the current directory and then drive A for resource files: the default path for the older tos'es was PATH=<0>A<null termination>. thus, the current directory and drive A was searched by TOS. i haven't actually tried, but i think that setting up a proper PATH= search path should properly search for resource files for any file. is this true?? has anyone tried this using the older tos 1.0, or the newer tos 1.4??? i've been using tos 1.4 with gulam (since laser C doesn't run with tos 1.4, and the atari resource construction set CANNOT, i repeat, CANNOT find it's resource file using the PATH= variable under gulam. can anyone out there confirm this??? i don't want to clutter *every* subdirectory on my harddrive with RCS2.RSC and its corresponding configuration file. (as an aside, why didn't atari include the resource file *inside* the resource construction set program itself. the program includes an option to create *.RSH files, so why didn't atari use this option. this would save plenty of hassle regarding the searching for the resource file!!!) oh well, enough for now! :-) -- 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!"