abnormal execution of "tr" command

[Mel Burslan]

# echo charlie | tr [a-z] [A-Z]
Aharlie
#
# whereis tr
tr: /usr/bin/tr /usr/share/man/man1.Z/tr.1

copied tr executable from another node into /tmp/tr

# diff /usr/bin/tr /tmp/tr
#

(no difference)

# echo abcd | /tmp/tr [a-z] [A-Z]
abAd

OS is hpux 11.11

TIA

[curt larson_1 · Accepted solution]

have you tried quoting the strings to protect from interpretation by the shell, such as:

tr "[a-z]" "[A-Z]"

[Pete Randall]

Mel,

That's extremely odd!! I tried it on my 11i workstation and it came out fine:

root# echo charlie | tr [a-z] [A-Z]
CHARLIE
root# what /usr/bin/tr
/usr/bin/tr:
$Revision: B.11.11_LR
Fri Oct 27 01:01:23 PDT 2000 $
root# uname -a
HP-UX tsws1 B.11.11 U 9000/785 2006183676 unlimited-user license


Pete

[A. Clay Stephenson]

I suspect what is going on is that the shell is strangely expanding your [a-z] [A-Z] depending upon what files are present in your CWD. Always protect your translation strings with quotes.

echo "charlie" | tr '[a-z]' '[A-Z]'

I suspect that that will work as expected.

[Marvin Strong]

Clay, I think is correct about the shell expanding the [a-z] [A-Z], try changing directories, and doing the tr again, it should work.

I can reproduce your error, from my / directory but it works fine in another directory for me.

[Mel Burslan]

I am not sure what is causing it but it really bugs me right at the moment. all other 34 servers in my data center responded right to this command but this one. Looks like, for some strange reason, it was hung on lower case c character and thinks that it maps to upper case a, as if my [a-z] [A-Z] mapping does not expand as [abcd...xyz] [ABCD...XYZ].

When I double quoted the [a-z} and [A-Z] expressions, it works. I also tried expanding the sequences by typing all 26 letters in between, this time output turned out to be

# echo abcd | /tmp/tr [abcdefghijklmnopqrstuvwxyz] [ABCDEFGHIJKLMNOPQRSTUVWXYZ]
ab[d

I was running this command as root. When I run it as my mortal userid, i.e., after running su - mortal, it works fine

Also, while I was tying this response andrefreshing the screen to read further responses, yes I changed my working directory of root, which was /root, to / or any other for that matter and the command works fine. Looking at my environment variables, there is nothing fancy about my prompt or any other signficant redirections of any sort.. strange.. but thanks for all the help

Cheers

[A. Clay Stephenson]

The fundamental wrong turn was in thinking that this was a tr problem when rather than a shell "problem". Tr was simply acting upon the data passed to it by the shell --- which was not necessarily the same thing that you typed. For the same reason that I always surround shell variables with {}'s, I always surround string constants with quotes. It that case, what you type IS what you get.

[john korterman]

Hi,
it has to do with the files in the directory on which the shell tries to perform filename substitution. If you for instance have a file whose name is "c" in the directory, then an expansion could look like this:
# ls [a-z]
c

If you also have e.g. a file named A, then the shell would expand to this:
ls [A-Z]
A

In which case your command would look like this after file name substitution:
# echo charlie | tr c A
Aharlie


It is only a suggestion; you would get a similar result even if you had no file name starting with "A".

Regards,
John K.

[Jeroen Peereboom]

John (and others) are right.

Type the tr command without quotes again, and press ESC twice after typing [a-z] to have the shell expand the string, and do the same for [A-Z]. I assume vi-mode here. Now you can see what is actually being executed.

I wonder what tr will do if more than 1 filename fits. Tr will probably complain; to expand you must type ESC followed by '*'.

I've spent some time on this a few (more than 10) years ago. Always hide wildcards from the shell.

Another example (took half a day to solve):
Don't do: tar xvf /dev/rmt/... /etc/*
if you want to restore the files you removed from /etc. It will only restore files in /etc that are already present because of filename expansion by the shell...

JP