[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
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.


Reply to: