`make check` fails if builddir path contains `=`
The following is a portion of blk/Makefile.tests
responsible for compile tests:
( set -x ; env \
UPCXX_CODEMODE=$(UPCXX_CODEMODE) \
UPCXX_THREADMODE=$$threadmode \
UPCXX_NETWORK=$$network \
$$upcxx_cmd $(upcxx_src)/$$src \
In the case one's build directory has a name like build-cc=gnu
, the expansion of $$upcxx_cmd
to a fullpath will be misinterpreted as a variable assignment! The resulting failure mode is very non-intuitive failure to execute the source file! (sorry, I didn't preserve the actual text).
Comments (7)
-
reporter -
/usr/bin/env --help Usage: /usr/bin/env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...] Set each NAME to VALUE in the environment and run COMMAND. Mandatory arguments to long options are mandatory for short options too. -i, --ignore-environment start with an empty environment -0, --null end each output line with 0 byte rather than newline -u, --unset=NAME remove variable from the environment --help display this help and exit --version output version information and exit A mere - implies -i. If no COMMAND, print the resulting environment. GNU coreutils online help: <http://www.gnu.org/software/coreutils/> Report env translation bugs to <http://translationproject.org/team/> For complete documentation, run: info coreutils 'env invocation'
info coreutils
actually documents the opposite behavior for--
:In the rare case that a utility contains a '=' in the name, the only way to disambiguate it from a variable assignment is to use an intermediate command for COMMAND, and pass the problematic program name via ARGS. For example, if './prog=' is an executable in the current 'PATH':
env prog= true # runs 'true', with prog= in environment env ./prog= true # runs 'true', with ./prog= in environment env -- prog= true # runs 'true', with prog= in environment env sh -c '\prog= true' # runs 'prog=' with argument 'true' env sh -c 'exec "$@"' sh prog= true # also runs 'prog='
-
reporter @bonachea I don't understand what the "opposite behavior" means above. There is no mention at all of a double hyphen in the--help
output you've pasted. What is the opposite of undocumented?
EDIT: Never mind the text above. I eventually realized you meant opposite of my prior assertion that--
ended parsing name=value pairs rather than my initial interpretation as the opposite of the text you had quoted.The important thing you've added for me is that third example from coreutils which seems to state that double-hyphen is ignore without ending parsing for name=value pairs.
I'll plan to use
export
and notenv ... -- ...
-
reporter I've realized the entire env-v-export question is probably unnecessary.
My current thought is that the "right" fix is to discard use of environment variables in favor of the corresponding command line options toupcxx
. -
- changed milestone to 2022.9.0 release
Mass roll-over of open issues to next release milestone
-
- changed milestone to 2023.3.0 release
Mass roll-over of open issues to next release milestone
-
reporter - changed status to wontfix
This is not something we anticipate ever fixing.
- Log in to comment
Neither Linux nor macOS document
--
in their man page forenv
, thought both appear to support it as a means to terminate processing of name=value pairs.If use of
--
is not considered safe, then we can replaceenv
withexport
and add a semi-colon before the$$upcxx_cmd
. This will have exactly the same scope as the current logic, since the(
which begins the snippet in the issue description starts new scope (sub-shell) which ends right after the (elided above) arguments to$$upcxx_cmd
.