Shell Programming and Scripting

I'm the one who is sorry.. Sorry at coding That line was a big help!

Just my misunderstanding of what you said earlier.
I thought you meant that any time that a .* was used,
it would be safer to use a pipe. This Awk/Sed example by Trumpen was
the only thing I could find that did what I wanted.
After re-reading your post I now understand that it is meant
only for input.

I'm in the middle of adding the error checks mentioned earlier, After I
get it done, I will put it up here for other's to peruse and/or use as needed.

Thanks again all!!

You can do it as a single command with awk, too:

Code:

part1=$(awk -F= '/ARTIST/{gsub(" ","_");print $2}' tmp/tmp.txt)
part2=$(awk -F= '/TITLE/{gsub(" ","_");print $2}' tmp/tmp.txt)

This concept is a bit hard to grasp, because an asterisk is seemingly the same as an asterisk. No, that isn't the case.

There are regular expressions which are interpreted by regexp-using programs: sed, awk, grep, ed, vi, ... In this set of regular expressions a "." stands for "any character" and the asterisk stands for "0 or more of the last expression". ".*" means therefore "any number (including 0) of any character" and will therefore match any string whatsoever. Its the "real big joker", so to say.

But all these regexps deal with *string* manipulation. You feed a string to the program and this regexp will decide if the string matches or not. In this regard awk, sed and the others work basically the same way: if the string matches (of if it doesn't match) then a certain action is performed on this string, otherwise it isn't. (If i got you interested: Dale Dougherty wrote an excellent book, "sed & awk".)

Something entirely different are *shell* wildcards. They are some sort of regular expressions too, but their meaning is another. In this set of regexps the asterisk means "any number of any characters", similar to ".*" above.

The reason, why shell expansion poses a risk is the following: suppose a commandline like

Code:

ls -l *txt

In OSes like DOS the options ("-l", "*txt") would be passed to the program, in this case the executable "ls", and ls would have to figure out if a filename matches the schema and should be displayed or not. Not so in Unix: the shell (the program you type the command into) itself will expand the wildcard and replace what you have typed by what is matched by what you typed.

Suppose there are two files "a.txt" and "b.txt" in the directory and you issue the above command. First the shell will notice the wildcard, look into the directory and find 2 files which match it. Then it will replace your command with:

Code:

ls -l a.txt b.txt

and this is, what ls will finally see. If you had entered the command this way yourself ls would not be able to tell the difference.

Now, suppose you would enter the same command in a directory where several hundreds of files matching the wildcard reside. The commandline would become pretty long, yes? Unfortunately the commandline has a limit (4k characters) and ls has also a limit. More than a certain number of arguments will not be digested. "Too many arguments" or "Argument list too long" reads the error which will be displayed then.

I hope this clarifies it.

bakunin