In UTF-8 locales: $ scp é z localhost:/tmp é 100% 0 0.0KB/s 00:00 z 100% 0 0.0KB/s 00:00 It seems that scp thinks that "é" has two characters since it has two bytes in UTF-8. I originally reported this bug against Debian in 2007[*], and it is still present. [*] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407088
Ingo Schwarze just did some work on the progressmeter and its support for utf8: https://anongit.mindrot.org/openssh.git/log/?qt=author&q=schwarze@openbsd.org+&showmsg=1 The work is already in the snapshots http://www.mindrot.org/openssh_snap/ and will be in the 7.3 release. Does that fix the problem you're reporting?
(In reply to Darren Tucker from comment #1) > Does that fix the problem you're reporting? I've tried Debian's openssh-client 1:7.3p1-1, and the problem is still there: cventin:~> scp é z localhost:/tmp Connected to cventin (from 127.0.0.1) é 100% 0 0.0KB/s 00:00 z 100% 486 1.3MB/s 00:00
Created attachment 2860 [details] screenshot Note: there's currently a problem with bugzilla, which interprets my UTF-8 characters as ISO-8859-1. I've attached a screenshot.
(In reply to Vincent Lefevre from comment #3) > Created attachment 2860 [details] > screenshot > > Note: there's currently a problem with bugzilla, which interprets my > UTF-8 characters as ISO-8859-1. I've attached a screenshot. The PNG file has been corrupted in the upload, so that it isn't visible either!
It appears that my comments have been modified! "é" should appear as "é" (so that the alignment issue is now no longer visible). Without the accent over the "e" (if it gets corrupt again), that would give: $ scp e z localhost:/tmp e 100% 0 0.0KB/s 00:00 z 100% 0 0.0KB/s 00:00 showing the alignment issue.
That's wrong again. It seems to be a bug in the current Bugzilla, which does a spurious ISO-8859-1 to UTF-8 transformation, while the input is already in UTF-8 (note: I've checked that the page in interpreted as UTF-8 by my browser, and the double encoding is also visible by downloading the HTML source).
Are you able to replicate this with a recent OpenSSH? There have been quite a few fixes in this area since 7.x.
Yeah it's still there. It's kinda hard to follow what progressmeter is doing composing the status line into a single buffer, we should probably put the component parts into their own dynamically allocated buffer and compose the final one with a single asmprintf.