[ksh] Readline support in a read-loop ?

[Janis Papanagnou]

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

[Joerg Mertens]

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)"´.

[Kenny McCormack]

In article <untn92$3t3gn$1...@dont-email.me>,

Janis Papanagnou <janis_pap...@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.

[Janis Papanagnou]

On 13.01.2024 13:21, Joerg Mertens wrote:
> Janis Papanagnou <janis_pap...@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

[Janis Papanagnou]

On 13.01.2024 13:56, Kenny McCormack wrote:
> In article <untn92$3t3gn$1...@dont-email.me>,
> Janis Papanagnou <janis_pap...@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

[Christian Weisgerber]

On 2024-01-13, Janis Papanagnou <janis_pap...@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 na...@mips.inka.de

[Kenny McCormack]

In article <slrnuq546h...@lorvorc.mips.inka.de>,

Christian Weisgerber <na...@mips.inka.de> wrote:
>On 2024-01-13, Janis Papanagnou <janis_pap...@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 -

[Lew Pitcher]

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

> In article <slrnuq546h...@lorvorc.mips.inka.de>,
> Christian Weisgerber <na...@mips.inka.de> wrote:
>>On 2024-01-13, Janis Papanagnou <janis_pap...@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"

[Kenny McCormack]

In article <unu4rb$3v226$1...@dont-email.me>,
Janis Papanagnou <janis_pap...@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

[Janis Papanagnou]

On 13.01.2024 16:08, Kenny McCormack wrote:
> In article <unu4rb$3v226$1...@dont-email.me>,
> Janis Papanagnou <janis_pap...@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

[Janis Papanagnou]

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

[Christian Weisgerber]

On 2024-01-13, Kenny McCormack <gaz...@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.

[Eric Pozharski]

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

[jeorge]

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

[Janis Papanagnou]

On 13.01.2024 16:48, Christian Weisgerber wrote:
> On 2024-01-13, Kenny McCormack <gaz...@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...

[Janis Papanagnou]

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

[Janis Papanagnou]

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

[Chuck Martin]

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

[Kenny McCormack]

In article <unuc23$3ve$1...@dont-email.me>,

Janis Papanagnou <janis_pap...@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

[Christian Weisgerber]

On 2024-01-14, Janis Papanagnou <janis_pap...@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.

[Kenny McCormack]

In article <slrnuq7qmg...@lorvorc.mips.inka.de>,
Christian Weisgerber <na...@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) -

[Jim Jackson]

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

[Janis Papanagnou]

On 14.01.2024 14:03, Kenny McCormack wrote:
> In article <unuc23$3ve$1...@dont-email.me>,
> Janis Papanagnou <janis_pap...@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

[Janis Papanagnou]

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

[Christian Weisgerber]

On 2024-01-14, Jim Jackson <j...@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.

[Janis Papanagnou]

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

[Martijn Dekker]

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

[Janis Papanagnou]

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

[Kenny McCormack]

In article <l13gnd...@mid.individual.net>,

Martijn Dekker <mar...@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.

[Christian Weisgerber]

On 2024-01-21, Kenny McCormack <gaz...@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.

[Janis Papanagnou]

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

[Kenny McCormack]

In article <slrnuqqh9i...@lorvorc.mips.inka.de>,

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 -

[Janis Papanagnou]

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

[Kenny McCormack]

In article <uou1t8$2cbe7$1...@dont-email.me>,

Janis Papanagnou <janis_pap...@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.