Thread (4 messages) flat view 4 messages, 3 authors, 2016-06-15

Re: [PATCH 2/2] Makefile: work around ksh's failure to handle missing list argument to for loop

From: Brandon Casey <hidden>
Date: 2016-06-15 22:49:05

Possibly related (same subject, not in this thread)

It looks like Johannes has already supplied the explanation that was
missing from my commit message.  Thanks.


On Mon, Jul 5, 2010 at 1:18 PM, Junio C Hamano [off-list ref] wrote:
Johannes Sixt [off-list ref] writes:
quoted
Before the test for emptyness can happen, the complete statement must be
parsed, but ksh finds a syntax error in the statement and, therefore,
cannot even begin to execute the statement. (ksh doesn't follow POSIX in
this regard, where this would not be a syntax error.)
I had to stare at Brandon's patch that was essentially:

-    for p in $(FOO); do echo $$p; done
+    foo=$(FOO); for p in $$foo; do echo $$p; done

and the above two doesn't look like there should be any difference; your
explanation makes quite a lot of sense but that's arcane.  I doubt I will
be able to justify and explain the latter construction without consulting
your message I am responsing to, if somebody asks "why do we assign $(FOO)
to a shell variable and then iterate over it?" 6 months from now.

It might make sense to use $(foreach) instead of rolling our own loop in
the shell to avoid glitches like this.
$(foreach) works too.  I only avoided it because it has already caused a
problem once before by creating a command line that exceeded the
maximum argument list length on IRIX.

REMOTE_CURL_ALIASES only has 3 items in it right now, and probably
won't grow much larger, if it grows at all, so there is little chance of
exceeding the maximum argument list length on IRIX.  So $(foreach) is
fine with me if you think that reads better.

-Brandon
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help