Re: Bash-Problem with cursor position after calling a function with READLINE_LINE
On Fri 07 Sep 2018 at 18:40:51 (+0200), Stefan Krusche wrote:
> 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.
As I posted, I get the same behaviour whichever shebang I have,
any of bash|dash|sh.
> > 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.
Nor mine. Once you've pressed F1 on the command line, you've entered
the script and the script doesn't need it.
> 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?
That doesn't concern me. I'm only looking at the minimal working example posted.
> > 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
Correction here: it's a bash shell, but it's invoked in the same
manner as the shell that executed the bind. So, if you perform this
test on a VC login shell, the subshell says "-bash". If you start a
shell with "bash -i" and perform the test, it's subshell will also
say "bash -i".
> > 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...?
Well, you've written "when that script's filename is called". What
else is that but asking the system to execute the script. That's what
the bind was for.
If the script has no shebang, then (I assume) the system will run a
shell to execute it. As under correction above, it appears to start up
this new shell with the same command line as the one it's running in.
I had thought it might look at $SHELL, but it appears not.
> 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).
I've not played with any of this before, so it's all new to me and I
can only report what I find as I find it. (I don't have a use case.)
It would be interesting to know how it interacts with bash functions,
for example, as opposed to external scripts. Could an ambitious person
write a TOPS-20 style commandline system including the noise words
with it?
Cheers,
David.
Reply to: