On Thu, 15 Oct 2026, Jacob Bachmeyer wrote:
> 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?
I don't think passing through a shell is optimal - ideally the settings
would be literal strings, while the other parts of the execution
interfaces would clearly define a point at which there is a translation
from "list of strings for program and arguments, as if passed to execvp"
to "command line string passed to a shell". It's simply consistent with
the current working of ssh_exec where the existing strings passed in get
passed to a shell without further quoting.
There may well also be cases where it's necessary to interpret override
settings within DejaGnu in order to compose them, if in future you do have
both scoped overrides and those passed directly to remote_exec /
remote_load - and in that case, interpretation of something described
logically as "prepend to PATH-like variable", in order to compose with
another prepending or a replacement of the value of the same variable, is
simpler than doing full interpretation of shell substitutions.
> 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".
Yes, that looks like reasonable notation.
> 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?
It might make sense to have an explicit way to query "do DejaGnu and the
board support a given environment operation?".
There could be extended versions
path-prepend[;]/VAR=EXTRA-VALUE
path-prepend[ ]/VAR=EXTRA-VALUE
to prepend with ';' and ' ' respectively as separator, though I'm less
sure that's needed in the initial version.
--
Joseph S. Myers
[email protected]
