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?

If not in ksh; is that maybe possible in bash or zsh ?

Or is there a general problem with that idea or such a function?

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> 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?
>
> If not in ksh; is that maybe possible in bash or zsh ?
>
> Or is there a general problem with that idea or such a function?

You can start your shell with `rlwrap -a´. This should provide readline
support on every prompt. However unfortunately this way readline cannot
distinguish between the read prompts and the other prompts.

Another possibility would be to start an external program which reads
and prints a single line and then wrap this program with rlwrap. Then
in your script you should be able to capture the line with
`word="$(program)"´.

In article <untn92$3t3gn$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> 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?
>
>If not in ksh; is that maybe possible in bash or zsh ?

Don't know much about ksh (don't much about the French I took), but bash
will do this quite easily. Just include "-e" as an option to "read".

>Or is there a general problem with that idea or such a function?

No, seems perfectly reasonable to me.

FWIW, I actually don't like readline much. Prefer "Tecla" (you can Google
it). I wrote a bash extension library that gives me access to Tecla from
my bash scripts. The extension library creates a new builtin command
"getline" that has Tecla editing functionality.

--
I love the poorly educated.

On 13.01.2024 13:21, Joerg Mertens wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> 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?
>>
>> If not in ksh; is that maybe possible in bash or zsh ?
>>
>> Or is there a general problem with that idea or such a function?
>
> You can start your shell with `rlwrap -a´. This should provide readline
> support on every prompt. However unfortunately this way readline cannot
> distinguish between the read prompts and the other prompts.

Looks interesting. The docs also mention some more tools. - Thanks.

Too bad that it has no configure script and it requires some newer
version of Autoconf to build, so currently I can't compile it as
it is on my Linux. Will have to look into it later...

>
> Another possibility would be to start an external program which reads
> and prints a single line and then wrap this program with rlwrap. Then
> in your script you should be able to capture the line with
> `word="$(program)"´.

I also thought in that direction as a fall-back if there's nothing
already existing. My first thoughts were to use ksh's KEYBD trap,
maybe in conjunction with a 'set' discipline function on the 'read'
variable. But first I look whether I can avoid to invent something
new.

Janis

On 13.01.2024 13:56, Kenny McCormack wrote:
> In article <untn92$3t3gn$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> 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?
>>
>> If not in ksh; is that maybe possible in bash or zsh ?
>
> Don't know much about ksh (don't much about the French I took), but bash
> will do this quite easily. Just include "-e" as an option to "read".

I had searched the bash man page for readline but somehow missed it
(maybe a typo); but it is there. - Thanks.

I inspected my script and it may be the least effort to just port
it from ksh to bash; there's not much ksh specific in it. It seems
that this is the most convenient solution for me.

>
>> Or is there a general problem with that idea or such a function?
>
> No, seems perfectly reasonable to me.
>
> FWIW, I actually don't like readline much. Prefer "Tecla" (you can Google
> it). I wrote a bash extension library that gives me access to Tecla from
> my bash scripts. The extension library creates a new builtin command
> "getline" that has Tecla editing functionality.

I'd be interested to have a look into the built-in. Is it available
to the public?

Janis

On 2024-01-13, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> 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?
>
> If not in ksh; is that maybe possible in bash or zsh ?

Not in bash, where "read -e" will use readline(3), but it doesn't
keep any history, so you can't access previous input. It's possible
to put some text into the readline edit buffer (-i text), so you
could, say, offer the immediately previous input as a default.

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

In article <slrnuq546h.20hn.naddy@lorvorc.mips.inka.de>,
Christian Weisgerber <naddy@mips.inka.de> wrote:
>On 2024-01-13, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
>> 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?
>>
>> If not in ksh; is that maybe possible in bash or zsh ?
>
>Not in bash, where "read -e" will use readline(3), but it doesn't
>keep any history, so you can't access previous input.

No idea what you're on about here. It works as expected for me.

--
"The party of Lincoln has become the party of John Wilkes Booth."

- Carlos Alazraqui -

On Sat, 13 Jan 2024 14:52:56 +0000, Kenny McCormack wrote:

> In article <slrnuq546h.20hn.naddy@lorvorc.mips.inka.de>,
> Christian Weisgerber <naddy@mips.inka.de> wrote:
>>On 2024-01-13, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>>> 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?
>>>
>>> If not in ksh; is that maybe possible in bash or zsh ?
>>
>>Not in bash, where "read -e" will use readline(3), but it doesn't
>>keep any history, so you can't access previous input.
>
> No idea what you're on about here. It works as expected for me.

I've never used this bash feature myself, so I don't have any firsthand
knowledge of it.

HOWEVER, it appears that bash(1) uses certain user-configurable
settings[1] to enable or disable the "history" options of bash(1)'s
"read -e"

P'haps Christian does not have these options enabled (thus causing
"read -e" to ignore line history), and you /do/ have them enabled
(either by choice, or by default).

[1] See bash(1) "READLINE" section, specifically the "Readline
Variables" subsection, and the "Readline Initialization" subsection
for information on how to enable/disable history.
--
Lew Pitcher
"In Skills We Trust"

In article <unu4rb$3v226$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>> FWIW, I actually don't like readline much. Prefer "Tecla" (you can Google
>> it). I wrote a bash extension library that gives me access to Tecla from
>> my bash scripts. The extension library creates a new builtin command
>> "getline" that has Tecla editing functionality.
>
>I'd be interested to have a look into the built-in. Is it available
>to the public?

I can post it here, if you like. Give me a little time to get it together
for posting.

--
"The most unsettling aspect of my atheism for Christians is
when they realize that their Bible has no power to make me
wince. They are used to using it like a cattle prod to get
people to cower into compliance." - Author unknown

On 13.01.2024 16:08, Kenny McCormack wrote:
> In article <unu4rb$3v226$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> ...
>>> FWIW, I actually don't like readline much. Prefer "Tecla" (you can Google
>>> it). I wrote a bash extension library that gives me access to Tecla from
>>> my bash scripts. The extension library creates a new builtin command
>>> "getline" that has Tecla editing functionality.
>>
>> I'd be interested to have a look into the built-in. Is it available
>> to the public?
>
> I can post it here, if you like. Give me a little time to get it together
> for posting.

Thanks. And don't worry or hurry, I have plenty of time. :-)

My tries with bash's read -e failed BTW; yet I have no idea
why it doesn't work. - Will have to examine it...

Janis

On 13.01.2024 14:32, Christian Weisgerber wrote:
> On 2024-01-13, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
>> 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?
>>
>> If not in ksh; is that maybe possible in bash or zsh ?
>
> Not in bash, where "read -e" will use readline(3), but it doesn't
> keep any history, so you can't access previous input. It's possible
> to put some text into the readline edit buffer (-i text), so you
> could, say, offer the immediately previous input as a default.

This is what I experienced as well. So I'll have to look into it.
Lew's comment indicates that there might be some hope to solve it
by configuration. I'll see what I find and get...

BTW, the injection of default data into the read prompt is also
possible in Kornshell. (I tried it in both shells.) But it's not
what I need, because I'd then have to clear it constantly, since
my "normal" use-case is to type in new phrases, but occasionally
I want some older phrases (mostly the last one) corrected.

BTW #2, my (desperate) latest try was to define a KEYBD trap and
if .sh.edchar is a Tab it should replace the input by the data
line from a tool specific history file, and use ksh's read -s
option. - It also doesn't work; at least not yet...

Janis

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

>>Not in bash, where "read -e" will use readline(3), but it doesn't
>>keep any history, so you can't access previous input.
>
> No idea what you're on about here.

What I said.

Anybody can try it for themselves:

while IFS= read -r -e -p "prompt> " line
do
echo "[$line]"
done

Actually, the lack of history is only true if you run it in a script.
In an interactive shell, there is history--but it's the command
history and it does not include the "read" input.

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

with <untn92$3t3gn$1@dont-email.me> 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?
>
> If not in ksh; is that maybe possible in bash or zsh ?

As of zsh (disclaimer: not a ksh-user here)

% typeset foo= ; vared -p '### ' foo ; echo "($?) ($foo)"
### aa bb cc
(0) (aa bb cc)

More information 'info zsh vared'. What manual is trying to say should
be discovered through experiments though. Another caveat: it's not
clear from getgo if 'vared' would read from stdin and then go for
editing. Yet another caveat: in 5min I failed to find out how to
achieve multiline input. Also: obviously it's not readline(3), it's
zle. Are you distracted enough now?

*CUT* [ 4 lines 1 level deep]

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

On 1/13/24 3:05 AM, 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?
>
> If not in ksh; is that maybe possible in bash or zsh ?
>
> Or is there a general problem with that idea or such a function?

A while back I was playing with ksh93 and wrote a "Word Of The Day"
script presents randomly selected words -- a through z -- from the
system "words" file which can then be selected for dictionary lookup.

Temporary history files to seed "adjacent words",
core_word+{s,es,ist,etc}, in the event a definition for the selected
word wasn't found. The suggested adjacent word(s) are selected via the
Up/Down arrows and can then be edited similar to readline.

Anyway, maybe it's useful to you:

gopher://sdf.org/0/users/jgw/Misc/wotd.ksh

* lynx(1) or curl(1) support gopher links

jeorge

On 13.01.2024 16:48, Christian Weisgerber wrote:
> On 2024-01-13, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>
>>> Not in bash, where "read -e" will use readline(3), but it doesn't
>>> keep any history, so you can't access previous input.
>>
>> No idea what you're on about here.
>
> What I said.
>
> Anybody can try it for themselves:
>
> while IFS= read -r -e -p "prompt> " line
> do
> echo "[$line]"
> done
>
> Actually, the lack of history is only true if you run it in a script.
> In an interactive shell, there is history--but it's the command
> history and it does not include the "read" input.

That would be okay (at least for ksh) since ksh's 'read -s' allows to
drop the read input to the command history. (But ksh doesn't have the
'read -e', OTOH. I thought the requirement would not be uncommon and
some [emphasis!] _easy_ support would be in the shells, but no, it's
cursed.)

Janis, continuing later...

On 13.01.2024 17:47, Eric Pozharski wrote:
> with <untn92$3t3gn$1@dont-email.me> Janis Papanagnou wrote:
>> [...]
>>
>> 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?
>>
>> If not in ksh; is that maybe possible in bash or zsh ?
>
> As of zsh (disclaimer: not a ksh-user here)
>
> % typeset foo= ; vared -p '### ' foo ; echo "($?) ($foo)"
> ### aa bb cc
> (0) (aa bb cc)
>
> More information 'info zsh vared'. What manual is trying to say should
> be discovered through experiments though. Another caveat: it's not
> clear from getgo if 'vared' would read from stdin and then go for
> editing. Yet another caveat: in 5min I failed to find out how to
> achieve multiline input. Also: obviously it's not readline(3), it's
> zle. Are you distracted enough now?

Both would be okay. (I neither need multiline, nor a specific readline
function.) I just want to be able to get and edit previous inputs most
simply and least disturbing. - I'll look into it. Thanks.

Janis

On 13.01.2024 20:09, jeorge wrote:
>
> A while back I was playing with ksh93 and wrote a "Word Of The Day"
> script presents [...]
>
> Anyway, maybe it's useful to you:

Quite some code; I'll have a look into it but need some time. - Thanks.

>
> gopher://sdf.org/0/users/jgw/Misc/wotd.ksh

Legacy feelings come up... :-)

I used gopher maybe once around 1990; is it still in use?
(Good that curl supports it; thanks for the hint.)

Janis

On 2024-01-14, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 13.01.2024 17:47, Eric Pozharski wrote:
>> with <untn92$3t3gn$1@dont-email.me> Janis Papanagnou wrote:
>>> [...]
>>>
>>> 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?
>>>
>>> If not in ksh; is that maybe possible in bash or zsh ?
>>
>> As of zsh (disclaimer: not a ksh-user here)
>>
>> % typeset foo= ; vared -p '### ' foo ; echo "($?) ($foo)"
>> ### aa bb cc
>> (0) (aa bb cc)
>>
>> More information 'info zsh vared'. What manual is trying to say should
>> be discovered through experiments though. Another caveat: it's not
>> clear from getgo if 'vared' would read from stdin and then go for
>> editing. Yet another caveat: in 5min I failed to find out how to
>> achieve multiline input. Also: obviously it's not readline(3), it's
>> zle. Are you distracted enough now?
>
> Both would be okay. (I neither need multiline, nor a specific readline
> function.) I just want to be able to get and edit previous inputs most
> simply and least disturbing. - I'll look into it. Thanks.

The vared command needs -h to use the history. You can also use fc -p
before using the vared command to push the current history onto a stack
and switch to a new history list. The fc command can be found in
"man zshbuiltins" and the vared command in "man zshzle".

--
To reply via e-mail, replace "YYMMDD" with the current date in the
appropriate format, or your mail will bounce. Removing the + and
everything that follows in my username will also cause your mail to
bounce. Details: https://nyx.net/~cmartin/HowToEmailMe

In article <unuc23$3ve$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>My tries with bash's read -e failed BTW; yet I have no idea
>why it doesn't work. - Will have to examine it...

In what way did it "not work" ?

See the other thread I entered on this. As far as I can tell, in-the-line
editing does work, but history doesn't. Is history the main functionality
that you need?

FWIW, it sure seems to me that there should be a way to get history to work.

--
The whole aim of practical politics is to keep the populace alarmed (and hence clamorous
to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary.

H. L. Mencken

On 2024-01-14, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> That would be okay (at least for ksh) since ksh's 'read -s' allows to
> drop the read input to the command history.

Bash also has a way to push commands into history. And in an
_interactive_ shell, "read -e" has access to history. Also, it
looks like the loop is considered a single command. We can combine
all this:

#!/usr/local/bin/bash -i
while IFS= read -r -e -p "prompt> " line
do
echo "[$line]"
history -s "$line"
done

It seems fragile, though, depending on underspecified behavior.
And I lack an understanding of the consequences of forcing a shell
to run as if interactive when executing a script.

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

In article <slrnuq7qmg.2tbp.naddy@lorvorc.mips.inka.de>,
Christian Weisgerber <naddy@mips.inka.de> wrote:
....
> #!/usr/local/bin/bash -i
> while IFS= read -r -e -p "prompt> " line
> do
> echo "[$line]"
> history -s "$line"
> done

Wow. I just tried adding "-i" to my script (see other thread) - and it
works - or does it?

If you add -i, you get history, but the history is the script itself, not
things you've previously entered at the prompt. So, that's no good.

--
The difference between communism and capitalism?
In capitalism, man exploits man. In communism, it's the other way around.

- Daniel Bell, The End of Ideology (1960) -

On 2024-01-14, Christian Weisgerber <naddy@mips.inka.de> wrote:
> On 2024-01-14, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
>> That would be okay (at least for ksh) since ksh's 'read -s' allows to
>> drop the read input to the command history.
>
> Bash also has a way to push commands into history. And in an
> _interactive_ shell, "read -e" has access to history. Also, it
> looks like the loop is considered a single command. We can combine
> all this:
>
> #!/usr/local/bin/bash -i
> while IFS= read -r -e -p "prompt> " line
> do
> echo "[$line]"
> history -s "$line"
> done
>
> It seems fragile, though, depending on underspecified behavior.
> And I lack an understanding of the consequences of forcing a shell
> to run as if interactive when executing a script.
>

This works for me. It's the stripped down version of a couple of scripts
I use every login session ...

#!/bin/bash

HISTFILE=$HOME/.history.test
HISTNUM=200

while $loop ; do
echo
set -H -o history
history -r
read -p "prompt : " -e ans
echo "$ans" >> $HISTFILE
case "$ans" in
q|quit|Q|Quit|QUIT)
exit 0
;;
esac
done

HTH
Jim

On 14.01.2024 14:03, Kenny McCormack wrote:
> In article <unuc23$3ve$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> ...
>> My tries with bash's read -e failed BTW; yet I have no idea
>> why it doesn't work. - Will have to examine it...

Yet I haven't found the time to continue the examinations. So just a
short reply here...

>
> In what way did it "not work" ?

I tried with my code and also with the small sample that you provided,
setting up the two files, etc. - The effect was that I got my prompt
but arrows (or vi keys or any other random keys) did not show previous
input.

>
> See the other thread I entered on this. As far as I can tell, in-the-line
> editing does work, but history doesn't. Is history the main functionality
> that you need?

Yes exactly.

Entering text on the prompt and typing arrow keys on the actual input
will position the cursor so that I can, for example, insert some more
text. (Previously the left-arrow key just created ^[[D^[[D^[[D ...)

What I primarily needed was to get the previously entered data (which
has already be confirmed by <return>) back into the prompt. If I can't
reload the previous text into the prompt the arrow-movement isn't very
useful [on the empty prompt].

The use-case is that I send words to a server and depending on the
server response I may have to adjust/refine the previous input (without
typing all again).

Sorry if I was unclear about that.

>
> FWIW, it sure seems to me that there should be a way to get history to work.

Yeah, I have to see...

Janis

On 14.01.2024 19:13, Jim Jackson wrote:
>
> This works for me. It's the stripped down version of a couple of scripts
> I use every login session ...

It indeed looks good; I can retrieve the history entries with the arrow
up/down keys, then navigate with the arrow left/right keys (and also
with the Vi keys), I can even issue Vi commands, etc. - Nice. - Thanks.

Janis

> #!/bin/bash
>
> HISTFILE=$HOME/.history.test
> HISTNUM=200
>
> while $loop ; do
> echo
> set -H -o history
> history -r
> read -p "prompt : " -e ans
> echo "$ans" >> $HISTFILE
> case "$ans" in
> q|quit|Q|Quit|QUIT)
> exit 0
> ;;
> esac
> done
>
>
> HTH
> Jim
>

On 2024-01-14, Jim Jackson <jj@franjam.org.uk> wrote:

> This works for me. It's the stripped down version of a couple of scripts
> I use every login session ...
>
> #!/bin/bash
>
> HISTFILE=$HOME/.history.test
> HISTNUM=200
>
> while $loop ; do
> echo
> set -H -o history

Oh! That's better. We can enable history in a non-interactive
shell and push input lines into the history:

#!/usr/local/bin/bash
set -o history
while IFS= read -r -e -p "prompt> " line
do
echo "[$line]"
history -s "$line"
done

That's the bash solution to Janis's original problem.

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