Re: Bash-Problem with cursor position after calling a function with READLINE_LINE
On Fri 07 Sep 2018 at 14:58:48 (+0200), Stefan Krusche wrote:
> Am Freitag, 7. September 2018 schrieb Norbert Gruener:
> > Hi Stefan,
> >
> > >> bash^[[D^[[C^[[B^[[A
> > >
> > > This reminds me of programs (ed, rcs, telnet etc.) which don't use
> > > readline and have less command line editing capabilities. Backspace
> > > should work, though.
> >
> > It is exactly my impression too. But I could not find any hint why the
> > »command line editing « should be deactivated in that case.
>
> Maybe, just maybe... ;-) the cause lies in what you use as a shebang in your
> script. If I do:
> $ sh
> I get a dash subshell on my system which has apparently no command line editing
> with readline configured and I get the cursor movement sequences printed
> instead of being translated/executed by the terminal.
>
> On the other side changing the shebang to "#/bin/sh" instead of "#/bin/bash"
> didn't change the behaviour of that little script with the bound F1 key, works
> just as before...
I'm not quite sure I follow your argument. AIUI you need to be running
a bash shell to be able to bind the F1 key in the first place.
The only way I can provoke the errant behaviour is to have no shebang
in the script. Otherwise it all works as normal with bash, dash and sh.
With a shebang, the parent process of the script is reported as
/bin/dash /home/david/bin/_bash_man
(and the shell corresponds to the dash|bash|sh shebang).
But without any shebang, the parent is reported as just
bash
which I assume is another subshell being invoked at the start of the
script. As I don't know how the proper mechanism actually works, I
can't explain why the extra shell makes it fail, though I don't find
it particularly surprising.
Cheers,
David.
Reply to: