Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #199837 > unrolled thread

Bash-Problem with cursor position after calling a function with READLINE_LINE

Back to article view | Back to linux.debian.user

Contents

  Bash-Problem with cursor position after calling a function with  READLINE_LINE Norbert Gruener <norbert@norbert-gruener.de> - 2018-09-06 18:10 +0200
    Re: Bash-Problem with cursor position after calling a function with READLINE_LINE "Thomas Schmitt" <scdbackup@gmx.net> - 2018-09-06 18:30 +0200
      Re: Bash-Problem with cursor position after calling a function with  READLINE_LINE Norbert Gruener <norbert@norbert-gruener.de> - 2018-09-06 18:50 +0200
        Re: Bash-Problem with cursor position after calling a function with READLINE_LINE "Thomas Schmitt" <scdbackup@gmx.net> - 2018-09-06 20:40 +0200
          Re: Bash-Problem with cursor position after calling a function with  READLINE_LINE Norbert Gruener <norbert@norbert-gruener.de> - 2018-09-07 08:40 +0200
    Re: Bash-Problem with cursor position after calling a function with READLINE_LINE Stefan Krusche <linux@stefan-krusche.de> - 2018-09-07 12:10 +0200
      Re: Bash-Problem with cursor position after calling a function with  READLINE_LINE Norbert Gruener <norbert@norbert-gruener.de> - 2018-09-07 14:50 +0200
        Re: Bash-Problem with cursor position after calling a function with READLINE_LINE Stefan Krusche <linux@stefan-krusche.de> - 2018-09-07 15:00 +0200
          [SOLVED} Re: Bash-Problem with cursor position after calling a  function with READLINE_LINE Norbert Gruener <norbert@norbert-gruener.de> - 2018-09-07 15:20 +0200
            Re: [SOLVED} Re: Bash-Problem with cursor position after calling a function with READLINE_LINE Stefan Krusche <linux@stefan-krusche.de> - 2018-09-07 15:30 +0200
          Re: Bash-Problem with cursor position after calling a function with  READLINE_LINE David Wright <deblis@lionunicorn.co.uk> - 2018-09-07 16:50 +0200
            Re: Bash-Problem with cursor position after calling a function with READLINE_LINE Stefan Krusche <linux@stefan-krusche.de> - 2018-09-07 18:40 +0200
              Re: Bash-Problem with cursor position after calling a function with  READLINE_LINE David Wright <deblis@lionunicorn.co.uk> - 2018-09-07 20:50 +0200
                Re: Bash-Problem with cursor position after calling a function with READLINE_LINE Stefan Krusche <linux@stefan-krusche.de> - 2018-09-08 12:50 +0200
                  Re: Bash-Problem with cursor position after calling a function with READLINE_LINE Stefan Krusche <linux@stefan-krusche.de> - 2018-09-08 13:00 +0200
                    Re: Bash-Problem with cursor position after calling a function with  READLINE_LINE Curt <curty@free.fr> - 2018-09-08 16:40 +0200
                      Re: Bash-Problem with cursor position after calling a function with  READLINE_LINE Norbert Gruener <norbert@norbert-gruener.de> - 2018-09-13 12:30 +0200
                Re: Bash-Problem with cursor position after calling a function with READLINE_LINE "Thomas Schmitt" <scdbackup@gmx.net> - 2018-09-08 17:10 +0200
                  Re: Bash-Problem with cursor position after calling a function with READLINE_LINE "Thomas Schmitt" <scdbackup@gmx.net> - 2018-09-08 18:20 +0200
      Re: Bash-Problem with cursor position after calling a function with  READLINE_LINE mick crane <mick.crane@gmail.com> - 2018-09-07 18:10 +0200
    Re: Bash-Problem with cursor position after calling a function with  READLINE_LINE Jude DaShiell <jdashiel@panix.com> - 2018-09-07 16:20 +0200
      Re: Bash-Problem with cursor position after calling a function with  READLINE_LINE Norbert Gruener <norbert@norbert-gruener.de> - 2018-09-13 12:30 +0200

Page 1 of 2  [1] 2  Next page →

#199837 — Bash-Problem with cursor position after calling a function with READLINE_LINE

Hi all,

In my Bash shell (».bashrc«) I have »bind« a command to the »F1« key
   bind -x '"\eOP":"_bash_man"'        # F1 man <command>

The script »_bash_man«  looks like (it is simplified only for test reasons)

   echo "${READLINE_LINE}"


When I type »aaa« and then press »F1«, I see a new line on the screen
containing the string »aaa« and the cursor is positioned behind the
string. The »Backspace« key is doing nothing, and pressing the four
»arrow« keys just give that result

   bash^[[D^[[C^[[B^[[A

but does not move the cursor in any direction. When I press

  aaa^Az»Enter«

then the output on the screen is

  bash: zaaa: command not found

Apparently the cursor position is not set correctly and the cursor
movements are not done on the screen.


Technical detail:
  Debian: Debian GNU/Linux 9.5.0 _Stretch_
  Bash:   GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)


Any help or any information would be very much appreciated.

Cheers,
Norbert
-- 

[toc] | [next] | [standalone]

#199839 — Re: Bash-Problem with cursor position after calling a function with READLINE_LINE

Hi,

i replayed this on Jessie.
I get printed lines "aaa" for every F1 i press.
No shell prompts get printed inbetween, but rather the shell prompt
and the text "aaa" stay in the base line of the xterm.
The text "aaa" can be edited and the new text gets printed with F1.

Like after three times pressing F1:
  $
  aaa
  aaa
  abc
  $ abc

(This brings F1 back to normal:
   bind -x '"\eOP"':
)

If not your other commands in the script are to blame, then maybe your
terminal ? I use /usr/bin/xterm (which refuses to tell me its version).


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#199841

Hi Thomas,

On 9/6/18 6:28 PM, Thomas Schmitt wrote:
> Hi,
> 
> i replayed this on Jessie.

under Jessie this was working for me too.  But after my upgrade to
Stretch I got these problems   :-(

Cheers,
Norbert
-- 

[toc] | [prev] | [next] | [standalone]

#199843 — Re: Bash-Problem with cursor position after calling a function with READLINE_LINE

Hi,

Norbert Gruener wrote:
> after my upgrade to Stretch I got these problems   :-(

Did you already check whether it is a matter of the terminal program ?
If it is a bit rot problem between readline and terminal, then you
might get lucky with a different one.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#199849

Hi Thomas,

On 9/6/18 8:30 PM, Thomas Schmitt wrote:
> Hi,
> 
> Norbert Gruener wrote:
>> after my upgrade to Stretch I got these problems   :-(
> 
> Did you already check whether it is a matter of the terminal program ?
> If it is a bit rot problem between readline and terminal, then you
> might get lucky with a different one.

I have tried »xterm«, »uxterm«, and »xfce4-terminal«. The behavior was
identical in all three terminals.

Cheers,
Norbert
-- 

[toc] | [prev] | [next] | [standalone]

#199851 — Re: Bash-Problem with cursor position after calling a function with READLINE_LINE

Hallo Norbert,

Am Donnerstag, 6. September 2018 schrieb Norbert Gruener:
> Hi all,
>
> In my Bash shell (».bashrc«) I have »bind« a command to the »F1« key
>    bind -x '"\eOP":"_bash_man"'        # F1 man <command>
>
> The script »_bash_man«  looks like (it is simplified only for test reasons)
>
>    echo "${READLINE_LINE}"

I tried exactly that and it seems to work. I put only that one line in a script, 
assigned the F1 key with bind to it and it outputs just the string I typed 
before when I hit F1 like intended. No problems with cursor movements, 
backspace and any other command line editing.

I'm on Devuan ascii and run GNU bash, Version 4.4.12(1)-release 
(x86_64-pc-linux-gnu)

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

M2C

Kind regards,
Stefan Krusche

[toc] | [prev] | [next] | [standalone]

#199854

Hi Stefan,

On 9/7/18 12:07 PM, Stefan Krusche wrote:
> Hallo Norbert,
> 
> Am Donnerstag, 6. September 2018 schrieb Norbert Gruener:
>> Hi all,
>>
>> In my Bash shell (».bashrc«) I have »bind« a command to the »F1« key
>>    bind -x '"\eOP":"_bash_man"'        # F1 man <command>
>>
>> The script »_bash_man«  looks like (it is simplified only for test reasons)
>>
>>    echo "${READLINE_LINE}"
> 
> I tried exactly that and it seems to work. I put only that one line in a script, 
> assigned the F1 key with bind to it and it outputs just the string I typed 
> before when I hit F1 like intended. No problems with cursor movements, 
> backspace and any other command line editing.
> 
> I'm on Devuan ascii and run GNU bash, Version 4.4.12(1)-release 
> (x86_64-pc-linux-gnu)

it is exactly the same version like in Debian Stretch.  My guess is that
this behavior is activated because of different default values. But it's
just my guess.

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

Cheers,
Norbert
-- 

[toc] | [prev] | [next] | [standalone]

#199855 — Re: Bash-Problem with cursor position after calling a function with READLINE_LINE

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

Kind regards,
Stefan

[toc] | [prev] | [next] | [standalone]

#199856 — [SOLVED} Re: Bash-Problem with cursor position after calling a function with READLINE_LINE

Hi Stefan,

you made my day!!! :-))

On 9/7/18 2:58 PM, Stefan Krusche wrote:
> 
> 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 have inserted the sheband »#!/bin/bash« and now everything works as
expected  :-)

Thank you very much for your help

Cheers,
Norbert
-- 
Ceterum censeo
Redmond esse delendam.

[toc] | [prev] | [next] | [standalone]

#199858 — Re: [SOLVED} Re: Bash-Problem with cursor position after calling a function with READLINE_LINE

Am Freitag, 7. September 2018 schrieb Norbert Gruener:
> Hi Stefan,
>
> you made my day!!! :-))

Nice. :-)

Kind regards,
Stefan

PS: no need to CC me, I'm subscribed ;-)

[toc] | [prev] | [next] | [standalone]

#199866

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
  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, though I don't find
it particularly surprising.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#199875 — 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).

M2C

Kind regards,
Stefan Krusche

[toc] | [prev] | [next] | [standalone]

#199877

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.

[toc] | [prev] | [next] | [standalone]

#199896 — 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.

Kind regards,
Stefan

[toc] | [prev] | [next] | [standalone]

#199897 — Re: Bash-Problem with cursor position after calling a function with READLINE_LINE

Am Samstag, 8. September 2018 schrieb Stefan Krusche:
> 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.

Just read it: OP *inserted* said shebang, meaning it probably wasn't there 
before. That matches what you reported.

Cheers,
Stefan

[toc] | [prev] | [next] | [standalone]

#199902

On 2018-09-08, Stefan Krusche <linux@stefan-krusche.de> wrote:
> Am Samstag, 8. September 2018 schrieb Stefan Krusche:
>> 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.
>
> Just read it: OP *inserted* said shebang, meaning it probably wasn't there 
> before. That matches what you reported.

He also mentioned that the script was working in Jessie. So I remain
uncertain. 

I think only Norbert himself can resolve this enigma. But he's melted
back into the woodwork, as they so often do.

> Cheers,
> Stefan
>
>


-- 
‘If I can’t have long hair or any fun, I can have a cat.’ 
Ernest Hemingway, “Cat in the Rain”

[toc] | [prev] | [next] | [standalone]

#200087

On 9/8/18 4:28 PM, Curt wrote:
> On 2018-09-08, Stefan Krusche <linux@stefan-krusche.de> wrote:
>> Am Samstag, 8. September 2018 schrieb Stefan Krusche:
>>> 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.
>>
>> Just read it: OP *inserted* said shebang, meaning it probably wasn't there 
>> before. That matches what you reported.
> 
> He also mentioned that the script was working in Jessie. So I remain
> uncertain. 
> 
> I think only Norbert himself can resolve this enigma. But he's melted
> back into the woodwork, as they so often do.

I am sorry not to have responded earlier, but I did not expect so much
atttention  :-)

As I already said, this »one-liner« was working under Jessie without any
shebang line. And after I upgraded to Stretch I got the mentioned problem.

Cheers,
Norbert
-- 

[toc] | [prev] | [next] | [standalone]

#199903 — Re: Bash-Problem with cursor position after calling a function with READLINE_LINE

Hi,

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,
  if any.

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
own.
Whatever happens, it works on Stretch.


My main suspect would be the statement in the middle quote about scripts
without "#!":

  "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 :)

Thomas

[toc] | [prev] | [next] | [standalone]

#199905 — Re: Bash-Problem with cursor position after calling a function with READLINE_LINE

Hi,

i wrote:
> That's probably because there is bash-ism in the script,

Of course i meant to say:

  That's probably because there is _no_ bash-ism in the script,


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#199873

On 2018-09-07 11:07, Stefan Krusche wrote:
> Hallo Norbert,
> 
> Am Donnerstag, 6. September 2018 schrieb Norbert Gruener:
>> Hi all,
>> 
>> In my Bash shell (».bashrc«) I have »bind« a command to the »F1« key
>>    bind -x '"\eOP":"_bash_man"'        # F1 man <command>
>> 
>> The script »_bash_man«  looks like (it is simplified only for test 
>> reasons)
>> 
>>    echo "${READLINE_LINE}"
> 
> I tried exactly that and it seems to work. I put only that one line in
> a script,
> assigned the F1 key with bind to it and it outputs just the string I 
> typed
> before when I hit F1 like intended. No problems with cursor movements,
> backspace and any other command line editing.
> 
> I'm on Devuan ascii and run GNU bash, Version 4.4.12(1)-release
> (x86_64-pc-linux-gnu)
> 
>>    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.

Had something similar with vi a while back.
put
"set nocompatible
set backspace=indent,eol,start"

or something
in .vimrc

https://vi.stackexchange.com/questions/2162/why-doesnt-the-backspace-key-work-in-insert-mode

-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web