Copy/Paste Can't Handle Nonprinting Characters

[Yani Raafezaj]

Binary package hint: ghex

I was trying to create a binary file. In insert mode, I selected a 32-byte region consisting solely of 0x90 bytes, copied it (tried both menu and CTRL+C) and pasted (both menu and CTRL+V). Instead of getting the text I had copied, I got this in the text field:

"\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff"

Further testing with other text gave three different results seemingly at random; result 3 is the most common.
1) The paste command did nothing
2) The program quit abruptly
3) Non-printing characters below 0x7f are ignored, all bytes from 0x80 to 0xff inclusive are replaced with "\Uffffffff" in the text and the hex values corresponding to this string in the binary field.

I'm running Ubuntu 8.10 (Intrepid Ibex), with the following output from apt-cache policy ghex:

ghex:
  Installed: 2.22.0-1ubuntu1
  Candidate: 2.22.0-1ubuntu1
  Version table:
 *** 2.22.0-1ubuntu1 0
        500 http://archive.ubuntu.com intrepid/universe Packages
        500 http://mirrors.kernel.org intrepid/universe Packages
        100 /var/lib/dpkg/status

I have attached a screenshot of the program after the problem indicated. The selected region in gray is what was pasted, the first two lines above the pasted region it is what was copied.

[Damian Yerrick (tepples)]

It appears to be treating the text as ASCII characters and trying to convert the text to Unicode, where \Uffffffff (32-bit representation of -1) represents any code unit that isn't assigned to a code point.

[Saleh Hamadeh (salehhamadeh)]

Yeah, I'm having the same problem and I'm running Ubuntu 9.10(Except that the program doesn't quit). It either doesn't respond to the copy-paste commands or doesn't copy non-ASCII characters.

[Damian Yerrick (tepples)]

Perhaps my suggestion for bug 75151 in gedit, where any unrecognized code unit is converted to a corresponding private use area code point, might apply here as well.
https://bugs.launchpad.net/gedit/+bug/75151

[albion (albiongeck)]

I recommend using bless as an alternative hex editor until this bug is fixed.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Damian Yerrick (tepples)]

It still happens over nine years later in GHex 3.18.3 in Xubuntu 18.04 LTS.

1. Open a file
2. In insert mode, add a few $FF bytes
3. Try to copy and paste the $FF bytes

Gives me this in standard error:

(ghex:3268): Gtk-WARNING **: 20:46:46.316: Error converting from text/plain;charset=utf-8 to UTF-8: invalid UTF-8

(ghex:3268): Gdk-WARNING **: 20:46:46.317: Error converting selection from UTF8_STRING

[ElTouco72 (eltouco72)]

2 years later, Ghex 3.18.4 in Ubuntu 20.04 LTS and still copy paste does not work right, which makes it pretty much unusable.
I can't believe how such a major feature for an editor can remain unfixed for so long.

[bat (jbcooper)]

Yep, 12 years after problem reported, we're still here. Bless our socks and souls ;-0

[bat (jbcooper)]

There's a 9 year old file (converter.c) saying:

"#if 0 /* Pasting is not working. gtk is doing weird things. Chema */ "

Does anyone know have any clues on how to fix this?

[Olivier Robert (novhak)]

That logic is beyond me... One one hand the XConq package is removed, but on the other hand, this remains untouched during more than ten years. Considering how largely unusable it is, it should have been removed ages ago.

[bat (jbcooper)]

Hello, this is now fixed in version 3.41 of gHex which you can get from the git repo. Great news!

[ElTouco72 (eltouco72)]

it's not quite true
it just copies character as is. so with non ascii char you get things like that

È'Q7
ß

it should copies the hex values...

so no it is not fixed