On 10/15/26 06:57, Joseph Myers wrote:
On Wed, 14 Oct 2026, Jacob Bachmeyer wrote:
[...]
VAR:=VALUE looks to much like make's static assignment. VAR+=VALUE is
generally used for /append/. Maybe the better option would be to allow
"${VAR}" to appear in VALUE? Then prepending to PATH would simply be
"PATH=/where/ever:${PATH}".
The colon is only meant to be there if the variable was already set. In
shell terms it's PATH=/where/ever${PATH+:${PATH}} - but I don't suggest
actually supporting such shell notation for the overrides.
If the environment overrides are going to be passed through a shell (as
your initial patch did), what is the harm in using shell notation?
Also, PATH can generally be assumed to already be set, although you are
correct that other PATH-like variables might not be.
Maybe it would
be better to have something that explicitly names the kind of override
when it's not simply setting a value?
VAR=VALUE
VAR/undef
VAR/path-prepend=/where/ever
I am unsure if "/" might actually be obscure but valid in POSIX
environment variables.
It would have to use prefixes instead:
set/VAR=VALUE
unset/VAR
path-prepend/VAR=EXTRA-VALUE
path-append/VAR=EXTRA-VALUE
The "set" operation could be a default (available explicitly if VAR
could otherwise be confused) and "=VAR" could be an alias for "unset/VAR".
The only problems are how to handle PATH-like variables that use
something other than colon as their list item separator and how to
handle future needs for other manipulations?
[...]
"next test script" is liable to mean tens of thousands of tests were
skipped as a result of (typically) a syntax error in a dg.exp test
directive, which is functionally equivalent to the whole testsuite falling
over.
Should dg.exp also catch errors and attempt to resume, then?
That would probably be friendlier to users, yes, in the case of a mistake
in a test directive.
I will look into it.
-- Jacob
