*** Bug 401031 has been marked as a duplicate of this bug. ***

Confirming because of the duplicate.

Created attachment 210583 [details]
screenshot of binary comparison

I use a little wrapper script like so...

#!/bin/bash
PROG=$(basename $0)
TEMP1=/tmp/$PROG-$$-FILE1.tmp
TEMP2=/tmp/$PROG-$$-FILE2.tmp
usage() { echo "usage: $PROG FILE1 FILE2"; exit 1; }
cleanup() { rm -f $TEMP1; rm -f $TEMP2; }
[[ $# -ne 2 ]] && { echo "error: missing FILE argument(s)"; usage; }
[[ -f $1 ]]  || { echo "error: FILE1 ($1) is not a file"; usage; }
[[ -f $2 ]]  || { echo "error: FILE2 ($2) is not a file"; usage; }
trap cleanup EXIT
hexdump -C $1 >$TEMP1
hexdump -C $2 >$TEMP2
meld $TEMP1 $TEMP2

I use this wrapper as a nautilus script (hence the fancy Usage() with zenity): when invoked with directories, it uses a recursive md5sum on each file (useful in 3-way comparisons); when invoked with files, it uses Paul Durgas' hexdump -C idea

Latest version can always be found at https://github.com/MestreLion/scripts/blob/master/meld-bin


By the way... this is a 6-year old bug... any chance a dev will look into this?

#!/bin/bash

myname="${0##*/}"

usage() {
	msg="$1\nUsage: $myname <FILE|DIR> <FILE|DIR> [FILE|DIR]\n"
	if [[ "$TERM" == "dumb" ]] && type zenity >/dev/null 2>&1 ; then
		msg="${msg//&/&amp;}"
		msg="${msg//</&lt;}"
		zenity --info --no-wrap --text "$msg"
	else
		printf "%b" "$msg" >&2
	fi
	exit 1
}

md5sumdir() (
	cd "$1"
	find . -type f -exec md5sum {} + | LC_ALL=C sort -f --key=2
)

case $# in
	2|3)
		# set the trap with swapped quotes for delayed array evaluation
		trap 'rm -f -- "${items[@]}"' EXIT
		items=()

		while (( $# )) ; do
			tempfile=$(tempfile --prefix "_" --suffix "_${1//\//_}")
			items+=( "$tempfile" )

			[[ -f "$1" ]] && hexdump -C "$1" > "$tempfile"
			[[ -d "$1" ]] && md5sumdir  "$1" > "$tempfile"
			shift
		done
	;;
	*) usage "$myname requires either 2 or 3 arguments";;
esac

meld "${items[@]}"

Created attachment 230704 [details]
Comparison of 2 hex files (1 byte difference) done with meld-hex.sh

I think the problem with scripts that use hexdump - it is impossible to align to random symbol in the line.

For example if the only difference between 2 binary files is an extra XX byte in the beginning of either one of them then comparison of hexdumps will show you that each line has difference - which is obviously not a case (refer to "Comparison of 2 hex files (1 byte difference) done with meld-hex.sh" screen-shot attached).

In other words implementation of correct hex compare is not that straight-forward task.

For example "hexdiff" will show 2 files completely different for the case above.
"dhex" shows difference correctly so anybody may want to look into its guts.
I didn't find origin of its sources, but at least they're available in Lunchpad: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/dhex/raring/files

Some googling about dhex led me to:

Ubuntu's package home page:
http://packages.ubuntu.com/raring/dhex

Debian package:
http://packages.debian.org/sid/dhex

Upstream website:
http://www.dettus.net/dhex/

As for the alignment issues in hexdump, I still think *some* diff is better than no diff at all. For binaries, sometimes just saying if files are different or identical is enough, and not even hexdump is needed for that. I would be glad if meld did that. Hex-diff (either via hexdump or dhex) is just a convenience, and it is welcome despite lack of proper alignment.

Personally I think a simple "these binary files are the same" or "these binary files differ" message (depending on the case) would satisfy. 

I use a Nautlus script to select one file, and then select the next to compare. And it would be nice if it worked for binary files as well. (As it is, I just do an MD5 hash for both files, and compare the hash. But this is far from ideal, not to mention MD5 is broken for this purpose, as there are attacks on it -- SHA2 would be better if you had to worry about attacks.)

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/10.