I'm trying to run single bash command to go out to a group of servers and check the free file space on a particular LVM partition. I'm running into a problem with the awk quotes. If anyone has some suggestions on how to fix or do it better, I'd appreciate hearing it.

I have a file with the hosts names and ip addresses comma separated. So, to run the task on each system I parse that file. Here is what I am trying to run: The double quotes for the printf are causing the problem. Any suggestions?

Thanks!

Try to escape them, as well as the $ signs:

1 members found this post helpful.

I had escaped the quotes around the format string, but not the positional parameters. Adding in those last two escapes did the trick! Thanks very much!

It helps readability to format your commands up on several lines, preferably with indented sub-commands and adequate whitespace.

The first error I spotted is: Don't Read Lines With For

Now perhaps it isn't really a big worry in this particular case, since you probably get a list of individual words, but it never hurts to do it properly.

You can also eliminate the use of cut with a properly-formulated read command.


The second thing I noticed was the Useless Use Of Grep. awk can do all the pattern matching itself.


Third, always try to separate the code from the data. In this case you want to send a command through ssh to another system, and that "code" is thus actually data. So store it in a variable first. That will make it easier to format, at the very least. (Note though that this is a special case. Usually you do not want to store commands in a variable.)

And one secret for handling reserved characters in such a situation is to use the $'..' "ansi-c" quoting pattern. You can backslash both single and double quotes inside them, making it easier to format the command as a whole.


Finally, it's a good idea to use meaningful variable names, but ones that don't match existing commands or keywords. And lose the '{}' brackets when you don't need them. They do nothing but clutter up the code.

But do quote them, always!

1 members found this post helpful.

I wouldn't call reading a file with for an error. When you know the structure of your file, there is nothing wrong with using it. I would rather call it a choice.

Good spot on using awk's matching to get rid of the grep.

I always use the '{}' brackets. I make it habbit. That way, when I do need them, I won't have forgotten.

I normally would indent, etc, but I was writing this command as a one time on the command line. So, I wanted to get it correct for that.

In a script that I save and re-use, I do use meaningful variable names. As this wasn't the case, I just use something short and f is my default.

Thanks for the suggestions!

DRLWF is an error because it's an unsafe, unreliable technique that depends on very exacting input and trusting to shell word-splitting before it will work properly. It is also inefficient. Since there are better techniques available that ARE reliable, efficient, and don't require exacting input, it is never proper to use it in my book. The fact that it can work in some limited situations is immaterial, it is still poor coding practice.

As for the rest, I will certainly agree that it's up to individual choice, but I think you'll find that experienced scripters tend to converge on similar styles because they're the ones that work best. I went through a phase myself too where I used ${} all the time, but I eventually gave it up when I realized that it was doing nothing but causing me more typing, making the code harder to read, and introducing yet another way for potential syntax errors to slip in. The slight benefit given isn't worth the effort.

I've also found that focusing on doing things properly all the time, even in quick & dirty situations, isn't really a burden once you get use to it. Laziness leads to sloppiness, which leads to errors. In the long run it costs you no more to do it right than to do it wrong.