SHELL used sh: tr command not working in home directory and works fine in other directories

[sphatak]

The problem is "tr" command does not work in home directory, but it works if the directory is changed. The shell used is sh
Ex. Following command is not woring from home directory
echo TEST | tr [:upper:] [:lower:]
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

but in $HOME/abc its working fine without making any change.
Can you please advice and suggect some workaround?

[Anshumali]

This is behavior with this user only or the issue is with other users as well?
i see no issues, whats your system os version and patch level.

[Dennis Handly]

>The problem is "tr" command does not work in home directory

Do you have "." in your PATH and a tr in your home directory?
Try "whence tr" in both places.

[Steven E. Protter]

Shalom,

stty -a
env | more

Check the environment and settings. There is clearly an error in the user environment.

PATH most likely.

SEP

[Matti_Kurkela]

Maybe your shell is interpreting the arguments to tr as wildcards, and finding something that matches them in your home directory. The result of that expansion might be what is confusing the tr command.

If there is nothing in $HOME/abc, the shell finds nothing matching the "wildcards" and passes the arguments as-is.

Try adding single quotes around the tr strings:

echo TEST | tr '[:upper:]' '[:lower:]'

That prevents the shell wildcard expansion from touching the arguments of tr.

Another alternative would be that you have the directory "." listed in your PATH and you have a non-default "tr" command in your home directory.

MK

[sphatak]

Thank you all for your reply.
1) If it is an environment issue it should give problem in child directory. As I am not changing the environment.
2) There is no tr file in my home directory.
3) We can not put quotes since it requires changes in number of scripts.
Please let me know if it is a known issue and applying some patch would solve it?

[Ralph Grothe]

I know, as you want to avoid changing your scripts, this will be of little help.
But the HP posix shell offers a feature that even Bash lacks to my knowledge (probably zsh has it?)
There are these case specific options with the typeset command in sh-posix
that entirely make any tr or sed fumbling redundant.
A shell var declared to only hold lower case will always output lower case even if the assigment was upper case.
e.g.

$ typeset -l lcvar
$ lcvar=TEST
$ echo $lcvar
test

Maybe an alternative for your next script overhaul?

[Steven Schweda]

> Maybe your shell is interpreting the
> arguments to tr as wildcards, [...]

Sounds likely to me. Note that in "man tr",
these character classes are always quoted.
For example:

[...]
In a case conversion, however, the string2 array
contains only those characters defined as the
second characters in each of the toupper or
tolower character pairs, as appropriate. For
example:

tr -s '[:upper:]' '[:lower:]'
[...]

Perhaps they were quoted for a reason.


> 3) We can not put quotes since it requires
> changes in number of scripts.

Then I guess that you're out of luck. In
other words, "Making my badly written scripts
work correctly is too much work."?

[sphatak]

Then I guess that you're out of luck. In
other words, "Making my badly written scripts
work correctly is too much work."?
---- I dont think the scripts are badly written. The ascripts are in use since many years and working in our environment as well. I think this is something related to the environment on the HP server.

[OldSchool]

"1) If it is an environment issue it should give problem in child directory. As I am not changing the environment."

followed by

"I think this is something related to the environment on the HP server."

You were more than likely correct the first time. You said it doesn't work in the home dir but does in the child. Is this from a script or the command line?


"The ascripts are in use since many years and working in our environment as well."

Ok, so what's changed recently?

What is your PATH variable set to?

What is the contents of your HOME directory?

What does "whence tr" report?

Does "echo TEST | tr [E] [e]" work and give "TeST"?

BTW: I can reproduce the behavior you are seeing, but only in the C-shell. What's the script using????

[Peter Nikitka]

Hi,

to re-use your words: of course the script is badly written - you did not care for quoting and did not take filename expansion into account.
sh
$ mkdir new
$ cd new
$ ls [:upper:]
[:upper:]: No such file or directory
$ touch u
$ ls [:upper:]
u

On my SUN the message differs but has the same cause:
echo TEST | tr [:upper:] [:lower:]
tr: String2 contains an invalid character class.

The correct way would be to use
$ echo TEST | tr '[:upper:]'
'[:lower:]'
test

As a hack, you can disable filename expansion, if you do not need it elsewhere:
$ set -f
$ echo TEST | tr [:upper:] [:lower:]
test

mfG Peter

[James R. Ferguson]

Hi:

Peter N. nailed it. Follow his test (no pun intended) and you will see the behavior is the same on HP-UX.

As Steven S. said, there is good reason the manpages show examples with quotes.

I'm sorry to say that your scripts are simply badly written. They don't work 100% of the time, and that's just not good.

Regards!

...JRF...

[Dennis Handly]

>Peter: did not take filename expansion into account.

Rats, I was trying to test that so I created a file "[:upper:]". But that worked.

Only when I read Steven's did I get it:
tr [epru:] [elorw:]
Which is: echo tr [epru:] [elorw:]

[Keith Jahn]

This fault is often caused by a single character filename in the directory.

find /home/ -name \? -print

Quoting the command as advised above is best.

[sphatak]

From Keith Jahn
This fault is often caused by a single character filename in the directory.

find /home/ -name \? -print

Quoting the command as advised above is best.