This will print the offset and bytes in hex:
cmp -l file1.bin file2.bin | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
Or do $1-1
to have the first printed offset start at 0.
cmp -l file1.bin file2.bin | gawk '{printf "%08X %02X %02X\n", $1-1, strtonum(0$2), strtonum(0$3)}'
Unfortunately, strtonum()
is specific to GAWK, so for other versions of awk—e.g., mawk—you will need to use an octal-to-decimal conversion function. For example,
cmp -l file1.bin file2.bin | mawk 'function oct2dec(oct, dec) {for (i = 1; i <= length(oct); i++) {dec *= 8; dec += substr(oct, i, 1)}; return dec} {printf "%08X %02X %02X\n", $1, oct2dec($2), oct2dec($3)}'
Broken out for readability:
cmp -l file1.bin file2.bin |
mawk 'function oct2dec(oct, dec) {
for (i = 1; i <= length(oct); i++) {
dec *= 8;
dec += substr(oct, i, 1)
};
return dec
}
{
printf "%08X %02X %02X\n", $1, oct2dec($2), oct2dec($3)
}'
To me, it still seems likely to be an ASCII vs. binary mode problem, despite the test you did with your desktop client. Your desktop client may be smarter than the command-line FTP client on the sending server (your local server that you're running your script on).
For example, if the local server is Windows (which uses CRLFs as line endings) and the remote server is Unix (which uses just LFs as line endings), and you're not specifying binary mode and your FTP software doesn't auto-detect it and do the right thing, then you'd be using ASCII mode for the transfer, which should strip the CRs off of any CRLF pairs. If your gzipped tarball happens to have the byte pattern 0x0d0a appearing in it anywhere, it would lose the 0x0d.
If the command-line FTP client on your sending system (I guess that's your local server) is anything like the one on my system, all you'd have to do to test this theory is to add the binary
command before or after the cd
line:
cd $FSBACKDIR
ATTACH='for file in *$DATE.tar.gz; do echo -n -e "put ${file}\n"; done'
ftp -nv <<EOF
open $FTPHOST
user $FTPUSER $FTPPASS
binary
cd $FTPDIR
$ATTACH
quit
EOF
One last thought: If it's not ASCII vs binary mode after all, I'd look to see if maybe the FTP ALG in a NAT gateway between your local and remote server (or between the remote server and your desktop) is somehow corrupting the file in transit. I suppose it could also be some other kind of proxy in between hosts, not specifically a NAT gateway's FTP ALG.
Best Answer
Yes. Per the dd man page, you are looking for something like:
where
_filename_n_
is replaced with an actual filename.bs=1
means thatcount
andskip
are byte counts.skip
is how many to skip;count
is how many to copy. Edit byte counts start from 0, not 1. Therefore, to start at the first byte, useskip=0
(or leaveskip
unspecified).As a bash function, you could use:
and then call it as
(with k=
0
because byte numbers start at zero).With the
${3:+...}
, you can leave off the output file or the input file. E.g.,