Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Command line tr behaving different to Linux

I've been writing scripts to automate image building for various embedded software projects, but I found tr is behaving differently on my Mac to my Linux PC.

I'm essentially trying to generate an 0xFF padded image.

Linux yields (as expected):

tr '\000' '\377' < /dev/zero | hexdump

0000000 ffff ffff ffff ffff ffff ffff ffff ffff

But MacOS Terminal gives me:

tr '\000' '\377' < /dev/zero | hexdump

0000000 c3 bf c3 bf c3 bf c3 bf c3 bf c3 bf c3 bf c3 bf

I can't figure out exactly what's going on, I guess MacOS is interpreting the octal differently. I have a workaround using Python, but this is bugging me! Can anyone here tell me what's going on?

Thanks

MacBook Pro, OS X Mountain Lion (10.8.2), MacOS Terminal

Posted on Feb 14, 2013 3:52 AM

28 replies

Linc Davis

Level 10

209,547 points

Feb 14, 2013 3:12 PM in response to Frank Caggiano

I don;t have a BASH_VERSION environmental variable set. Should that be happening automatically or are you setting it and could that indicate something?

It's a built-in, read-only parameter. I tend to doubt that you don't have it, but if you really don't, something is wrong.

Feb 14, 2013 3:33 PM in response to Linc Davis

Ok I'll look into that. In the meantime what about the strings output?

Message was edited by: Frank Caggiano - OK forget the BASH_VERSION thing I must have fat fingered it or something it is set Pandora:~ frank$ echo $BASH_VERSION 3.2.48(1)-release Pandora:~ frank$

Feb 14, 2013 4:02 PM in response to Frank Caggiano

I've been away from my computer, I'm at home now, and on my personal computer (not my work laptop) I'm still seeing the strangeness. Here's what my terminal say's...

Frijoles-MacBook:~ frijole$ /usr/bin/tr '\000' '\377' < /dev/zero | hexdump

0000000 c3 bf c3 bf c3 bf c3 bf c3 bf c3 bf c3 bf c3 bf

Frijoles-MacBook:~ frijole$ tr '\000' '\377' < /dev/zero | hexdump

0000000 c3 bf c3 bf c3 bf c3 bf c3 bf c3 bf c3 bf c3 bf

Frijoles-MacBook:~ frijole$ echo $BASH_VERSION

3.2.48(1)-release

Frijoles-MacBook:~ frijole$ uname -v

Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64

Frijoles-MacBook:~ frijole$ which tr

/usr/bin/tr

Frijoles-MacBook:~ frijole$ which hexdump

/usr/bin/hexdump

Frijoles-MacBook:~ frijole$ strings /usr/bin/tr

$FreeBSD: src/usr.bin/tr/cmap.c,v 1.2 2004/07/14 08:36:09 tjr Exp $

$FreeBSD: src/usr.bin/tr/cset.c,v 1.3 2004/07/14 08:33:14 tjr Exp $

$FreeBSD: src/usr.bin/tr/str.c,v 1.24 2004/11/14 05:15:25 jkh Exp $

$FreeBSD: src/usr.bin/tr/tr.c,v 1.24 2005/04/09 14:31:41 stefanf Exp $

@(#)PROGRAM:tr PROJECT:text_cmds-84

cmap_splay

/SourceCache/text_cmds/text_cmds-84/tr/cmap.c

t != NULL

cset_delete

/SourceCache/text_cmds/text_cmds-84/tr/cset.c

cset_rangecmp(t, ch) == 0

cset_splay

genrange() malloc

misplaced sequence asterisk

illegal sequence count

misplaced equivalence equals sign

unknown class %s

upper

lower

Ccdsu

strdup(argv[1])

empty string2

usage: tr [-Ccsu] string1 string2

tr [-Ccu] -d string1

tr [-Ccu] -s string1

tr [-Ccu] -ds string1 string2

rune

Linc Davis

Level 10

209,547 points

Feb 14, 2013 4:59 PM in response to FrijolePerezoso

What do you get from this:

printf '\0' | tr '\0' '\377' | hexdump

Feb 14, 2013 5:54 PM in response to FrijolePerezoso

You're string output is what I have. It would be nice to know what Linc's shows but he doesn;t seem to want to share that information with us.

Until this is figured out you can download the GNU tr I posted in one of my responses above. It will at least let you get on with your work.

Message was edited by: Frank Caggiano

Feb 14, 2013 5:52 PM in response to Linc Davis

Pandora:~ frank$ printf '\0' | tr '\0' '\377' | hexdump

0000000 c3 bf

0000002

Pandora:~ frank$

Any reason not sharing the strings output? I just went on a system that is virgin 10.8.2. Never had an account on it, never logged in before. Logged in as guess and get the same response from tr.

There has to be something about our systems that is different. There of us are all getting the same response which is wrong and different from yours.

Again the strings output will probably not show us anything but it would eliminate one other possibility

Linc Davis

Level 10

209,547 points

Feb 14, 2013 6:23 PM in response to Frank Caggiano

The "strings" output is irrelevant. I'm using the system binary. If you want something to compare, use this:

MD5 (/usr/bin/tr) = 99e19fcbae62d356e3af836572542e60

etresoft

Level 8

46,390 points

Feb 14, 2013 6:40 PM in response to FrijolePerezoso

Linux doesn't handle Unicode in the Terminal like the Mac does. If you set the "LANG" environment variable to "C" (as it probably is on Linux), it will work. Otherwise, all those high-order bits are going to get interpreted as Unicode characters.

Feb 14, 2013 6:51 PM in response to etresoft

Thank you, thank you, thank you. I can now go to bed a happy camper!!! 🙂

OK that fixes it for the tr that comes with OS X but can you explain why the GNU version whicj I compiled locally works on OS X without modifying the LANG variable?

again thanks

Linc Davis

Level 10

209,547 points

Feb 14, 2013 6:50 PM in response to Linc Davis

I can reproduce the problem by changing the value of LC_ALL parameter from "C" to "us". So set it to "C".

Feb 15, 2013 1:30 AM in response to etresoft

HOORAY!

LANG=C works for me! Many thanks 🙂

etresoft

Level 8

46,390 points

Feb 15, 2013 6:38 AM in response to Frank Caggiano

Frank Caggiano wrote:

OK that fixes it for the tr that comes with OS X but can you explain why the GNU version whicj I compiled locally works on OS X without modifying the LANG variable?

Because BSD utilities are more advanced than GNU. According to the documentation, GNU tr doesn't support multibyte characters.

Feb 15, 2013 7:25 AM in response to etresoft

Thanks much

Command line tr behaving different to Linux