Re: [ksh93u+m] Interactive subshell expansion disfunctional

Hi Martijn

On 22.06.2024 01:14, Martijn Dekker wrote:

Op 21-05-2024 om 17:57 schreef Janis Papanagnou:

I recently replaced all original ksh93u+ by ksh93u+m, and meanwhile
noticed quite some deficiencies, things that worked in original ksh
but not any more in ksh93u+m.

 
I would of course be very interested in learning what deficiencies
(other than the below) you've been observing.

Unfortunately I haven't kept track. It's just that I noticed that
a couple things that worked before do not any more. Partly because
they were probably anyway only considered experimental, partly it
were features that I'd suspect are not commonly used.

Off the top of my head one was the support of ksh's alarm timers,
and another thing was in context of discipline functions used on
shell variables. (In the latter case I have no certainty whether
it's a shell issue or whether I should have done this differently.
I detected it with my "kosta" code, a ksh variant of Kaz' "basta"
for bash, only with features from ksh implemented.) Another thing
is how variables are expanded in Vi-mode.

(I will need some time to reproduce and collect the information.)

 

The latest observation is that in interactive mode with 'set -o vi'
I was able to write a command substitution, say,
>
   ls $(date)

(This should of course have been  ls $(date +%F)  for the output
format shown below.)

>
and with the cursor positioned (e.g.) at the closing parenthesis I
could expand the argument by Esc-* to obtain
>
   ls 2024\-05\-21
>
This does not seem to work in ksh93u+m. - Is there a chance to get
original ksh behavior back?

 
"Subshell expansion" was never meant to be a thing and is not documented
anywhere.

Kornshell had always things implemented (for experimentation or
even for production) and not always documented it [in time or
generally].

The behaviour was a bug; this was not supposed to happen.

(I cannot see where you derive that from.)

All I can say is that because the docs had partly always been
behind of time or inconsistent it's not necessarily a bug; there
are more things implemented than documented. (Not sure about the
"latest" 93u+ but that was an observation since my ksh88 days.)

So if you want to say "all that isn't documented isn't supported"
I can hardly argue with you and will (of course) accept that.

It
also behaved inconsistently and crashed the shell in some cases.

The features I used behaved well. But I agree that some usages
showed inconsistencies (a general issue with old ksh; that's
why I'm so happy that you provided a thoroughly fixed ksh93u+m).

 
For further details and rationale, please see:
https://github.com/ksh93/ksh/commit/7a2d3564
https://github.com/ksh93/ksh/issues/268
 
The documented behaviour of ESC-* in emacs is:

I cannot speak for Emacs-mode since I'm doing everything in
Vi-mode (as indicated above).

 
       M-*       Attempt pathname expansion on the current word.  An
asterisk is
                 appended if the word doesn't match any file or contain any
                 special pattern characters.
 
Pathname expansion simply has no business executing code; that's not
what it's for.

The expansion I mentioned was not the only expansion issue.

But first let me explain a short difference between pathname
expansion and command expansion as it was. If I now type

  x=$(date +%F)<Esc>*

then <Esc>* is expanding all files. I would have expected (as
it had been before with ksh93u+) that a filename expansion
would appear if I had typed

  x=$(date +%F)*<Esc>*

i.e. if I had provided a glob pattern that the Vi command
<Esc>* could then expand, or if the cursor would be on a
word (a file or command) to become expanded (by globbing
and PATH expansion, respectively). Now in ksh93u+m both
depicted commands expand the same way (and lists all files
in the working directory; not very useful, and luckily
there is an undo command to let that filename pollution
vanish).

(I think it's also okay, as it currently works already,
to expand all filenames on a space   x=$(date +%F) <Esc>*
but I think [from my perspective] it's a rarer case.)

Moreover, if the cursor is on the opening parenthesis the
<Esc>* will insert an escaped '\*' despite being in command
mode (and not in input mode).

Variable expansion does also misbehave (I think already in
original ksh93u+). With

  y='ABC   DEF'

  z=$y<Esc>*

will expand to

  z=ABC DEF

and trying to add quotes

  z="$y"<Esc>*

will do nothing. And going back one character to the 'y'
and then typing <Esc>* will produce

  z=ABC DEF"

In my daily work with the Kornshell these expansions were
really useful (modulo the bugs/inconsistencies of course).
But of course I cannot expect that features that are (maybe,
haven't checked) not (not well) documented to be supported.
Especially if there were (as you also say) inconsistencies
or bugs already in the original Kornshell.

 
I can see how the behaviour as you describe it could come in handy,
though. We could treat it as a feature request for version 93u+m/1.1 and
up. It would have to be implemented properly. If implemented it should
probably also be bound to a new key combination.

I found it intuitive as it could be used before in ksh93u+,
so I'm not very keen if another key combination will be
invented. (My muscle memory will certainly fool me then.)

Wouldn't it be consistently describable depending on the
context? (I think it would.) On a command fragment or in
a command position a pathname expansion will be done, on
other word fragments (or globbing characters) a globbing
expansion will be done, on a $ prefixed variable name a
variable expansion will be done (ideally with a correct
quotung), and on a shell construct character (like the
parentheses or dollar in $(...) a command expansion will
be done. - This is not yet thought through, but it
resembles the previous behavior modulo some adjustments
to address some previously existing inconsistency.

Janis