jjones@anuck.UUCP (jeff jones) (11/24/88)
I've been reading the net for several months now and I have seen a lot of references to the MKS toolkit package. All of the references have been of a positive nature. I agree with all that I have read because I use the package too, to its fullest extent, and I am completely satisfied. Now, risking third-degree burns over most of my body, I am posting this in a negative light. Am I the only MKS user on the net that finds MKS bugs!!? Recently, I posted an example of what I think is a BUG in MKS. I got no responses confirming or denying the problem. Maybe I expected too much from you MKS users on the the net. I thought I would get a lot of responses when I considered all the ranting and raving I read about this product. I at least expected a response from Mr. MKS, either confirming or denying the problem. I know that Gerry Wheeler (Mr. MKS?) reads this net because he always seems to volunteer his excellent responses to MKS problems. However, the problems seem to have been cases of improper product configuration rather than MKS bugs. Obviously, MKS figures it would be in their best interest not to respond to true bug postings in the hopes that fingers wind up pointing at users rather than MKS. If MKS offers guidance on the net concerning their product, they should also address their product's negative aspects when they come to light. I am now posting what I think are several BUGS in MKS. I am posting them so that fellow MKS users might save themselves some headaches or show me the light if I have errored in my usage and methods. Don't bother sending me alternate ways of accomplishing the same thing as I already have work-arounds for these bugs, I'm just interested in knowing if fellow MKS users concur with these suspect bugs. Hardware setup...IBM AT model 339 (8 Mhz), 512K ram, 30 Mb hard disk, 80287 coprocessor, IBM EGA and IBM EGA adapter with 256K video memory, MS bus mouse. Software setup...PC-DOS 3.2 with Microsoft's patch for floating-point exception handling in IBMBIO.COM. ANSI.SYS and MS-MOUSE.SYS loaded in CONFIG.SYS. MKS Ver 2.2, Configuration 4...full MKS control, COMMAND.COM not even loaded. Nothing exported except the necessaries such as PATH, HISTORY, etc...'set -o' returns only 'vi'; ls aliased to 'ls -xp'; ulimit=2; FILES=20; BUFFERS=20. 1. The length of the pathname to each file seems to cause this bug. This seems to work correctly if the path string in WHERE is only one deep. The goal is to get the FIRST filename in a list of filenames sorted by last modification time. BTW, this worked correctly on an AT&T 6386, but not on the IBM AT-339 (8 Mhz). WHERE=c:/dir1/dir2 #note that there are four .log files under WHERE list=`ls -t $WHERE/*.log` #returns the first path/filename...as expected echo $list | sed 's/ .*$//' #but now try to load it into a variable... #this doesn't load correctly FIRST=`echo $list | sed 's/ .*$//'` echo $FIRST #but this DOES FIRST=$(echo $list | sed 's/ .*$//') echo $FIRST 2. Can't do a change word (cw) on the last word of a command line vi edit. Type 'echo now is the time for all bad' but don't hit CR. ESC and 'h' back to put cursor under the b in bad. Now do a 'cw' to change 'bad' to 'good'. The characters get INSERTED before the space after 'all'. You just can't make 'good' out of 'bad. I know that 'cw' SHOULD enter INSERT input mode, but not when it's acting on the element at the end of the line; then it should enter APPEND input mode. 3. Also during command-line edit, '.' does not complete the entire previous text modification command. Type 'echo here we go again' but don't hit CR. ESC and 'h' back to put cursor under the h in 'here'. Now do an 'i' and enter the character T. ESC and 'l' anywhere on the line and do a '.'...you're put back into insert input mode but it doesn't insert the T and then ESC. 4. Can't ^c out of the command history edit. At the shell prompt, type ESC to kick into command history edit, and then 'k' up a few lines into the command history. Now change your mind and try to get back to the shell prompt. You can't ^c out of it. You have to 'j' or 'Gj' all the way back to the beginning and then CR. 5. Write two simple shell-scripts where one calls the other: SCRIPT1.ksh: junk_var=surprise echo junk_var from script1 = $junk_var script2 SCRIPT2.ksh: echo junk_var from script2 = $junk_var Don't export ANYTHING. Execute script1...well, can YOU guess what script2 outputs for junk_var? It's NOT a null string as it's supposed to be. I wonder if this has anything to do with BUG #1. 6. Cpio won't return the files requested from an input file when given wild card characters. Example: Let all pascal files be fileN.pas under c:/dir1/dir2 Now make the cpio file: find / -type f -newer agefile -print | cpio -o > cpio.arc Now try to get just the *.pas files (won't work): cpio -it "*.pas" < cpio.arc Well, let's hear it from you fellow MKS users. Sorry about the length but at least they're all in one place. Flames Away!!! J. R. Jones att!angate!bill!jjones
tneff@dasys1.UUCP (Tom Neff) (11/25/88)
In article <1361@anuck.UUCP> jjones@anuck.UUCP (jeff jones) writes:
-
-I've been reading the net for several months now and I
-have seen a lot of references to the MKS toolkit package.
-All of the references have been of a positive nature. I
-agree with all that I have read because I use the package
-too, to its fullest extent, and I am completely satisfied.
-
-Now, risking third-degree burns over most of my body, I
-am posting this in a negative light. Am I the only MKS
-user on the net that finds MKS bugs!!?
Perish the thought. :-)
-Recently, I posted an example of what I think is a BUG in
-MKS. I got no responses confirming or denying the problem.
-Maybe I expected too much from you MKS users on the the net.
-I thought I would get a lot of responses when I considered
-all the ranting and raving I read about this product.
This might be a good time to insert Standard Netnews Tip #397: NEVER
assume your article made it around the net! Connectivity is frequently
less than perfect, especially over UUCP, and the seasoned net.user will
often have to repost when things are Suspiciously Quiet after he makes
a query or comment. Don't go apoplectic and assume the rest of us
don't care, when we may not have heard.
-I at least expected a response from Mr. MKS, either confirming
-or denying the problem. I know that Gerry Wheeler (Mr. MKS?)
-reads this net because he always seems to volunteer his
-excellent responses to MKS problems. However, the problems
-seem to have been cases of improper product configuration
-rather than MKS bugs. Obviously, MKS figures it would be in
-their best interest not to respond to true bug postings in
-the hopes that fingers wind up pointing at users rather
-than MKS. If MKS offers guidance on the net concerning
-their product, they should also address their product's
-negative aspects when they come to light.
For someone who is "completely satisfied," the poster is awfully quick
to accuse MKS of machiavellianism! More to the point, netnews is NOT
the way to report bugs to MKS. The Toolkit documentation clearly lists
a netmail address for Mortice Kern, which is:
uunet!watmath!mks!toolkit
If you file a bug report to this address and do not get a response in a
reasonable time, there might be grounds for complaint. Not otherwise.
I have used this address several times and can verify it has good
connectivity.
Even if one has "lost the manual" (cough, cough, cough), knowing that
Gerry Wheeler participates in this newsgroup, one can also glean his
netmail address from the article headers.
-I am now posting what I think are several BUGS in MKS...
- ... I'm just interested in
-knowing if fellow MKS users concur with these suspect bugs...
-Software setup...PC-DOS 3.2 with Microsoft's patch for
-floating-point exception handling in IBMBIO.COM. ANSI.SYS
-and MS-MOUSE.SYS loaded in CONFIG.SYS. MKS Ver 2.2,
^^^^^^^^^^^
Not the current version,
2.3 is many months old.
-Configuration 4...full MKS control, COMMAND.COM not even
-loaded. Nothing exported except the necessaries such as
-PATH, HISTORY, etc...'set -o' returns only 'vi'; ls aliased
-to 'ls -xp'; ulimit=2; FILES=20; BUFFERS=20.
^^^^^^^^
Why bother with this.
-1. The length of the pathname to each file seems to cause
- this bug....
- #but now try to load it into a variable...
- #this doesn't load correctly
- FIRST=`echo $list | sed 's/ .*$//'`
- echo $FIRST
This worked for me every time under MKS 2.3, the current version.
It would have been very helpful if you had mentioned what *does*
end up in the $FIRST variable.
-2. Can't do a change word (cw) on the last word of a command
- line vi edit.
Works for me every time under MKS 2.3, the current version.
-3. Also during command-line edit, '.' does not complete the
- entire previous text modification command.
My results match yours. If it's a bug it's not fixed under 2.3.
-4. Can't ^c out of the command history edit.
This works for me every time under MKS 2.3.
-r. Write two simple shell-scripts where one calls the other:
- SCRIPT1.ksh:
- junk_var=surprise
- echo junk_var from script1 = $junk_var
- script2
-
- SCRIPT2.ksh:
- echo junk_var from script2 = $junk_var
-
- Don't export ANYTHING. Execute script1...well, can YOU
- guess what script2 outputs for junk_var? It's NOT a null
- string as it's supposed to be. I wonder if this has anything
- to do with BUG #1.
Under 2.3 my results match yours. It must have to do with the
way either ksh or echo looks up $junk_var... unlike UNIX, the Toolkit
doesn't actually spawn a new process for sub-shell invocation. It
allocates a new memory block and puts some things in it, including
the exported environment variables and aliases. You would think
the subshell would restrict its search to that, but apparently it
reads the environment segment of its DOS process instead, so still
sees junk_var defined. Probably a Mortice Kern bug.
-6. Cpio won't return the files requested from an input file when given
- wild card characters.
Under 2.3 my results match yours. Apparently when there are path
slashes in the cpio archive's stored filenames, the -i pattern matcher
has coniptions. Probably a Mortice Kern bug.
-Well, let's hear it from you fellow MKS users. Sorry about the
-length but at least they're all in one place. Flames Away!!!
There is no need for flames. This is a good group for dispassionate
bug reporting, you just may have to repost occasionally.
--
Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff
"None of your toys CIS: 76556,2536 MCI: TNEFF
will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)rac@jc3b21.UUCP (Roger A. Cornelius) (11/26/88)
From article <1361@anuck.UUCP>, by jjones@anuck.UUCP (jeff jones): Much stuff deleted - I am now posting what I think are several BUGS in MKS. - I am posting them so that fellow MKS users might save - themselves some headaches or show me the light if I have - errored in my usage and methods. Don't bother sending me - alternate ways of accomplishing the same thing as I already - have work-arounds for these bugs, I'm just interested in - knowing if fellow MKS users concur with these suspect bugs. Info about system configuration deleted - 1. The length of the pathname to each file seems to cause - this bug. This seems to work correctly if the path string - in WHERE is only one deep. The goal is to get the FIRST - filename in a list of filenames sorted by last modification - time. BTW, this worked correctly on an AT&T 6386, but not - on the IBM AT-339 (8 Mhz). - - WHERE=c:/dir1/dir2 - - #note that there are four .log files under WHERE - list=`ls -t $WHERE/*.log` - - #returns the first path/filename...as expected - echo $list | sed 's/ .*$//' - - #but now try to load it into a variable... - #this doesn't load correctly - FIRST=`echo $list | sed 's/ .*$//'` - echo $FIRST - - #but this DOES - FIRST=$(echo $list | sed 's/ .*$//') - echo $FIRST I haven't tried anything like this so haven't had the problem. I'm running Xenix at the moment so can't try it either. - 2. Can't do a change word (cw) on the last word of a command - line vi edit. This one I have had. It's better now though, the previous version (I have 2.3 upgraded from 2.2c) had this problem anywhere on the command line if I remember correctly. - 3. Also during command-line edit, '.' does not complete the - entire previous text modification command. Agreed. '.' only puts you back in insert mode. It doesn't repeat the inserted text as it should. If memory serves me, it won't repeat a case conversion '~' either. This is also true within the vi editor itself, or could be that was the previous version also, I can't remember. - 4. Can't ^c out of the command history edit. This is not true on my system. Do you have 'BREAK=ON' in config.sys? (could be this has nothing to do with it, although I do have it in my config.sys) - 5. Write two simple shell-scripts where one calls the other: - SCRIPT1.ksh: - junk_var=surprise - echo junk_var from script1 = $junk_var - script2 - - SCRIPT2.ksh: - echo junk_var from script2 = $junk_var - - Don't export ANYTHING. Execute script1...well, can YOU - guess what script2 outputs for junk_var? It's NOT a null - string as it's supposed to be. I wonder if this has anything - to do with BUG #1. Haven't tried this one either, but v2.3 had some changes regarding exporting of variables and aliases. I've already deleted the stuff you had above about system config., and forget what version you have. - 6. Cpio won't return the files requested from an input file when given - wild card characters. Or this one. - Well, let's hear it from you fellow MKS users. Sorry about the - length but at least they're all in one place. Flames Away!!! - - J. R. Jones - att!angate!bill!jjones I agree there are some (I'd say minor) problems with the Toolkit, and hopefully they will be fixed in the future. I had the same problem that was recently posted about a user-compiled program being deemed "not-executable" by MKS sh.exe, and when I sent Gerry mail about it, he was more than cooperative. He requested a disk with the files in question on it, which I sent, and I'm waiting for a reply. Roger Cornelius uunet!pdn!jc3b21!sherpa!rac
jls@killer.DALLAS.TX.US (Jerome Schneider) (11/27/88)
Although I e-mailed this to Gerry Wheeler at MKS, I though I would post
it here (in keeping with the spirit of showing both the good and the bad
sides of the toolkit :->). Here are three more bugs (features?).
(I have MKS toolkit Version 2.3b, PC-DOS 3.3, and a clone 386.)
1) When using any of the (reserved) option flags inside a ksh string
compare, i.e. [ "str" = "-x" ], a syntax error occurs that does not occur
under AT&T ksh on SysV.3 (killer). I discovered the problem when trying
to UNSHAR a file with the following script fragment:
if [ "${1}" = "-c" ] ......,;
which was testing for a shell parameter $1 set to "-c" . MKS ksh seems
to interpret the "-c" string as a -c test for character mode file device
type and erroneously issued
test: expression syntax error
Apparently, the MKS parsing algorithm implements a different precedence
for the = operator and the option flags. By changing the "-c" to "c" in
the example, the test works properly, so I think this narrows the problem.
2) inittab ran out of space "file too large" with only 20 lines or so.
Does this mean at inittab can be no larger than one disk sector?
3) A ctrl-break (SIGINT) appears to break init running inittab. To set
up a moderately secure rsh login, it would be nice to trap keyboard
activity during init to assure that mandatory programs are run first.
If I receive anything definitive from MKS, I'll post to the net.
carroll@s.cs.uiuc.edu (11/28/88)
/* Written 6:50 pm Nov 25, 1988 by rac@jc3b21.UUCP in s.cs.uiuc.edu:comp.sys.ibm.pc */ [bug report], and when I sent Gerry mail about it, he was more than cooperative. Roger Cornelius uunet!pdn!jc3b21!sherpa!rac /* End of text from s.cs.uiuc.edu:comp.sys.ibm.pc */ This is the key here, as tneff mentioned. Send bug reports to MKS. No software is perfect, and even though I've raved to people about MKS, I'll stand up and say 'Yes, there are bugs'. What did you expect? What makes it acceptable is that 1. There aren't all that many, and they tend to be minor, and 2. MKS has been very cooperative (to me) about bug reports. So, when you find things like this, send them in.
wheels@mks.UUCP (Gerry Wheeler) (12/03/88)
There have been a couple of messages recently pointing out some problems in our software. We have looked into each point, and resolved each as necessary. > From jjones@anuck.UUCP (jeff jones) Wed Nov 23 11:41:22 1988 > Message-ID: <1361@anuck.UUCP> > > I at least expected a response from Mr. MKS, either confirming or > denying the problem. I know that Gerry Wheeler (Mr. MKS?) reads this > net because he always seems to volunteer his excellent responses to MKS > problems. Mr. MKS? Not quite. :-) Jeff pointed out several items, which I've deleted for space reasons. Several had already been fixed since the version he has was issued, and the others have now been fixed and will appear in the next release. If you want to get an update, Jeff, give us a call or drop me a line. > From jls@killer.DALLAS.TX.US (Jerome Schneider) Sun Nov 27 05:38:49 1988 > Subject: Re: MKS BUGS > Message-ID: <6244@killer.DALLAS.TX.US> > > Although I e-mailed this to Gerry Wheeler at MKS, I though I would post > it here (in keeping with the spirit of showing both the good and the bad > sides of the toolkit :->). Here are three more bugs (features?). Jerome's points have also been fixed up, except for the size of inittab. It does have a limit of 1K + 100 bytes, because of the need to keep init as small as possible. In many cases, programs which do not remain resident can be loaded from /etc/rc.ksh instead, which has no size limit. We appreciate these items being pointed out, no matter where, as we do like to keep the Toolkit up to date. However, I think email would have been a better choice for some of this. For one thing, we won't miss reading an email message. And there seems little point in broadcasting to many thousands of people news of bugs that have already been fixed. Our usenet email address is ...!uunet!watmath!mks!toolkit (which is directed to me). We also have addresses on CompuServe and BIX. And my thanks to those who have already replied to these messages. We wanted to be sure we had everything in hand before posting our own reply, so the intermediate replies from others helped fill the gap. -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043