On 13.01.2024 11:05, Janis Papanagnou wrote:
> I'm having a Kornshell script that prompts for input like this
>
> while IFS= read -r word?"prompt> "
> do process "${word}"
> done
>
> Is there a possibility to somehow get readline(3) editing support
> into such a read loop, so that whenever the prompt is displayed I
> can skim (e.g. with cursor keys) through the previous data input?

(After the discussions, a few days of tranquility, and a tasty cup
of coffee...)

Now this is embarrassing! - I could make it work also in Ksh, and
even quite simply; 'readline' isn't necessary at all, Ksh supports
it natively. - These changes work for me in Ksh...

$ diff ...
96a97,101
> HISTFILE="${HOME}/.prompt.history"
> HISTSIZE=50
>
> set -o vi
>
99c104
< while IFS= read -r word?"prompt> "
---
> while IFS= read -r -s word?"prompt> "

The HISTFILE and HISTSIZE isn't necessary, it just keeps the global
history clean by using an own history file for this application.

The 'read -s' is to drop the input data into the history (I already
tried that before, but that alone didn't work).

The key was just to also enable the editing 'set -o vi' (which isn't
taken from the environment or from some configuration files I tried).

Janis

Op 16-01-2024 om 08:16 schreef Janis Papanagnou:
[...]
> The 'read -s' is to drop the input data into the history (I already
> tried that before, but that alone didn't work).
>
> The key was just to also enable the editing 'set -o vi' (which isn't
> taken from the environment or from some configuration files I tried).

Yeah, that's only done for interactive shells. To use emacs or vi with 'read'
in a script, you have to set the option yourself.

Speaking of which, ksh 93u+m/1.0.9 will have a bug fix for 'read -s' that may
interest you. You may wish to apply the patch to bltins/read.c locally ahead
of the release:

https://github.com/ksh93/ksh/commit/def3415b.patch

| When emacs or vi mode is activated in a script, 'read -s' should
| allow the user to arrow up to the current shell history file
| ($HISTFILE, default ~/.sh_history). But it looks like the history
| file is not properly initialised for 'read -s' as it does not work
| on the first invocation:
| | $ ksh -c 'set -o emacs; read -s foo'
| (type up arrow; beep -- before f840ce81, infinite loop)
| | $ ksh -c 'set -o emacs; read -s foo; read -s foo'
| (type return, then up arrow; shell history appears)
| | src/cmd/ksh93/bltins/read.c: sh_readline():
| - Move the code block that initialises the shell history file to
| immediately before where the first read operation is performed.

--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh

On 21.01.2024 04:18, Martijn Dekker wrote:
>
> Speaking of which, ksh 93u+m/1.0.9 will have a bug fix for 'read -s'
> that may interest you. You may wish to apply the patch to bltins/read.c
> locally ahead of the release:

Thanks for the information and for the fix!

Janis

In article <l13gndFp7p1U1@mid.individual.net>,
Martijn Dekker <martijn@inlv.demon.nl> wrote:
>Op 16-01-2024 om 08:16 schreef Janis Papanagnou:
>[...]
>> The 'read -s' is to drop the input data into the history (I already
>> tried that before, but that alone didn't work).
>>
>> The key was just to also enable the editing 'set -o vi' (which isn't
>> taken from the environment or from some configuration files I tried).
>
>
>Yeah, that's only done for interactive shells. To use emacs or vi with 'read'
>in a script, you have to set the option yourself.

But in my testing, in bash, setting the "-o vi" did nothing, unless also
accompanied by setting interactive mode (-i on the #! line). And in that
case, the history "works", but is wrong. I.e., when you scroll with
up/down arrows, you get the lines of the script, not lines you've entered.

Anyway, that's bash. Maybe it is different in ksh.

--
It's possible that leasing office space to a Starbucks is a greater liability
in today's GOP than is hitting your mother on the head with a hammer.

On 2024-01-21, Kenny McCormack <gazelle@shell.xmission.com> wrote:

> But in my testing, in bash, setting the "-o vi" did nothing, unless also
> accompanied by setting interactive mode (-i on the #! line). And in that
> case, the history "works", but is wrong. I.e., when you scroll with
> up/down arrows, you get the lines of the script, not lines you've entered.

But, as we already established, you can explicitly enable history
in a noninteractive bash and use "history -s" to push lines into
the history.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

On 21.01.2024 11:58, Kenny McCormack wrote:
>
> Anyway, that's bash. Maybe it is different in ksh.

Yes. The 'read' options (names, semantics, available options),
the 'history' support, and the gory details about interactive
behavior seems to differ significantly between ksh and bash.
That's why I had previously considered to even port my script
to bash. (But since there's a most simple ksh solution I'm of
course more happy with that.)

Janis

In article <slrnuqqh9i.amu.naddy@lorvorc.mips.inka.de>,
Christian Weisgerber <naddy@mips.inka.de> wrote:
>On 2024-01-21, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>
>> But in my testing, in bash, setting the "-o vi" did nothing, unless also
>> accompanied by setting interactive mode (-i on the #! line). And in that
>> case, the history "works", but is wrong. I.e., when you scroll with
>> up/down arrows, you get the lines of the script, not lines you've entered.
>
>But, as we already established, you can explicitly enable history
>in a noninteractive bash and use "history -s" to push lines into
>the history.

Oh, OK.

That just looks like a hokey hack to me, so I kinda stopped paying attention
at that point.

Anyway, I'll stick with my getline extension.

--
To my knowledge, Jacob Navia is not a Christian.

- Rick C Hodgin -

On 21.01.2024 17:59, Kenny McCormack wrote:
>
> Anyway, I'll stick with my getline extension.

You intended to show us your implementation. Did I miss the post
or isn't it yet ready to publish?

Note: I was (and still am) generally interested to see your bash
extension example. - Just saying, in case you thought I'd not be
interested any more because I found my ksh based solution.

Janis

In article <uou1t8$2cbe7$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>On 21.01.2024 17:59, Kenny McCormack wrote:
>>
>> Anyway, I'll stick with my getline extension.
>
>You intended to show us your implementation. Did I miss the post
>or isn't it yet ready to publish?

Thanks for the reminder. I need to get going on that.

>Note: I was (and still am) generally interested to see your bash
>extension example. - Just saying, in case you thought I'd not be
>interested any more because I found my ksh based solution.

Good to know. Thanks.

--
Just remember:

Pence is all the evil, with none of the crazy.