Re: Bash-Problem with cursor position after calling a function with READLINE_LINE
Am Freitag, 7. September 2018 schrieb David Wright:
> 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...
Should be "#!/bin/bash" of course.
> 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.
Yes, F1 is bound in the parent shell which is bash. In the sh subshell F1 is
not bound, but that wasn't my point. I remembered to have seen the unwanted
behaviour from invoking plain sh in a bash shell and thought it might have to
do with the actual script the OP is trying to make work.
> 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.
Same here. I wasn't able to provoke any error either, at least not with the
little script containing only a shebang and 'echo "${READLINE_LINE}"'. But who
knows how the OP's original script is supposed to work?
> 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
Not sure if I understand this here. Why would F1 invoke a subshell, or even
execute "_bash_man", when that script's filename is called, which has no
shebang as first line...?
Either way, with or without shebang, I'd expect a subshell being invoked without
readline support (because it would not be interactive), but that's neither the
case on my system (see above).
M2C
Kind regards,
Stefan Krusche
Reply to: