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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. try to use existing ksh scripts
2. watch them get errors :-).
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
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
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 " + 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
$ vi /tmp/y
<ctrl-Z> <ctrl-Z> <ctrl-Z>
 + Stopped vi /tmp/y
$ jobs -l
 + 23476 Stopped vi /tmp/y
 - 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
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
$ 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.