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.
