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

[Manuel Contreras]

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

test results listed below (same test.file exists on both boxes)...

$ remsh goodBOX -n " head -1 test.file | cut -c60-69 | tr '[a-z]' '[A-Z]'>
OABMIS02


$ remsh badBOX -n " head -1 test.file | cut -c60-69 | tr '[a-z]' '[A-Z]'"
��hr02

without the tr:
$ remsh badBOX -n " head -1 165700047_20100728_095914 | cut -c60-69 "
OABMIS02


the above command works correctly when performed locally...


already checked the tr executable...same on both boxes:

> ll /usr/bin/tr
-r-xr-xr-x 1 bin bin 76508 Feb 15 2007 /usr/bin/tr*

> cksum /usr/bin/tr
3992625266 76508 /usr/bin/tr



largest difference between boxes is goodBOX has a 2007 quality pack, and the badBOX is 2008.

input is appreciated...
manny

[Manuel Contreras]

thought I would provide another example:

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

$ remsh goodBOX "echo abCd | tr '[a-z]' '[A-Z]'"
ABCD

[Dennis Handly]

>the above command works correctly when performed locally.

In the same directory? Also, try using the absolute path to tr(1).

Since you are using '', it can't be filename completion that is expanding your strings.

It could possibly be your locale settings?

[Manuel Contreras]

I like the latest echo example, as it simplifies the test.

locally works fine:
> echo abCd | /usr/bin/tr '[a-z]' '[A-Z]'
ABCD


remotely does not :(
$ remsh badBOX "echo abCd | /usr/bin/tr '[a-z]' '[A-Z]'"
ABbD


does work on goodBOX:
$ remsh goodBOX "echo abCd | /usr/bin/tr '[a-z]' '[A-Z]'"
ABCD


both boxes are 11.31

[Dennis Handly]

What happens if you invoke a remote script like:
#!/usr/bin/sh
env
echo "The tr output ====="
echo 'abCd' | /usr/bin/tr '[a-z]' '[A-Z]'

[Manuel Contreras]

$ remsh badBOX "/home/is/testuser/test.sh"
_=/usr/bin/env
LANG=en_US.iso88591
PATH=/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/contrib/bin:/usr/local/bin:
LOGNAME=testuser
SHELL=/usr/bin/ksh
HOME=/home/is/testuser
PWD=/home/is/testuser
TZ=PST8PDT
The tr output =====
ABbD
$

[Matti_Kurkela]

Several possible causes:

1.) tr makes a wrong conversion on plain US-ASCII character "C", which would be pretty weird indeed.

2.) tr works OK, but something in the data transmission chain converts the uppercase C to lowercase b (or to something else that ultimately ends up displayed as lowercase b). Strange but possible, if your terminal/emulator includes key macro features.

3.) something else, more information needed.


To test (and possibly exclude) hypothesis 2) and to get more information, we need a way to express the characters without directly inputting them. The "printf" command and the ASCII code table (see "man 5 ascii") are helpful here.


Connection sanity check in remote -> local direction:

remsh badBOX 'printf "\\141\\142\\103\\144\\n"'

(output should be "abCd"; if it's something else, the output of badBOX is being modified on the way from the badBOX to the local display.)


Connection sanity check in local -> remote direction:
remsh badBOX "echo abCd | od -b"

(output should include "141 142 103 144 012" which is abCd + line termination character expressed in octal ASCII codes; if the codes are different, your input is being modified on the way from local to badBOX.)


Explicit remote tr sanity check:

remsh badBOX 'printf "\\141\\142\\103\\144\\n" | /usr/bin/tr "[a-z]" "[A-Z]" | od -b'

(output should include "101 102 103 104 012" which is ABCD + line termination character expressed in octal ASCII codes)

MK

[Manuel Contreras]

To test (and possibly exclude) hypothesis 2) and to get more information, we need a way to express the characters without directly inputting them. The "printf" command and the ASCII code table (see "man 5 ascii") are helpful here.


Connection sanity check in remote -> local direction:

remsh badBOX 'printf "\\141\\142\\103\\144\\n"'

(output should be "abCd"; if it's something else, the output of badBOX is being modified on the way from the badBOX to the local display.)


$ remsh badBOX 'printf "\\141\\142\\103\\144\\n"'
abCd




Connection sanity check in local -> remote direction:
remsh badBOX "echo abCd | od -b"

(output should include "141 142 103 144 012" which is abCd + line termination character expressed in octal ASCII codes; if the codes are different, your input is being modified on the way from local to badBOX.)


$ remsh badBOX "echo abCd | od -b"
0000000 141 142 103 144 012
0000005




Explicit remote tr sanity check:

remsh badBOX 'printf "\\141\\142\\103\\144\\n" | /usr/bin/tr "[a-z]" "[A-Z]" | od -b'

(output should include "101 102 103 104 012" which is ABCD + line termination character expressed in octal ASCII codes)


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


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




Matti, thanks for your Extended analysis.

[Dennis Handly]

>MK: Connection sanity check in local -> remote direction:
>remsh badBOX "echo abCd | od -b"

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

What architecture/model are the two boxes?

Perhaps the next check is to do all this on the badBOX in your home directory. Invoke the script with:
env -i ./script

#!/usr/bin/ksh

export _=/usr/bin/env
export LANG=en_US.iso88591
export PATH=/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/contrib/bin:/usr/local/bin:
export LOGNAME=testuser
export SHELL=/usr/bin/ksh
export HOME=/home/is/testuser
export PWD=/home/is/testuser
export TZ=PST8PDT

echo 'abCd' | /usr/bin/tr '[a-z]' '[A-Z]' | xd -tx1 tc


Other next steps could be putting "abCd" in a file, rather than using echo:
/usr/bin/tr '[a-z]' '[A-Z]' < file | xd -tx1 tc

[Raj D.]

Manuel,

What happens if you try with ssh , instead of remsh :

$ ssh -q badBOX "echo abCd | tr '[a-z]' '[A-Z]'"

do you get ABCD , the correct output.
- may be some flaws over remsh services.


Hth,
Raj.