tr problem

Les Mikesell lesmikesell at gmail.com
Fri Jun 13 04:24:25 UTC 2008


Gene Heskett wrote:
> 
>>>
>>> I'm trying to convert a test file, src code for a legacy computer, whose
>>> eol is a single cr into one with a newline subbed for each cr, and tr is
>>> being a pita, it broken, or there is PEBKAC.
>>>
>>> If I use this syntax:
>>>
>>> tr -c \r \n <filename  >filename2
>>>
>>> Then the whole file is converted to nnnnnnnnnn's, every byte.
>>>
>>> The manpage (and pinfo tr too) is, shall we say, completely lacking in how
>>> to handle the file I/O.
>>>
>>> So how do you use tr?"
>> Why option -c?
>>
>> tr '\r' '\n' <filename  >filename2
>> would do it.
> 
> Cuz the manpage says that it triggers the character convert thing?

No, tr actually takes 2 'sets' of characters even though in your use you 
only need one character in each set. For example
tr '[A-Z]' '[a-z]'
would lowercase a file (and the brackets and quotes aren't strictly 
necessary but would be on a sysV version).
The -c option means to complement the first set (i.e. it becomes the 
characters not included).

> It doesn't touch on its performance if the option isn't given.  And it doesn't 
> mention using the quotes either, but it worked just fine, thank you very much.

Man pages generally never mention the things the shell does to a command 
line before starting the program.  This will include expanding variables 
and wildcard filenames, redirecting I/O, and other things triggered by 
shell metacharacters.  In this case tr doesn't particularly need the 
quotes, but if you don't use them the shell will parse and remove the \ 
characters (treating them as quotes for the following character in its 
own parsing).  These details are the same for every command you type (or 
script) and not repeated in every man page.

-- 
   Les Mikesell
    lesmikesell at gmail.com





More information about the users mailing list