From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6 Description of problem: I see several ksh bugs against FC4 out there reporting individual problems, but I see many more problems than the ones reported. Job control seems brain damaged. It is sort of there, but I don't get Done messages when the job finishes, and if I start the job with a fancy alias, the "jobs" report doesn't show the actual command the alias ran, just a truncated bit of the alias name itself. Worse than that, many different ksh script which worked on FC3 and also on a huge variety of other operating systems' ksh, don't work on FC4. At least one problem seems to have something to do with quoting in multi-line strings, but it is hard to pin down just how many bugs there are. I'm gonna have to dig up the FC3 ksh rpm and see if it will install and works better than whatever monstrosity is masquerading as ksh on FC4. Version-Release number of selected component (if applicable): ksh-20050202-1 How reproducible: Always Steps to Reproduce: 1. try to use existing ksh scripts 2. watch them get errors :-). 3. Additional info:
I just erased the ksh-20050202-1 rpm, and installed the pdksh-5.2.14-30 rpm from FC3, and all my problems seem to have been solved.
Have seen the same issues. Had to go back to FC3 ksh for scripts to work properly. Sidenote: if you execute ksh from within the /bin directory - several of the formatting errors evaporate.
Please attach some of the failing scripts and add some comments at whichj point AT&T's ksh behaves differently And please bear in mind that pdksh is just a clone of the real kornshell which we're now shipping and you've probably hit some of the incompatibilities between those two.
I'll have to work on the example scripts, none of the ones I have can work without a ton of other stuff they interact with installed, but it seems to be related to multi-line quoted strings in the script (things like passing a multi-line script directly to awk as an argument on the command line). On the compatibility front: This must be proof of bit-rot. The scripts all work fine on many different systems which have AT&T derived kernel and userlands. It is only the "official" ksh on fedora core 4 that barfs :-). The pdksh seems to be much more compatible with the official ksh on the other machines I've used.
I no longer know if it has anything to do with multi-line strings or not. I can watch the full-blown scripts fail in the context of all the apps they interact with, but can't seem to produce a stand-alone script that can demonstrate a failure (I hate when that happens :-).
One thing that breaks most of our scripts is the behaviour of the "echo" builtin command. In ksh, "echo" should behave like bash "echo -e", that is, it should interpret escape sequences like "\n" for newline. Fedora's ksh outputs the escape sequences literally. By contrast, the "print" command works like it should. That is peculiar, because "echo" supposedly is an alias for "print".
Created attachment 118616 [details] compressed tar file with several files to demo bugs The hint about escape sequences was what I needed. Here is a bzip2'ed tar file with some sample bug generating scripts and aliases. The README file has the details. I've got examples of the escaping being different as well as an example of how jobcontrol is screwed up.
confirm: echo "\t" or other escape sequences are printed like bash echo -E "string" the whole echo defaults are changed in FC4, means that bash echo in FC3 was working like echo -e and in FC4 it works like echo -E
Job control is very broken especially when trying to suspend vi with ctrl-Z. If you try Ctrl-Z in vi, the screen simply flashes (ksh seems to suspend/continue it in rapid sucession). When you exit the editor, ksh reports it as "[5] + Stopped". Running "jobs" to see what jobs are their yields two job entries for vi, one of which you can fg, but the other that you can't kill or anything. $ vi /tmp/y <ctrl-Z> <ctrl-Z> <ctrl-Z> ZZ [5] + Stopped vi /tmp/y $ jobs -l [5] + 23476 Stopped vi /tmp/y [4] - 23475 Running vi /tmp/y
Shouldn't this bug be split in two? I don't think job control and "echo" behaviour are much related.
job control works with ksh-20060124-3 (Fedora-devel), suspending and continuing vim works without the described problems. I'll quote the important part of ksh's manpage about echo: echo [ arg ... ] When the first arg does not begin with a -, and none of the arguments contain a \, then echo prints each of its arguments separated by a space and terminated by a new-line. Otherwise, the behavior of echo is system dependent and print or printf described below should be used. See echo(1) for usage and description. Which basically means that you should use ksh's print function instead of echo if need to write portable scripts. You're using the systems /bin/echo command (coreutils) which shows different behaviour.
Created attachment 130666 [details] enable Makefile option SHOPT_ECHOPRINT $ ksh $ type echo echo is a shell builtin "echo" behaviour in ksh is simply a Makefile option called "SHOPT_ECHOPRINT". In my opinion it should be set to be consistent with pdksh and most other ksh ports (SCO, AIX, HP-UX). Also, the man page for the Linux version of ksh should document the behaviour, because it is not "system dependent" but depends solely on a compile time decision. This patch fixes both issues.