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 18:40:51 (+0200), Stefan Krusche wrote:
> > > 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.
OK, got it. "bind -x" handles the argument to the key as a shell command.
> 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?
Thanks for food for thought, David. The question why, and where exactly, the
different behaviour emerges, remains unanswered for me. It would be interesting
to know how the OP actually solved his problem.