Where is SH_VIRAW "viraw" -o viraw

[phidebian]

Yall, Got the impression that set -o viraw has been silently removed (don't see any reference in git log)

Some dinos out there used to have it (ツ)

Even though it is easy to fix, only interactive ksh is impacted, then fix your .kshrc. Yet when not advertised (readme, git log,...), it make me thought my new build was bugged.

$ /d1/ksh/arch/linux.i386-64/bin/ksh 
/home/phi/.kshrc[69]: set: viraw: unknown option
Usage: set [-sabefhkmnprtuvxBCGH] [-A name] [-o[option]] [arg ...]
 Help: set [ --help | --man ] 2>&1

[McDutchie]

Was removed in e9d32a4 and it's also listed in COMPATIBILITY. This was only done on the dev branch, not on the 1.0 branch.

If there are objections, I could restore --viraw as a dummy option (as already done with -h/--trackall and --nolog in a414b71).

[phidebian]

Ha good to know. My grep, cscope etc, didn't catched COMPATIBILTY so didn't spotted.

Yes a dummy option could be nice, i.e set -o viraw silently equate to set -o vi May be something like

option.c::

#if SHOPT_VSH
        "vi",                           SH_VI,
        "viraw",                        SH_VI,
#endif

Dunno if enough to implement the dummy though.

[McDutchie]

Restored in 6bf4025.

Guess we're stuck with obsolete dummy options forever. Oh well…

[McDutchie]

Background: the vi editor used to support the terminal's canonical mode (--viraw turned off), which means the terminal itself, and not ksh, echoed user input. This was great on 75bps dialup links in the 1980s, where otherwise you would be typing faster than ksh could keep up with in raw (non-canonical) mode. But it's incompatible with changing the window size on modern terminals, because ksh cannot react to events while in canonical mode. The --viraw option turned on raw mode. It has been forced on by default for decades (by the SHOPT_VIRAW compile time option) because it simply works better and no one uses 75bps terminals. Since no one cares about canonical mode now, I removed that code and the compile-time option to avoid bit rot.

[phidebian]

Yes, I know about 1200 bauds :), the fact is that I moved from csh to ksh (ksh88) back in the 90's at a time where remote working was about HP2392 terminal and a good modem, I was working in RnD labs then. my tty setup (erase) and terminal setup was carefully cooked then. Believe it or not, but this .kshrc followed me all my life (as my .virc, .emacs), form HPUX1.0 on 900 series architecture, to various linux now,. So what a chock when my bug free .kshrc barfed at me :), meaning fixing all the .kshrc I got on all the system I have access to :).

A silent dummy option is good to me, thanx for that.
Cheers

[McDutchie]

Sorry about that. Lesson learned.

Though I do reserve the right to break things on the dev branch occasionally... for stability, use the 1.0 branch for now :)

[McDutchie]

…on the other hand, if there are no people like you using the dev branch, no one will catch me out when I get a bit too bold, so thank you :)

[phidebian]

No problem at all, even a withdraw would have worked, after all the fix in .kshrc is trivial.

The fact I was working on dev branch, and all of the sudden I got this unknown option was strange I thought at first my patch/feature was breaking the whole thing :) and could not find any ref of the withdraw as my brute grep would not look into COMPATIBILITY :)

Well at least I looked into my .kshrc thing I didn't made since decade :) and finally got emitional about my naive coding of the time :)