piraha expands variables inside of strings

Create issue
Issue #2333 wontfix
Roland Haas created an issue

A setup like this:

$bar = "Foo"
Cactus::terminate = "$bar"

will complain

WARNING[L1,P0] (Cactus): Major error in parameter file 'par/tov.par' line 2: Range error setting parameter 'Cactus::terminate' to 'Foo'

instead of the expected “$bar”. Double quotes should protect $ signs so that is possible to pass strings containing $ to thorns (for whatever reason).

Comments (5)

  1. Roland Haas reporter

    It is not documented either way, the docs just say “Parameter values can also contain variables of the form ${VARIABLE} or $ENV{VARIABLE}.”.

    The arguments to expand or not expand would be based on what the previous parser did (it supported $parfile, ${parfile} and $ENV{'FOO'}, what common languages in Cactus (Perl, bash, C, Fortran) would do, and what does not restrict users unnecessarily.

    The previous parser (in ParseFile.c once one sets piraha_active to 0) handles things inconsistently:

    Cactus::terminate = "$parfile"
    

    passes the literal $parfile to the terminate option, while both

    Cactus::terminate = "${parfile}"
    

    and

    Cactus::terminate = $parfile
    

    pass the actual name of the parfile. $ENV{'FOO'} was always expanded even in strings.

    Perl and bash of course expand “$foo” in double quoted strings (but no in single quoted ones), while C and Fortran have no such functionality.

    Piraha’s and the previous parser’s handling of $ENV is unfortunately inconsistent in that the previous parser required the ENV variable name to be enclosed in single quotes in the curly braces while piraha does not allow this.

    Not expanding $ inside of strings lets people use $ in strings but requires the used of constructs like “BAR”+$FOO+”BAZ” to use variables in strings.

    Overall since ENV variables (in their previous incarnations or piraha’s) were always expanded even inside of strings it is likely best to keep the current behaviour, ie expanding variables, even at the cost of not being able to use $ in strings directly. $ can show up in strings by using “+” eg:

    $A=b
    Cactus::terminate = "$"+"A"
    Cactus::cctk_final_time = "$"
    

    tries to assign the literal string “$A” and “$” to the Cactus parameters.

  2. Roland Haas reporter

    Maybe. I am not sure I would necessarily want to go down that rabbit hole. We would then have to add code to also escape the backslash and end up having to do the same thing we did in #2312 . I would rather not end up with a pattern along the lines of [^\\](\\\\)*\${name} to match “$FOO not preceeded by an unescaped backslash”.
    My bug report was a bit over-zealous and since there were already cases in the past for which variables were expanded inside of double quoted strings, I think we may as well wait and see if anyone is actually hit by this.

  3. Roland Haas reporter

    Expanding variables inside of double quoted strings is allowed by the current docs and already happened in the past. A workaround to add "$" to strings is available.

  4. Log in to comment