Tab completion error when expanding ${.sh}

[aweeraman]

Description of problem: Error during tab completion when attempting to expand ${.sh}

Ksh version: 2020.0.0

Steps to reproduce:

1. print ${.sh<TAB>

Actual results: ksh: line 1: ${!.sh$@: bad substitution

Expected results: print ${.sh. 1) .sh.edchar 14) .sh.stats.globs 2) .sh.edcol 15) .sh.stats.linesread 3) .sh.edmode 16) .sh.stats.nv_cachehit 4) .sh.level 17) .sh.stats.nv_opens 5) .sh.lineno 18) .sh.stats.pathsearch 6) .sh.match 19) .sh.stats.posixfuncall 7) .sh.math 20) .sh.stats.simplecmds 8) .sh.stats 21) .sh.stats.spawns 9) .sh.stats.arg_cachehits 22) .sh.stats.subshell 10) .sh.stats.arg_expands 23) .sh.subshell 11) .sh.stats.comsubs 24) .sh.type 12) .sh.stats.forks 25) .sh.version 13) .sh.stats.funcalls

Additional info: Linux ninsei 5.3.0-7625-generic #27~1576337002~19.10~bc3488b-Ubuntu SMP Sat Dec 14 18:31:03 UTC x86_64 x86_64 x86_64 GNU/Linux

[krader1961]

This works in ksh93u+ but is broken in ksh93v-. Example # 666 why I wish we had started with the ksh93u+ branch.

[jghub]

@aweeraman: it is also example # 666 why ksh2020 would not be a good choice for the default ksh in any distro (let alone a replacement of ksh93 altogether). ksh93u+ remains the only viable choice for this, both, because of superior performance and also because of being better behaved/ less buggy. at least if you assign more importance to absence of bugs like the one you report here than to reduced built time (big deal around here...) and silencing of lint warnings.

a head-to-head comparison ksh93u+ vs. k2020 for user-visible bugs would be interesting, although the outcome seems clear: the "does work in ksh93u+ but not in ksh2020" (like in your case) is seen around here definitely way more often than "was already broken in ksh93u+ and is also broken in ksh2020" while "was already broken in ksh93u+ and now has been fixed" seems a rare beast indeed (again: restricting it to user-visible bugs, i.e. manifest and deterministic misbehaviour). actually, the latter category (user-visible bugs already operational in ksh93u+ for which the ksh2020 project did provide an acceptable, well-engineered fix) would be valuable information to have (maybe krader is willing/able to provide it, maybe not) in order to backport these patches to ksh93u+.

[aweeraman]

@jghub I'm working towards getting ksh93u+ added to the Debian archive as well and support for the co-existence of the two shells so that users can make the choice. Will update this thread as we make progress on that.

[jghub]

@aweeraman: I believe this is very good news and the way to go: provide both shells, name the packages unambiguously to avoid confusion between ksh93 and ksh2020 and let the users decide what they want (and what not!). so: thanks for your work. this is really appreciated!

[aweeraman]

Just an update, @mirabilos has helped re-introduce ksh93 back and is currently sitting in the NEW queue and will be added to the archive, if all goes well. Meanwhile ksh2020 is updated to use the alternative system so the two can co-exist and is available on Debian testing. Meanwhile, let us support the 2020 team to fix the issues and collectively help move the project forward so we can keep the ksh legacy alive.

[jghub]

@aweeraman: thank you for this update. as said, having both options is good. having only ksh2020 is bad. I do hope other distros will follow your example... regarding

Meanwhile, let us support the 2020 team to fix the issues and collectively help move the project forward so we can keep the ksh legacy alive.

this would be good indeed. my initial hope was that this project will achieve that. but I have lost all confidence that this can happen as long as krader is involved (or rather: as long as krader is deciding single-handedly what changes are done). I presume you are aware of his crude and hostile behaviour which alone is sufficient to prevent development of an agreeable and good community or even only willingness of any passerby to give ksh a try.

as just one out of so many cases, what do you make of krader's attitude and behaviour in these issues (looking at the whole threads or the most recent posts from yesterday/today):

https://github.com/att/ast/issues/1449 https://github.com/att/ast/issues/1464

I can assure you that I am watching this project only because of ksh and despite krader. and as many others before me I probably will turn away in due time ( if I am sure that ksh93u+ has found a different home). I maintain: this project urgently would need a reset. krader should not have commit access to the main repo but should fork and submit pull requests for others to review and decide. otherwise this project is destined to fail (or in the worst case to succeed in replacing something good by something inferior).

[krader1961]

@jghub wrote

it is also example # 666 why ksh2020 would not be a good choice for the default ksh in any distro

That is an implicit admission that ksh93v- is not a "good choice for the default ksh in any distro" since the bug being discussed was introduced by the old AT&T AST team after the ksh93u+ release. It was not introduced by myself or anyone else who has actually committed changes intended to improve this project. Feel free to create a fork of the 2012-08-01-master (the ksh93u+) branch or the 2016-01-10-beta (the ksh93v-) branch. Then argue that your branch is superior to the current master branch.

[jghub]

That is an implicit admission that ksh93v- is not a "good choice for the default ksh in any distro" s

restoring factual correctness cont'd.: this is not an "impliciit admission", but the expressed opinion of lots of people, me included: ksh93v- most definitely is not a good choice as default ksh. it is beta software. and ksh2020 is worse. that's why things have to change. hopefully will.