Re: sh(1) BUGS entry query

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 30 Apr 2018 21:23:05 +0530
    From:        Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost>
    Message-ID:  <CAHwRYJ=SfJtmeMmeuboLTO2gSH-WJCDmShm_mh-aej=bF-XjRA%mail.gmail.com@localhost>

  | I believe this is happening in libedit.

I assumed that would be related.   sh itself as almost
nothing to do with it.

  | Few months back I added
  | escaping of special characters when doing filename auto-completion. I
  | missed '*' as one of the special characters, it's a one line fix
  | (patch below), which I can commit.

Please, but also add '['

In lebit (as the API is now) this is all very hard, as libedit is used
to interface to several programs, and what is special is not common.

Perhaps it would be better to allow a set (string?) of special chars
to be set by the calling application (and updated on demand).

Currently your list includes @ { and } which have no special meaning in
filenames at all (in sh).

But perhaps we need an enev better interaction between the calling
application, and libedit - perhaps with the application supplying the
possible matches (particularly before any '/' entered).  There is a
current open bug on sh(1) which complains that

	l<TAB>

returns l98.c labcd ... (whatever filenames exist) whereas what it
wants is "ls" "ln" "less" "last" "lex" :"lint" ...

Similarly if you type ls $x<TAB>

it would be better to get offered a choice of the var names starting
with x than the filenames starting $x

For this, a callback to the application which returns one name at a
time (and null when no more remain - with a state arg so the app
can remember where it is up to, as well as the prefix) that the app
can set - where if not set, the default is a libedit provided one which
reads directories (as now.)

kre