Re: Bash-Problem with cursor position after calling a function with READLINE_LINE
- Date: Sat, 08 Sep 2018 17:07:04 +0200
- From: "Thomas Schmitt" <scdbackup@xxxxxxx>
- Subject: Re: Bash-Problem with cursor position after calling a function with READLINE_LINE
David Wright wrote:
> As I posted, I get the same behaviour whichever shebang I have,
> any of bash|dash|sh.
That's probably because there is bash-ism in the script, except the
variable READLINE_LINE which the boss bash is supposed to have set.
> 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.
https://manpages.debian.org/stretch/bash/bash.1.en.html says after having
explained how the file is looked up:
If the search is successful, or if the command name contains one or
more slashes, the shell executes the named program in a separate
execution environment. Argument 0 is set to the name given, and the
remaining arguments to the command are set to the arguments given,
So it may be that the Linux kernel decides what to do. The man page
goes on with:
If this execution fails because the file is not in executable format,
and the file is not a directory, it is assumed to be a shell script,
a file containing shell commands. A subshell is spawned to execute it.
This subshell reinitializes itself, so that the effect is as if a new
shell had been invoked to handle the script, with the exception that
the locations of commands remembered by the parent (see hash below
under SHELL BUILTIN COMMANDS) are retained by the child.
I'd expect that a script without "#!" falls in this category.
It seems that here we have the difference between Jessie and Stretch.
The man page then explains what happens if "#!" is seen:
If the program is a file beginning with #!, the remainder of the first
line specifies an interpreter for the program. The shell executes the
specified interpreter on operating systems that do not handle this
executable format themselves.
So again, it may be that the kernel decides to execute the interpreter
program with the script, or it can tell the shell to handle this on its
Whatever happens, it works on Stretch.
My main suspect would be the statement in the middle quote about scripts
"This subshell reinitializes itself"
Obviously this differs from the initialization of a freshly started new
shell, or from the cleanup in the momma shell before the fork and start
of an external program.
Have a nice day :)