Bug 165742 - many incompatibilities in ksh on FC4
many incompatibilities in ksh on FC4
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: ksh (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-11 13:57 EDT by Tom Horsley
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-22 10:47:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
compressed tar file with several files to demo bugs (1.63 KB, application/octet-stream)
2005-09-08 20:00 EDT, Tom Horsley
no flags Details
enable Makefile option SHOPT_ECHOPRINT (1.25 KB, application/octet-stream)
2006-06-07 06:09 EDT, Pim Zandbergen
no flags Details

  None (edit)
Description Tom Horsley 2005-08-11 13:57:22 EDT
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:
Comment 1 Tom Horsley 2005-08-11 14:37:22 EDT
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.
Comment 2 Kip Krauss 2005-08-25 18:35:47 EDT
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.
Comment 3 Karsten Hopp 2005-09-07 10:22:47 EDT
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.
Comment 4 Tom Horsley 2005-09-07 18:41:47 EDT
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.
Comment 5 Tom Horsley 2005-09-07 21:32:21 EDT
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 :-).
Comment 6 Pim Zandbergen 2005-09-08 05:48:28 EDT
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".
Comment 7 Tom Horsley 2005-09-08 20:00:13 EDT
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.
Comment 8 markus.kommant 2005-10-11 12:59:56 EDT
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
Comment 9 David Leonard 2005-10-17 21:00:24 EDT
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
Comment 10 Pim Zandbergen 2005-10-27 05:45:56 EDT
Shouldn't this bug be split in two?
I don't think job control and "echo" behaviour
are much related.
Comment 11 Karsten Hopp 2006-05-22 10:47:19 EDT
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.
Comment 12 Pim Zandbergen 2006-06-07 06:09:37 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.