First off: thanks for sharing. And because you did that (instead of just saying you have a solution) you get something back immediately in return: some explanation why your script probably hasn't worked. So this will be at least helpful to you (but perhaps some others, because what you did is a common error). Here it goes:
When you write scripts, as a rule of thumb, NEVER use relative paths or filenames. See, you can call a script from everywhere and its workings should always be the same, regardless of from where you called it. The line
for RPTFIL in `ls`
will work if you call the script in one directory, but fail if you call it in another. Save for that, you should avoid the backticks (they are obsolete) but you do not need them anyway: for file in *edi ; do
will work the same and you do not need to call ls
for that. You see, "*" means already "all files" and is interpreted b the shell, not the program called. A command like:
ls *file
is processed this way: first, the shell sees the asterisk and "expands" it to a list of files matching, in this case: all files with names ending in "file" in the current directory. Then the result of this "expansion" is put on the (intermediate) command line:
ls *file # your command
ls a.file b.file c.file # after expansion (you won't see that)
Finally the command itself (here ls
) is called and given the list of files, which it displays. If you call ls
without any parameters it doesn't do much at all, only when you use additional options it gets more and more useful. But try, to test what i have said, on the commandline:
echo *
and you will see that it produces the same list as ls
without options. And with the explanation above you know why.
Anyway, preferable is to provide what the script needs to know on the commandline, like:
myscript.sh /path/to/my/data
UNIX has a quite fixed directory hierarchy and there is a certain place for all sorts of things. You put i.e. temporary files always in /tmp
and, on the other hand, whatever is in /tmp
can be deleted without question. So your script can assume some paths to be given.
Second: as a rule of thumb, always quote your variables! The shell treats space as separators, so a line like:
a b c
will call a program "a" with the first parameter "b" and the second parameter "c". It is possible to name a program "a b" or pass parameters with enclosed spaces you need to quote:
"a b" "c d" # will start a program "a b" with a single parameter "c d"
Now let us see your script itself:
The first thing is: when you start programming, keep a strict order. It will help you to organize your code. We always start with a shebang line, telling the OS which shell to use (instead of relying on an arbitrary default that could change), then declare the variables we use. This gives us the opprtunity to write in commentary what should go into these variables. Note that everything after "#" is a commentary.
#! /bin/ksh
# maybe you want to use "#! /bin/bash" instead, this line is called "shebang"
dir="$1" # working directory
tmpdir="/tmp/mydir" # temporary workspace
file="" # filename buffer
if [ -e "$tmpdir" ] ; then
mkdir -p "$tmpdir"
fi
mv ${dir}/*edi "$tmpdir"
for file in "$tmpdir/*" ; do
mv "file" "/some/place/FLXRPT.DAT"
process_file
if [ $? -ne 0 ] ; then # you might want some error reporting here
echo "ERROR processing $file" >2&
fi
....
done
rmdir "$tmpdir"
exit 0
This will first copy all files "*edi" from some directory to "/tmp/mydir", then copy one file after other to the name "/some/place/FLXRPT.DAT" and process it. if the (hypothetical) command "process_file" exits with any other value than 0 (conventionally this means success) an error message is produced and the script continues (it might also stop if you put an "exit" command after the echo). Once the list is finished the temporary directory is deleted and the script exits with 0 itself.
Now, i suppose this is not exactly what you wanted to do and you could (and should) modify it to better suit your needs. It is not so much about how to write a certain script but to show the princinples of how to write any script. Always bear in mind that scriptingis like any other form of software engineering and the same principles apply. In fact it is even more demanding (mostly on self-control) because you can get away initially with a lot of slack where other programming languages are more demanding from the start. You should mostly not rely on these shortcuts, because the longer your scripts get (and, believe me, once you get the hang of it you are NEVER going to stop) the more you need to drop these bad habits and do it the correct way. So better start developing good habits from the start.
In either case, if you have troubles extending your script we will be here to help you.
I hope this helps.
bakunin