nowlin@ihuxy.ATT.COM (Jerry Nowlin) (05/04/87)
This message is a status report on the next version of ash and a request for some answers to nagging little questions I've had for a while. Pay special attention to ? terminated sentences. I've received lots of good suggestions for things to add to ash. I've solved the problem of doing a "rm *.*" and aborting the rm when . and .. can't be removed. Does anyone understand why a getfirst() and getnext() with the *.* file specification will return . and .. but using . and .. directly as file specs fails? I also have I/O redirection for the built-in commands working. One question I have is whether or not users would prefer a distinction between error output and standard output. For example, if you redirect output from a "cat" and the file isn't available for reading, the error message stating this goes to the screen (stderr) instead of the file you directed output to. What do users prefer? Unless I get strong responses the other way I'm leaving stderr pointing at the screen. I also have ash recursing now so that scripts will run with lots less memory. An added side effect is that the environment (PATH, etc.) stays around for scripts no matter how deep they're nested (I increased the stack to 16K and can go 9 levels with no problem). The initialization file is now only executed for interactive invocations of ash and can contain any valid ash commands. This means the ash.ini file can do some initial copies for you to set up your working ram disk for example. I've tried in vain to make the environment available for Pexec()ed programs invoked by ash. Do I hear any suggestions on this one? What kind of format is this environment string passed to Pexec() supposed to be in? I've heard conflicting specifications. Should I be using the _shell_p variable for something? One last query. Since the command tail for Pexec() uses the initial byte as a length, and assuming they don't take negative tails into account, you should be able to have a 255 character command tail with byte 0 of a 256 byte buffer set to 255. It seems that tails longer than 128 don't work. Can anyone shed some light on this one? Ash does wild card expansion (except when arguments are quoted) and while the command line for built-in commands can be up to 255 characters, I can't pass that much tail to external commands. As an aside, it seems the Dosound() call needs the first byte of the command buffer to be a length also and it's documented just as well as the Pexec() call. Moving files (mv) will retain the current time stamp and copying files (cp) will change the time stamp of the newly created file. Anything else seems silly to me but I just thought I'd mention it because there was quite a stir about it a while back. I have added the code to set the keyboard clock when the gemdos clock is set but for some reason while the time is set correctly the date on the keyboard clock is munged up. Any hints? This is the code I use: long kbd; kbd = (gemdos(0x2a) << 16) + gemdos(0x2c); xbios(0x16,kbd); I've also tried it with both gemdos calls cast to longs and still the date is incorrect. I don't have this problem with the gemdos clock. Also, I've enabled the arrow keys to work with command history editing. I don't use them the same way VMS does though. I'm used to ksh history editing so why settle for (much) less on my ST. I have to finish the document before I post this version. It should be out by the end of May. If you can help with any of the ? above please send me mail. Jerry Nowlin (...!ihnp4!ihuxy!nowlin)
dclemans@mntgfx.UUCP (05/06/87)
The length byte in command tails cannot be negative. The command tail is taken from the Pexec call and stored in the base page for a process. The base page is 256 bytes; the last 128 bytes of the base page are used to store the command tail, including the length byte. Thus the maximum length of a command tail is 127 bytes. The commercial shells that allow passing command lines greater than 127 bytes (Mark Williams msh, Beckemeyers csh, etc.) pass the actual command line using environment variables, with the first 127 characters of the command line put into the command tail of the Pexec call for compatibility reasons. As of the latest releases from Beckemeyer and Mark Williams products they have gotten together and agreed on common formats for using the environment strings so that their products can be used in each others environments. The environment strings that they expect look something like "name=value\0name=value\0...name=value\0\0" if I remember correctly. It's documentated reasonably well in their manuals; some of Beckemeyers products even come with the source to example getenv and putenv functions. dgc