[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

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


Kind regards,
Stefan Krusche

Reply to: