[ On Monday, December 9, 2002 at 20:59:48 (+0100), Thomas Klausner wrote: ]
> Subject: ksh bugs and behaviour questions
>
> I've tried using ksh in current (from Nov 5) for a bit, and I stumbled
> over the following bugs and differing behaviour compared to bash:
> 
> . ctrl-y doesn't append to last ctrl-y
>   bash does this, and I find it quite nice when wanting to some parts in
>   the middle of a previous line

I'm not sure what you mean.  If you mean what I think you mean, and
assuming you're using the default bindings for "set -o emacs" then it
does indeed append:

# first I type some characters....

	16:38 [3245] $ asldkjflaskdjfasdlkjf

# then I press ^W

	16:38 [3245] $ 


# then I press ^Y

	16:38 [3245] $ asldkjflaskdjfasdlkjf

# then I press ^Y again:

	16:38 [3245] $ asldkjflaskdjfasdlkjfasldkjflaskdjfasdlkjf

Is that not what you mean by "ctrl-y appending to the last ctrl-y"?


> . ctrl-r doesn't search in current line
>   bash does this, and I prefer it to ksh's behaviour of starting in the
>   previous line in the history;

Personally I very much prefer the AT&T KSH behaviour (which does what
bash does, but far more elegantly).  (try shells/ast-ksh to see)

>   good if you want to e.g. change the flags
>   given to the current command

if that's all you want to do then what's wrong with <CTRL-P>?


> . expansion does not work correctly in many cases.
>   This is a bug. Details:
>   . directories containing a single quote or double quote.
>     > mkdir test<RET>
>     > cd test<RET>
>     > mkdir a\'b<RET>
>     > touch a<TAB>
>     > touch a\'b/<TAB>
>     > touch a\'b/'b/<TAB>
>     > touch a\'b/'b/'b/<TAB>
>     ...

You really don't want very much, do you!  ;-)

(I suspect fixing this will be quite difficult to do correctly)


> . <UP><DOWN> doesn't give back an empty line
>   bash does this; ksh remains on the last line in the history

That's a good thing!  :-)  (^U is your friend here)

(ksh93 is quite broken -- I'm not sure how to describe its behaviour)


> . ctrl-l on empty line does not clear(1)
>   bash does this, and I prefer it to having to type 'clear' :)

I really REALLY prefer the pdksh behaviour -- and it matches ksh93.

If you want a one-key clear(1) then it should be easy enough for you to
make a custom key binding to work as you wish.


> . first command line argument gets expanded even to non-executable files
>   bash does this, and I think it's a useful feature.

No, that's an annoying useless behaviour.  :-)


> . completion does not offer .* files at all except if . is prepended by the user
>   One could argue over this one. I'm not sure which I prefer.

This behaviour, which matches both ksh93 and other utilities such as ls,
is by far the better way.


> . completion does not work on incomplete variables ($HO<TAB>) or user names
>   (~wi<TAB>)
>   bash does this...

That would be nice, but again it's something ksh93 doesn't do either.


> . completion does not append '/' to ..
>   For me, this one's a bug.

Hmmm..... yes, I see.  (it does work correctly in ksh93)


> . if leaving ksh with CTRL-D, no new line character emitted
>   Nit, I know.

Trying to send any output after reading an EOF can get you into
trouble.  What if the EOF was sent just as the tty was hung up?

Its safest just to exit(), at least by default.

However if you really really want this behaviour then you can set a trap
to do it for you.  Eg. I have been running a logout script from my
initial login session by setting this trap in my ~/.profile for years
now:

	trap '. $HOME/.kshlogout ; exit $?' 0

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>