You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has a problem. Namely: if we ignore the $, this is legal shell syntax, but the command will probably fail? Variables get set to legal strings that are useless values, i.e. [gcc-path value] does not mean anything in terms of paths. The linker will ignore these, but I imagine you meant to suggest actual commands or paths... in other words, substitutions. Like variables?
I am aware of the [option] convention in man pages, but that is for optional values, and these commands will simply fail if these are not set. It is also a hoary convention lost to the mists of time and not actually documented anywhere, so anyone unfamiliar with this particular notation will have no idea.
If you want to force them to define the variable (and thus, likely force them to break if they try to simply copy and paste the code), you can do this for these vars:
LIBRARY_PATH="${YOUR_GCC_PATH_VALUE:?define this to your path}"
This command will fail (setting $? to 1, it doesn't really "exit") with an error like:
bash: YOUR_GCC_PATH_VALUE: define this to your path
This is, despite being somewhat obscure syntax, portable shell. All POSIX shells are required to understand this, and non-POSIX shells I am aware of will at least parse-error on it, even if they don't replicate this behavior.
The text was updated successfully, but these errors were encountered:
workingjubilee
changed the title
Instructions should use shell syntax for variables
Instructions should use shell syntax
Apr 20, 2024
../gcc/configure \
--enable-host-shared \
--enable-languages=jit \
--enable-checking=release \ # it enables extra checks which allow to find bugs
--disable-bootstrap \
--disable-multilib \
--prefix=$(pwd)/../gcc-install
does not actually execute correctly if pasted into my terminal:
$ ../gcc/configure \ --enable-host-shared \ --enable-languages=jit \ --enable-checking=release \ # it enables extra checks which allow to find bugs --disable-bootstrap \ --disable-multilib \ --prefix=$(pwd)/../gcc-installconfigure: WARNING: you should use --build, --host, --targetconfigure: WARNING: invalid host type: #configure: WARNING: you should use --build, --host, --targetconfigure: WARNING: you should use --build, --host, --targetconfigure: WARNING: you should use --build, --host, --targetconfigure: WARNING: you should use --build, --host, --targetconfigure: WARNING: you should use --build, --host, --targetconfigure: WARNING: you should use --build, --host, --targetconfigure: WARNING: you should use --build, --host, --targetconfigure: WARNING: you should use --build, --host, --targetconfigure: WARNING: you should use --build, --host, --targetchecking build system type... Invalid configuration `#': machine `#-unknown' not recognizedconfigure: error: /bin/sh ../gcc/config.sub # failedbash: --disable-bootstrap: command not found
This is regarding this excerpt from the README, primarily:
This has a problem. Namely: if we ignore the
$
, this is legal shell syntax, but the command will probably fail? Variables get set to legal strings that are useless values, i.e.[gcc-path value]
does not mean anything in terms of paths. The linker will ignore these, but I imagine you meant to suggest actual commands or paths... in other words, substitutions. Like variables?I am aware of the
[option]
convention in man pages, but that is for optional values, and these commands will simply fail if these are not set. It is also a hoary convention lost to the mists of time and not actually documented anywhere, so anyone unfamiliar with this particular notation will have no idea.If you want to force them to define the variable (and thus, likely force them to break if they try to simply copy and paste the code), you can do this for these vars:
LIBRARY_PATH="${YOUR_GCC_PATH_VALUE:?define this to your path}"
This command will fail (setting
$?
to1
, it doesn't really "exit") with an error like:This is, despite being somewhat obscure syntax, portable shell. All POSIX shells are required to understand this, and non-POSIX shells I am aware of will at least parse-error on it, even if they don't replicate this behavior.
The text was updated successfully, but these errors were encountered: