Terminal / SSH related question. Trouble making edits to previous commands

[Blink]

Some up front info. I am a windows user who has dabbled in trying linux over the years. I've done some distro hopping but I'm hitting a long streak of using Linux for around 3 weeks now, although I've had a lot of minor hicccups and teething issues.

One thing that is bothering me, and is something I also experienced on windows, when using MobaXterm, is this weird behavior during remote SSH sessions to my private server.

I don't know if this is a very specific issue, or abnormal but I swear the problem either went away on Mint Cinnamon, or I did not notice it nearly as much. However it's kind of bugging me now that I'm using Kubuntu.

I don't know for sure if this is an issue related to the size of the command line strings I am using, or what but it does seem to show up more when working with very long inputs.

------------

Let's say I want to manipulate a file with ffmpeg, and I create a rather decent sized command line.

-ffmpeg -i <inputfile.ext> -map 0:0 -map 0:1 -codec:a copy -vf scale=-1:540 -b:v 1.5M <outputfile.ext>


ok so now let's say I spelled the file name wrong and it errors on me.. What do you do? Hit up arrow, hit the Home key to put you closest to the error (the start of the command line) and go edit the filename.

The only problem is, it errors again, because it just sent a malformed command line, with characters NOT inserted where they were supposed to be, and possibly replacing other characters entirely. i pretty much have to rewrite the entire command line from scratch to save on frustration of trying to get the edit point correct.

-------------

Why does this happen? This does not seem normal to me. A lot of the time I can prevent it when I need to edit a command typo, by advancing the cursor forward past the edit point, then bringing it back (slowly, precisely) without overshooting my intended edit point. That case pretty much always works... This just doesn't seem like normal behavior to me, but I am really unfamiliar with SSH as a whole, and my only guess would be this is a packet loss issue? (seems odd for a secure connection to not have redundancy), or maybe a packet order or other related issue?

Can anyone provide some thoughts on why this has happened across multiple operating systems, across two different hardware platforms? Is this just the nature of remote connections or what?
Really hoping there is something I can tweak or adjust in a config file somewhere.

[Snowhog]

Welcome to KFN.

When in Kubuntu, are you using Konsole or xTerm or ?

[Blink]

Welcome to KFN.

When in Kubuntu, are you using Konsole or xTerm or ?

Hi, sorry for neglecting to mention that. I'm currently using Yakuake

I opened up a generic Konsole terminal as well and the problem is also present there

I can note that if I move the cursor to a position on the recalled command line, it will start inserting new characters several spaces away from what is visually indicated, it usually splits the command line in a weird way so the new inserted characters may cut things "in half".

edit:

i.e if I do livestreamer 'longassURL' <opt> -o <file> but I forgot to include " hlsvariant:// " in front of the URL, if I go to insert that text at the start of the URL string, it might shove one or two characters "behind" it, then the others get inserted in front, potentially a couple spaces off from where they should be, or at the very least breaking everything because it just "split" things in half... if that makes sense. Perhaps some screenshots will be needed to illustrate what is happening

[jlittle]

IIUC, if you are in an SSH session to a private server, the prompt you see, and the handling there, comes from the shell on the server. The shell on that server has an imperfect idea of how your terminal emulator on kubuntu works.

What OS is on the server? FreeBSD?

I suggest running echo $TERM to see what the server thinks your terminal is. If it's something weird you could try setting TERM to "xterm":

TERM=xterm ssh ...

or maybe "screen".

[Blink]

shell reports xterm-256 color

the server is running Ubuntu 16.04 LTS

I've never used "screen" before for what its worth

[Blink]

Ok so here are 3 screenshots I took just a little bit ago illustrating things. This is taken from Yakuake, but I also re-created the problem in Konsole as well.


First, I put a typo in the command


Next, I attempt to correct it by hitting Up Arrow to recall the last command line entry, and then the Home key to go to the start of the line.
Then I use the Right Arrow key to navigate over to where I need to correct the missing letter to spell "ffmpeg" properly.



And finally, this is the entire output, I have also hit Up Arrow again, and it shows what was sent was completely different than what was shown as being entered in the 2nd image above.



Here is the same output from Konsole.

[jlittle]

Ok so here are 3 screenshots:...

Escape sequences in the prompt, like those that give your colours, can confuse bash's idea where the cursor is, and your problem is like that.

What are the shell variables PS1 and PROMPT_COMMAND set to? One way to reveal the (otherwise unprintable) content of these would be:

echo "$PS1" | cat -v
echo "$PROMPT_COMMAND" | cat -v

(that "|" is meant to be an ASCII vertical bar, I'm not sure what Tapatalk is giving here.)

Regards, John Little

[Blink]

blink@hacktheplanet:~$ echo "$PS1" | cat -v
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[38;5;255m\]\u\033[38;5;196m@\[\033[38;5;46m\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
blink@hacktheplanet:~$ echo "$PROMPT_COMMAND" | cat -v

blink@hacktheplanet:~$

The second entry returns nothing, not sure if that helps.

Is this just the nature of having colored text in the prompts? No real way to work around it other than having plane just prompt text?

Here is a section snippet from my bashrc config, I haven't touched it in forever and since I know very little about Linux and Bash i did use a configurator to help me design my prompt. maybe that is part of the problem, or maybe not
Wasn't sure where this section actually ended so if I didn't include enough let me know.

[FONT=monospace]# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
 xterm-color|*-256color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
 if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
     # We have color support; assume it's compliant with Ecma-48
     # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
     # a case would tend to support setf rather than setaf.)
     color_prompt=yes
 else
     color_prompt=
 fi
fi

[/FONT][FONT=monospace]if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[38;5;255m\]\u\033[38;5;196m@\[\033[38;5;46m\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
# Custom bash prompt via kirsle.net/wizards/ps1.html
#export PS1="\[$(tput bold)\]\[$(tput setaf 7)\][\u\[$(tput sgr0)\]\[$(tput bold)\]\[$(tput setaf 1)\]@\h]:\W\\$\[$(tput sgr0)\]"
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac
[/FONT]

I kind of LOL'd when I read the "the focus should be on the output not the prompt" bit, because as a user, I find coloring makes for great delineation in terminals. helps me focus where I need to be looking a lot easier especially when looking at something that might spit out gobs of text. but I guess it is what it is

[jlittle]

The coloured prompt is a practice I make use of a great deal, it's really useful. I use $(...) constructs to call functions to process parts of the prompt for flexibility and maintainability. F. ex. a function trims the current directory to the most relevant bits when in deep hierarchies, otherwise the prompt is too long.

I'll have to check out yours when I'm back on my desktop. I'll also get the details of a workaround using an editor. Do you have a favoured editor, usable with an ssh login?

Regards, John Little

[Blink]

I prefer to use Nano

Thanks

[jlittle]

Yes, PS1 is definitely the culprit. Setting PS1 to yours reproduces your problem. IMO it's an ugly mess. Here's what it's trying to be:

PS1="\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[38;5;255m\]\u\[\033[38;5;196m\]@\[\033[38;5;46m\]\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$"

There was two missing "\[" and one missing "\]". Even knowing what the problem was likely to be, it was hard to see, a case of backslash-itis.
It's a bit long winded, but I'd prefer (in .bashrc):

swt=$'\e]0;'   # set window title start sequence, \a ends it
csi=$'\e['     # control sequence introducer, called that in the ANSI standard
white="\[${csi}38;5;255m\]"
  red="\[${csi}38;5;196m\]"
green="\[${csi}38;5;46m\]"
reset="\[${csi}0m\]"
bblue="\[${csi}1;34m\]" # bold blue, but depends on the konsole profile setting

window_title="\[${swt}\u@\h: \w\a\]"
chroot='${debian_chroot:+($debian_chroot)}'
userhost="$white\u$red@$green\h$reset"
working_dir="$bblue\w$reset"

PS1="$window_title$chroot$userhost:$working_dir\$"

I'd get rid of the chroot stuff, unless you actually often use chroot. If you're wondering about those magic colour numbers, run csi=$'\e[';for ((i=0;i<256;++i));do echo -n "${csi}38;5;${i}m $i ${csi}0m"; done for the 256 colour ones. See https://www.xfree86.org/4.8.0/ctlseqs.html for the gory details.

The workaround is to set the EDITOR environment variable to "nano", and press ctrl-x ctrl-e (or if you set -o vi like I do, esc v).

[Blink]

Thanks for the help, seems to be working pretty good now.