> IMHO, this can only lead to confusion. if one installs zsh as ksh, he > might use commands that are not supported by "historical" ksh, > and "historical" scripts may not run.
Quite frankly there is no shell in Debian which perfectly emulates "historical" ksh. The newer versions of AT&T ksh could break things in much subtler ways than this (such as the change from dynamic to static variable scoping) (see /usr/share/doc/ksh/COMPATIBILITY.gz). pdksh is also little better. I'd also bet that tcsh doesn't do a perfect job when it handles the csh alternative but it works for me. Given that zsh adjusts it's behaviour based on the name it was invoked under, it is useful for user's to be able to take advantage of this and have the ksh symlink point to it. Why install a ksh package if you use zsh and zsh can run all your ksh scripts? And given the low priority of the alternative, users aren't going to do this without some idea of what they're doing. Certainly, it would make sense to enable ERR for ksh compatibility mode. Or perhaps it'd be better to insist on "SIGERR" on UNICOS. Oliver ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
