Shell Programming and Scripting

Hey,

So I've run into a problem, due to my limited knowledge of Bash scripting.

Basically I've got a long script and I want to understand it before I even try and edit it. As long as I don't understand the script, I will not bother editing it.

Anyway, the following variable confuses me (I don't know what it does, exactly..):

Code:

DIR=$1/*

So my question is basically is someone could tell me (explain to me) what it means.

I know the variable DIR is being created and that the value of the first parameter is being used, but further than that I can't really place it.

I hope someone can help me out.

Thanks!!

If you are unsure about the content why don't you just display it?

Code:

DIR=$1/*
echo "$DIR"

This line appends a literal "/*" to whatever is given as the first positional argument. Suppose this is inside a script "foo.sh" and you call this script with "foo.sh bar" the variable DIR would contain "bar/*", if you call it with "foo.sh /path/to/somewhere" it would contain "/path/to/somewhere/*".

The statement is poorly phrased, btw., because it is asking for troubles: the asterisk ("*") has a special meaning to the shell and to protect such special characters from being interpreted one should cover them in quotes:

Code:

DIR="$1/*"

Furthermore, when using variable-names without spaces surrounding them it is a wise precaution to explicitly mark what belongs to the variable identifier and what doesn't:

Code:

DIR="${1}/*"

In your case this makes no difference, but consider:

Code:

a="blabla"
b="$ab"     # appending "b" will not work, because a variable named "ab" is expected
echo "$b"

b="${a}b"  # this will work
echo "$b"

I hope this helps.

bakunin

It is not necessary to quote an assignment unless it contains literal whitespace.

There's no point to using braces when the name is followed by a character that cannot be contained in a variable name.

Hey,

Thank you bakunin for your fast reply. I finally get it now .

Thanks!!

True. You can guarantee that "$1" will never contain a whitespace, then? Quoting variables out of habit, even in cases where it is not necessarily required, is just staying out of troubles, doing otherwise is asking for them.

Of course there is a point and i named it: precaution. That in this specific case it would not be necessary i did say explicitly said in the very next sentence, explaining on a counterexample what i meant.

We might disagree philosophically about what constitutes robust programming practices: i believe that many aspects of any often-employed activity (like, for instance, programming for a programmer) is driven by habits as much as conscient effort. My experience is that when i act habitually in a safe way i am generally better off then when i habitually employ a potential hazard - i will probably forget to take the necessary precaution in the one case where it will matter.

To come back from the general to the problem at hand, variable expansion: all i "risk" are two keystrokes and 2 bytes on a disk - compared to the avoided potential problems in cases like the one i cited this is not too much, i suppose.

bakunin

It doesn't matter whether $1 contains white space or not. That is not literal whitespace. $1 could be $' \t\n' or all spaces and it wouldn't matter.

Literal whitespace means an actual space on the command line, not contained in a variable.

(I should also include other characters special to the shell, such as a semi-colon.)

Doing it out of habit, instead of out of knowledge, is not good practice.

Doing it where it is never necessary is not good practice.

There is no potential problem in not quoting the assignment of one variable (or a concatenation of variables or strings not containing special characters) to a variable.

OK, I'll agree that quoting the assignment doesn't hurt, but it is not necessary, and certainly not more robust.