Operating System - HP-UX
1753578 Members
6449 Online
108796 Solutions
New Discussion юеВ

Re: discovered an issue when performing a remote tr (translate) command on hpux 11v3.

 
Matti_Kurkela
Honored Contributor

Re: discovered an issue when performing a remote tr (translate) command on hpux 11v3.

The connection sanity checks were OK, so it probably isn't a remsh problem.

$ remsh badBOX 'printf "\\141\\142\\103\\144\\n" | /usr/bin/tr "[a-z]" "[A-Z]" | od -b'
0000000 101 102 142 104 012
0000005

OK, so it definitely looks like a problem with tr. But on second thought, it might be a locale problem too.

One more test:

remsh badBOX 'echo abCd | LC_ALL=C tr "[a-z]" "[A-Z]"'

Setting LC_ALL=C makes all locale-specific processing fall back to POSIX standrd US-ASCII. If this makes the problem go away, then perhaps the locale files for your default locale en_US.iso88591 (located in /usr/lib/nls/loc/) are broken on badBOX.

Perhaps someone with root access has experimented with the "localedef" command and made a little mistake?

You might also copy /usr/bin/tr from goodBOX to /tmp/tr on the badBOX, then run the tests using /tmp/tr instead of /usr/bin/tr. If this fixes the problem, then it conclusively proves that badBOX's /usr/bin/tr is broken.

------

Dennis> A better output is hex, not octal: echo abCd | xd -tx1 -tc"

Maybe, assuming that you are already familiar with hex values of ASCII characters. I would have used it if printf(1) could accept hex escapes.

But as it can't, octal is unavoidable. And as I'm already potentially confusing people, having input in octal and output in hex would make it even harder to figure out what's going on if the reader is not already familiar with all the tools and concepts I used.

MK
MK
Dennis Handly
Acclaimed Contributor

Re: discovered an issue when performing a remote tr (translate) command on hpux 11v3.

>MK: it might be a locale problem too.

That's why I had the ENVs printed.

>You might also copy /usr/bin/tr from goodBOX to /tmp/tr on the badBOX

Manny said the cksum matched. But libc and the locale libs could be different.

>assuming that you are already familiar with hex values of ASCII characters.

That's why there is ascii(5) with octal and hex.

>octal is unavoidable.

You could put the chars in a file and do a hex dump on them to prove they're correct.
Manuel Contreras
Regular Advisor

Re: discovered an issue when performing a remote tr (translate) command on hpux 11v3.

your not going to believe the root cause:

# remsh badBOX -l testuser "echo abCd | tr '[a-z]' '[A-Z]'"
ABbD

# remsh badBOX -l testuser "unset LANG;echo abCd | tr '[a-z]' '[A-Z]'"
ABCD
#

thank you all...your input is always appreciated :)

Manuel Contreras
Regular Advisor

Re: discovered an issue when performing a remote tr (translate) command on hpux 11v3.

the LANG setting was the root cause for my remote tr issues.

# remsh badBOX -l testuser "echo abCd | tr '[a-z]' '[A-Z]'"
ABbD

# remsh badBOX -l testuser "unset LANG;echo abCd | tr '[a-z]' '[A-Z]'"
ABCD


the following setting does not exist on the goodBOX:

> cat /etc/rc.config.d/LANG
#!/sbin/sh
# @(#)B.11.31_LR
# Language preference. See lang(5), hpnls(5)
#
# LANG: Locale name
#
# Note: if using the default C locale, many commands will execute faster if
# LANG is not set.
#
#LANG=C
#export LANG
LANG=en_US.iso88591

Dennis Handly
Acclaimed Contributor

Re: discovered an issue when performing a remote tr (translate) command on hpux 11v3.

>the LANG setting was the root cause for my remote tr issues.
echo abCd | tr '[a-z]' '[A-Z]'

Ah. If you want to do this, you have to be in the American Nerd locale, not this goofy dictionary sort locale.

Basically what you asked for was:
a B b .. Z z converted to:
A AE a ... Z

See /usr/lib/nls/loc/src/en_US.iso1.src LC_COLLATE category.

From the man page, you probably want:
tr '[:lower:]' '[:upper:]'