1 |
Peter Volkov posted on Tue, 25 May 2010 11:46:12 +0400 as excerpted: |
2 |
|
3 |
> В Пнд, 24/05/2010 в 18:17 -0400, Mike Frysinger пишет: |
4 |
>> sources.gentoo.org/eclass/autotools.eclass?r1=1.97&r2=1.98 |
5 |
> |
6 |
> for makefile_name in {GNUmakefile,{M,m}akefile}.{am,in} "" ; do |
7 |
> |
8 |
> Why "" is required at the end of file list? |
9 |
|
10 |
Interesting coding trick! =:^) Here's that bit of code in full (watch the |
11 |
wrap): |
12 |
|
13 |
for makefile_name in {GNUmakefile,{M,m}akefile}.{am,in} "" ; do |
14 |
[[ -f ${makefile_name} ]] && break |
15 |
done |
16 |
[[ -z ${makefile_name} ]] && return 0 |
17 |
|
18 |
The for loop itself doesn't really do anything, except short-circuit |
19 |
itself with a break if the named file exists. What is its purpose, then? |
20 |
|
21 |
The purpose of the loop is to leave the name of the actual existing |
22 |
makefile in the variable makefile_name... |
23 |
|
24 |
**OR**, the purpose of the "" case, if none of the tested filename |
25 |
variants exists, it leaves the variable empty. |
26 |
|
27 |
The next line then tests for the last case, the empty variable, and short- |
28 |
circuits the eautomake function itself in that condition, returning 0/no- |
29 |
error/true. |
30 |
|
31 |
Without the "" case, the for loop would leave the last tested filename in |
32 |
the variable whether it existed or not, and the test for the empty |
33 |
variable wouldn't work. |
34 |
|
35 |
The perhaps more common alternative would be to test the exit status of |
36 |
the for loop, which returns the exist status of the last command, in this |
37 |
case either break (which would return zero/no-error/true), or the [[ -f ]] |
38 |
test itself (which would return 1/false/error if break didn't run). That |
39 |
would result in something like this (untested) code: |
40 |
|
41 |
for makefile_name in {GNUmakefile,{M,m}akefile}.{am,in} ; do |
42 |
[[ -f ${makefile_name} ]] && break |
43 |
done && return |
44 |
|
45 |
Assuming no error in my logic (a bit of an assumption since my code isn't |
46 |
tested and I expect his code was), I'm not sure why that code wasn't used, |
47 |
unless it was deemed less clear (perhaps the && return is too easy to |
48 |
miss, tho a separate [[ $? = 0 ]] && return would fix that), or was simple |
49 |
choice of coding style. |
50 |
|
51 |
While we're at it, in "&& return 0", the "0" is ALWAYS superfluous, as |
52 |
"return" returns the exit code of the last command by default, which MUST |
53 |
be zero or the "&&" logic would have failed, so the "&& return" |
54 |
combination will ALWAYS return 0. But that too may be coding style, as |
55 |
the "return 0" makes it explicit, a reasonable enough policy. |
56 |
|
57 |
-- |
58 |
Duncan - List replies preferred. No HTML msgs. |
59 |
"Every nonfree program has a lord, a master -- |
60 |
and if you use the program, he is your master." Richard Stallman |