UNIX for Dummies Questions & Answers

ugh. what's the relation between LongDesciption_of_File and Totally_different_Char_string (is there a rule to produce latter one from the first one, or are they just constants)? Are MM, DD and YY fields guaranteed to be 2 characters each?

There is very little relationship between the new and old naming format. They are files reduced from hundreds of tests and it seems like every time they performed the same test they called it something different (no naming convention). There is no rule to produce the new name from the old. You just have try to interpret the old name and figure out what they are talking about and rename it accordingly to a standard convention. That way we can catalog all these data files and be able to actually find something when we need to do some research. Luckily someone has come up with a table(text file) of old file name to new ones for every single file that we have. That is why I would like to be able to read from the text file into a script to do all of the copying and renaming.

I will give it a shot on monady when I get back to work. I don't have a Unix machine at home to try anything.

Thanks,

Here is what I got to finally work (almost).

Code:

while read -r $oldname $newname; do
cp /path/$oldname /path/$newname
done < /path/to/textfile.txt

The only problem I have with the code is how it reads the text file. It sees the line feed at the end of each line of the text file and adds a character onto the end of the file extension that looks like a little square. So instead of whatever.mat I get whatever.mat"littlesquare". This symbol can only be seen if you look at the files using a windows machine. Everything looks normal when viewing the files in Solaris. However, I can edit the text file so there is a cariage return at the end of each line instead of a line feed. It is just a pain in the neck. If anyone knows a way to fix this without changing the text file I would appreciate it.

Thanks

Probably copied from a microsoft system incorrectly. Look in our faq section for "text files, ASCII files, binary files and ftp transfers"

This discussion will be seem clearer afer examining the final code offered--which is very short. But to gain some knowledge and understanding, which is always importnat...
The read command works by using the characters stored in the IFS variable -- "internal field separator", by default whitespace -- to separate out the tokens/fields on each line it reads, and then loads the variables specified at its arguments, one token per variable. But if any tokens remain, they are all added to the last variable specified. So when you say read oldname newname, 2 variables are specified. The first parsed token is loaded into oldname, and the remainder of the tokens into newname. I.e., the first filename is being loaded into the var oldname, but newname is getting extra stuff besides the 2nd filename (the carriage return, or anything else after the second filename). (MS uses '\r\n' --CR/LF--to end lines, Unix just '\n' (i.e., LF)). So then one might think the following would work, which has a "garbage collecting" third variable for read:

Code:

#!/bin/sh
while read -r oldname newname trash; do
cp /path/$oldname /path/$newname
done < /path/to/textfile.txt

The previous code works only if there is some whitespace after the destination (2nd) filename on each line of the file. If so, the '\r' and the filename will be separated by whitesapce, and since $IFS is whitespace, read will treat the '\r' as a separate, third token, and it will be loaded into our trash variable.
If there is no space after the 2nd filename, the second token will be "dest_file\r", in which case you first have to get rid of the carriage returns (if you don't, the 2nd argument to your cp command will be meesed up). The filter tr -d '\015' will remove a carriage return. (015 is the octal ASCII code for carriage return, and tr -d deletes the specified character).
Even so, you may still may want to use a third "garbage collecting" variable, in case you have any comments in the file, which would mess up your cp command. E.g.

Code:

old_checkbook.dat  new_checkbook.dat  ' my checkbook data

Just make sure there are no spaces in the filenames you have. Otherwise, hopefully you have used a non-whitespace to delimit the source filename form the target filename. (If so, script will need to be fancier.)
Also, if the filenames in the file are from an MS machine, and you want to put the files on a Unix box, make sure the directory delimiter is '/', not MS '\'. You can do that with the filter tr '\' '/'
So in the end, we end up with this, whi h is basically just a more robust version of Perderabo's code:

Code:

#!/bin/sh
tr -d '\015' < /path/to/textfile.txt | tr '\' '/' | while read -r oldname newname trash
do
   cp "/path/$oldname" "/path/$newname"
done

wouldn't something like this work?

Code:

list=$(awk '{printf $1" "}' listfile)
for oldname in $list; do
        newname=$(grep $oldname listfile|awk '{print $2}')
        mv $oldname $newname
done