Copy/Paste Can't Handle Nonprinting Characters

Bug #364874 reported by Yani Raafezaj
36
This bug affects 8 people
Affects Status Importance Assigned to Milestone
ghex (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

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.

Revision history for this message
Yani Raafezaj (ytraaf) wrote :
Revision history for this message
Damian Yerrick (tepples) wrote :

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.

Revision history for this message
Saleh Hamadeh (salehhamadeh) wrote :

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.

Revision history for this message
Damian Yerrick (tepples) wrote :

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

Revision history for this message
albion (albiongeck) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ghex (Ubuntu):
status: New → Confirmed
Revision history for this message
Damian Yerrick (tepples) wrote :

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

Revision history for this message
ElTouco72 (eltouco72) wrote :

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.

Revision history for this message
bat (jbcooper) wrote :

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

Revision history for this message
bat (jbcooper) wrote :

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?

Revision history for this message
Olivier Robert (novhak) wrote :

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.

Revision history for this message
bat (jbcooper) wrote (last edit ):

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

Revision history for this message
ElTouco72 (eltouco72) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.