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?
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?
In article <untn92$3t3gn$[email protected]>,
Janis Papanagnou <[email protected]> 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.
Janis Papanagnou <[email protected]> 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)"´.
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?
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 ?
On 2024-01-13, Janis Papanagnou <[email protected]> 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.
In article <unu4rb$3v226$[email protected]>,
Janis Papanagnou <[email protected]> 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.
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 ?
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?
with <untn92$3t3gn$[email protected]> 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?
A while back I was playing with ksh93 and wrote a "Word Of The Day"
script presents [...]
Anyway, maybe it's useful to you:
gopher://sdf.org/0/users/jgw/Misc/wotd.ksh
On 13.01.2024 17:47, Eric Pozharski wrote:
with <untn92$3t3gn$[email protected]> 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.
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 article <unuc23$3ve$[email protected]>,
Janis Papanagnou <[email protected]> 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.
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?
HISTFILE="${HOME}/.prompt.history"
HISTSIZE=50
set -o vi
while IFS= read -r -s word?"prompt> "
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).
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:
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.
Anyway, that's bash. Maybe it is different in ksh.
On 2024-01-21, Kenny McCormack <[email protected]> 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.
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, I'll stick with my getline extension.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 135:13:27 |
| Calls: | 12,087 |
| Files: | 14,997 |
| Messages: | 6,517,362 |