tr scripts giving wrong results

[Medavie]

I have a simple test script that uses the tr command. When we run the script, most times we get the correct result but we have determined that if we run the script with a touched file name of a single character in the directory we do not get the proper results. Can someone tell me why having a single character filename changes the results. If somone wants to see the results try the following in a script. NAME=bcwbird
UPPERNAME=`print $NAME | tr [a-z] [A-Z]`
print $NAME
print $UPPERNAME
exit

Then touch a file called p in the directory you are executing from ie be in your home directory and touch p then execute the above script.
No translation occurs. change the p to an a and you get different results. My shell is ksh, seems to perform the same in sh.

[harry d brown jr]

Shane,

I though you were full of it, but you are right, this is what I got:

# ./io
bcwbird
BCWBIRD
# touch p
# ./io
bcwbird
bcwbird
# touch a
# ./io
tr: The combination of options and String parameters is not legal.
Usage: tr [ -c | -cds | -cs | -ds | -s ] [-A] String1 String2
tr [ -cd | -cs | -d | -s ] [-A] String1
bcwbird

#

I'm gonna analize it, be back soon


live free or die
harry

[John Poff]

Hi,

I tried your script and it seems to work correctly. I'm a little confused. Are you passing the filename as a parameter to the script? I don't see how your script (as shown in your post) has anything to do with any file name.

Could it be that you have an alias in your shell for the letters 'a' or 'p' that could be throwing you off?

JP

[John Poff]

Ok. Now i see, from Harry's post. That's weird!

JP

[harry d brown jr · Accepted solution]

Shane,

You need to put the TRANSLATION strings in QUOTES:

# cat ./io
#!/sbin/sh
NAME=bcwbird
UPPERNAME=`print $NAME | tr "[a-z]" "[A-Z]"`
print $NAME
print $UPPERNAME
# ./io
bcwbird
BCWBIRD
# rm p a
# ./io
bcwbird
BCWBIRD
# touch p
# ./io
bcwbird
BCWBIRD
# touch a
# ./io
bcwbird
BCWBIRD
#

The issue is the `` executing and translating characters.

live free or die
harry

[James R. Ferguson]

Hi Shane:

Try;

# UPPERNAME=`print $NAME | tr '[a-z]' '[A-Z]'`

...or...

UPPERNAME=`print $NAME | tr '[:lower:]' '[:upper:]'`

Regards!

...JRF...

[John Poff]

Cool. Snagged by the quotes. That's why I don't fool with 'tr' when I'm switching case in scripts. I prefer to use 'typeset':

typeset -u UPPERNAME=$NAME

will work fine.

JP

[John Palmer]

You need to quote the arguments to the tr command.

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

Without the quotes, the shell matches [a-z] with the filename 'p' (or 'a') and so the first argument supplied to tr is the filename.

If you are simply converting a string to uppercase then a more efficient way is to declare an uppercase variable thus:-

typeset -u UPPERNAME

NAME=bcwbird
UPPERNAME=${NAME}
print ${UPPERNAME}

BCWBIRD

Regards,
John

[harry d brown jr]

Shane,

this is easier to show:

# rm a p
# echo a | tr [a-z] [A-Z]
A
# touch p
# echo a | tr [a-z] [A-Z]
a
# touch a
# echo a | tr [a-z] [A-Z]
tr: The combination of options and String parameters is not legal.
Usage: tr [ -c | -cds | -cs | -ds | -s ] [-A] String1 String2
tr [ -cd | -cs | -d | -s ] [-A] String1
# echo a | tr "[a-z]" "[A-Z]"
A
#


live free or die
harry

[Medavie]

The single character filename is not used in the script, it only causes the script not to give the correct results if the single character filename is in the directory you execute from. If you move the single character filename to a multiple character file name the script will work. (ie mv p pp) and then run the script and translation will occur. As long as there is a single character filename in the directory you execute from the results are incorrect.

[A. Clay Stephenson]

The trick is to put [a-z] in quotes. The shell is expanding your naked [a-z] and [A-Z] into filename matches so that in effect your
tr [a-z] [A-Z] becomes tr p ... when a matching file is found.

If you discipline yourself to use ${VAR} rather than $VAR and enclose almost all arguments in the appropriate quotes, you will see far fewer
unexpected behaviors in the shell.