From: Bruce Stephens <hidden> Date: 2016-06-15 22:48:52
Dirk Süsserott [off-list ref] writes:
[...]
I had a similar problem when "make install"ing under AIX. Not with
NO_CURL but with some other NO_* option. I forgot which.
This yealded to an empty $(REMOTE_***_ALIASES) macro
(REMOTE_CURL_ALIASES in your case) which my AIX shell cannot handle.
It reads "for p in; do" which makes it unhappy. I solved my problem
with the SHELL_PATH environment variable (look at the first few lines
in the Makefile).
$ SHELL_PATH=/bin/bash NO_SOMETHING=YesPlease make install
then worked fine for me.
It wouldn't be too horrible to fix the Makefiles, though. Doing stuff
like this works portably (judging by what some OpenSSL Makefiles do):
foo="$(REMOTE_CURL_ALIASES)"; for i in $$foo; do \
[...]
I had a similar problem when "make install"ing under AIX. Not with
NO_CURL but with some other NO_* option. I forgot which.
This yealded to an empty $(REMOTE_***_ALIASES) macro
(REMOTE_CURL_ALIASES in your case) which my AIX shell cannot handle.
It reads "for p in; do" which makes it unhappy. I solved my problem
with the SHELL_PATH environment variable (look at the first few lines
in the Makefile).
$ SHELL_PATH=/bin/bash NO_SOMETHING=YesPlease make install
then worked fine for me.
It wouldn't be too horrible to fix the Makefiles, though. Doing stuff
like this works portably (judging by what some OpenSSL Makefiles do):
foo="$(REMOTE_CURL_ALIASES)"; for i in $$foo; do \
[...]
Bruce,
I just saw that Michael posted a patch which tests for the emptyness of
REMOTE_CURL_ALIASES. Probably that's a more convenient solution.
Dirk
From: Brandon Casey <redacted>
ksh does not like it when the list argument is missing in a for loop. This
can happen when NO_CURL is set which causes REMOTE_CURL_ALIASES to be unset.
In this case, the for loop in the Makefile expands to look like this:
for p in ; do
and ksh complains like this:
/bin/ksh: syntax error at line 15 : `;' unexpected
The existing attempt to work around this issue, introduced by 70b89f87,
tried to protect the for loop by first testing whether REMOTE_CURL_ALIASES
was empty, but it does not seem to work. So adopt Bruce Stephens's
suggestion (which comes from OpenSSL) for working around this issue.
Signed-off-by: Brandon Casey <redacted>
---
Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
From: Raja R Harinath <hidden> Date: 2016-06-15 22:49:04
Hi,
Brandon Casey [off-list ref] writes:
ksh does not like it when the list argument is missing in a for loop. This
can happen when NO_CURL is set which causes REMOTE_CURL_ALIASES to be unset.
In this case, the for loop in the Makefile expands to look like this:
for p in ; do
and ksh complains like this:
/bin/ksh: syntax error at line 15 : `;' unexpected
[snip]
- { test x"$(REMOTE_CURL_ALIASES)" = x || \
- for p in $(REMOTE_CURL_ALIASES); do \
+ remote_curl_aliases="$(REMOTE_CURL_ALIASES)" && \
+ for p in $$remote_curl_aliases; do \
I believe the idiom
test x'$(foo)' = x || for p in ''$(foo); do
works equally well in this case, and is less invasive.
- Hari
From: Michael J Gruber <hidden> Date: 2016-06-15 22:49:04
Brandon Casey venit, vidit, dixit 02.07.2010 20:50:
From: Brandon Casey <redacted>
ksh does not like it when the list argument is missing in a for loop. This
can happen when NO_CURL is set which causes REMOTE_CURL_ALIASES to be unset.
In this case, the for loop in the Makefile expands to look like this:
for p in ; do
and ksh complains like this:
/bin/ksh: syntax error at line 15 : `;' unexpected
The existing attempt to work around this issue, introduced by 70b89f87,
tried to protect the for loop by first testing whether REMOTE_CURL_ALIASES
was empty, but it does not seem to work. So adopt Bruce Stephens's
What does that mean? Either it works or it doesn't. I did work back
then. Does it (i.e.: the test for emtyness) fail to work for certain shells?
Michael
From: Johannes Sixt <hidden> Date: 2016-06-15 22:49:04
Am 7/4/2010 20:37, schrieb Michael J Gruber:
Brandon Casey venit, vidit, dixit 02.07.2010 20:50:
quoted
In this case, the for loop in the Makefile expands to look like this:
for p in ; do
and ksh complains like this:
/bin/ksh: syntax error at line 15 : `;' unexpected
The existing attempt to work around this issue, introduced by 70b89f87,
tried to protect the for loop by first testing whether REMOTE_CURL_ALIASES
was empty, but it does not seem to work. So adopt Bruce Stephens's
What does that mean? Either it works or it doesn't. I did work back
then. Does it (i.e.: the test for emtyness) fail to work for certain shells?
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.)
-- Hannes
From: Michael J Gruber <hidden> Date: 2016-06-15 22:49:04
Johannes Sixt venit, vidit, dixit 05.07.2010 08:19:
Am 7/4/2010 20:37, schrieb Michael J Gruber:
quoted
Brandon Casey venit, vidit, dixit 02.07.2010 20:50:
quoted
In this case, the for loop in the Makefile expands to look like this:
for p in ; do
and ksh complains like this:
/bin/ksh: syntax error at line 15 : `;' unexpected
The existing attempt to work around this issue, introduced by 70b89f87,
tried to protect the for loop by first testing whether REMOTE_CURL_ALIASES
was empty, but it does not seem to work. So adopt Bruce Stephens's
What does that mean? Either it works or it doesn't. I did work back
then. Does it (i.e.: the test for emtyness) fail to work for certain shells?
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.)
OK, thanks for clarifying. I suggest this to go into the commit message
so that the "does not seem to work" is qualified.
The OP back then (before 70b89f87) used ksh on AIX 6.1, but maybe he
left the thread without testing. I assume Hari's suggestion works on
ksh, as well?
If we go for Brandon's version: Is there a reason for small-casing the
var name? It looks as if we had two different variables with different
case (which we don't).
BTW: Is the $$var gmake specific? Has anyone tested the new version on,
say, AIX, not just on Linux with ksh?
Michael
From: Johannes Sixt <hidden> Date: 2016-06-15 22:49:04
Am 7/5/2010 10:14, schrieb Michael J Gruber:
BTW: Is the $$var gmake specific?
No. $ is a (special?) make variable that contains only a dollar sign. To
expand the variable in the Makefile, you have to write $$ (like for any
other Makefile variable whose name has only a single character, like $@,
$<, etc). As a result, you get a single dollar sign in the shell command
text. :-)
-- Hannes
From: Michael J Gruber <hidden> Date: 2016-06-15 22:49:04
Johannes Sixt venit, vidit, dixit 05.07.2010 11:15:
Am 7/5/2010 10:14, schrieb Michael J Gruber:
quoted
BTW: Is the $$var gmake specific?
No. $ is a (special?) make variable that contains only a dollar sign. To
expand the variable in the Makefile, you have to write $$ (like for any
other Makefile variable whose name has only a single character, like $@,
$<, etc). As a result, you get a single dollar sign in the shell command
text. :-)
@@ -0815,2 +0815,2 @@ endif-stupid remark about lower case-stupid question about escaping $+compensate for lack of morning coffee+note that an empty shell var is more than nothing at all