On Wed Nov 22 03:01:09 2023 +0000, Alex Henrie wrote:
I think you may have misread the diff: The patch adds an exception for `WCMD_IF` to `WCMD_execute`, not `WCMD_expand_envvar`. `WCMD_expand_envvar` is exactly the same as before, minus the `static` keyword. The call to `WCMD_expand_envvar(p, '!')` is merely delayed until after the `IF` statement is parsed, exactly as you say it should be. It doesn't surprise me that `IF` has to be treated differently when `WCMD_execute` calls `handleExpansion` because there are many places where `IF` and `FOR` are already special-cased. There's a good chance that we will eventually have to add `&& cmd_index != WCMD_FOR` to the same two lines too.
if I get this right:
* 'if foo bar == other' generates a syntax error * 'if %VAR%==other' will get the same syntax error when VAR contains a space * 'if "%VAR%"=="other"' doesn't get syntax error as strings are delimited * but 'if !WINE_FOO!==other' doesn't get syntax error even if WINE_FOO contains a space
this looks to me as if:
* %VAR% is replaced by its value, and then the command is parsed * while !WINE_FOO! is kept as is, command is parsed, which gives !WINE_FOO! as a token, and which is then evaluated
IOW, this looks to me to be only a matter of ordering of operations, and has nothing to do with being inside a IF or not
but this requires to have a decent tokenizer (for which when delay expansion is enabled just transforms !VAR! into its value)