Remove support for `FCEDIT` var

[krader1961]

The FCEDIT var defaults to the ed command. It has been deprecated since 1988 (20 years ago) in favor of the HISTEDIT var which does not have a default value. I know we want to minimize backward incompatible changes from the ksh93u+ release. But removing support for FCEDIT seems reasonable to me given the age of the deprecation.

This came to my attention while working an an unrelated issue which caused me to ponder the _pth_ed config time symbol for which we have a feature test.

[krader1961]

Hmmm... Even if we remove support for FCEDIT we need a fallback for a missing HISTEDIT. Should it be the ed command found at build time? Better, in my opinion, is to do what fish does and fallback to the VISUAL and EDITOR variables. If neither are set assume the user doesn't care enough to be able to edit command history. This seems reasonable since this is a highly sophisticated feature which is likely to be only used by people who have set the aforementioned env vars.

[mikeserv]

fuckedit is a posix specified environment variable. removing support for conformant behavior from the system upon which the standard is based is recursively sacrilege.

please dont.

p.s. thanks for caring, though. seriously, kudos for ksh upkeep.

p.p.s. try fcedit() { ! echo "$1" >&2 ;} >> "$1"; FCEDIT=fcedit fc -0

...unless that only works with alias ... i forget specifics just now, but once i facedit...

p.p.p.s.
oh. and you might need to exec 3>$1 to save the descriptor in case the shell deletes it after handoff... its been awhile... but the point is a randomized name in a temp directory is generated and thats a rare thing. also, no histamines... just first command or fuck it.

[siteshwar]

For reference it is documented here.

[krader1961]

I don't find @mikeserv's comment compelling. And, frankly, the argument isn't helped by trying to be cute (or edgy) by using words like fuckedit. Nor do I find the fact it is documented by POSIX compelling. How many people would even know what to do if they are dropped into the ed command as a result of using fc? If we are going to keep FCEDIT then the deprecation should be removed. You can't have it both ways. Either it is deprecated and should be removed after a suitable interval (20 years seems long enough) or it is considered sacrosanct by virtue of being documented by POSIX. Which, remember, did nothing more than codify the behavior of the major shells at the time the standard was written. That there are at least three env vars for specifying which editor to use (FCEDIT, EDITOR, VISUAL) is ridiculous. Especially since fc doesn't fall back to using VISUAL or EDITOR if FCEDIT isn't defined.

If the consensus is to retain FCEDIT then a) the deprecation needs to be replaced with a reference to the POSIX standard, and b) we need to replace the build time test for ed with a run-time test that finds the first occurrence in PATH.

[krader1961]

Probably the best solution is to retain FCEDIT and use it if set otherwise fallback to VISUAL then EDITOR then vi rather than the ed command. That would allow people to deliberately set FCEDIT to something other than their usual editor. And everyone else gets a more sensible fallback than ed. Note that the bash fallback for FCEDIT is EDITOR then vi.

P.S., In 30+ years of using UNIX I can't recall seeing anyone use FCEDIT as in @mikeserv's example. Obviously that's just a personal anecdote but it seems unlikely that there are enough people using it for such tricks to worry about.

[mikeserv]

@krader1961 flattery will get you nowhere.