SET command wish list

[DaveBenham]

Currently I am aware of 3 enhanced behaviors associated with patches to the native SET command.

The principal one is the ability of SET to define $heap variables. This makes all the sense in the world, and I would never want to lose that.

But another patch allows SET VAR = Trim one space on either side of equal. I am uncomfortable with that somewhat arbitrary definition. I understand that beginner batch coders are likely to try to define a variable with SET VAR = VALUE, and not understand why %VAR% does not work. But what about something like

set var1       =   1,000
set myVariable =      10
set Another    = 999,999

If one space is removed, wouldn't it be just as reasonable to expect that all whitespace before and after the = should be removed?

Also, I know that it is extremely unlikely that either the SET VAR = Value, or SET VAR+=AppendedValue patched behavior is likely to break any existing code. But the possibility is certainly there, and if we can get similar behavior in a manner that is guaranteed to be backward compatible, then I would prefer that.

Below is a wish list of potential changes to the SET patched behavior. They all assume you can patch the /Option parsing and behavior. That should be safe, because the native SET command does not allow a variable name to begin with / unless the entire assignment is quoted.

• Modify the return code behavior
  • Currently XP returns 1 and sets ERRORLEVEL to 1 when attempting to undefine a nonexistent variable. All other versions do not. Fix XP behavior to match others.
  • Return a unique non-zero value (1?) and set the ERRORLEVEL to match if a value cannot be set because the value is too long. Native behavior is to make no change to the variable, and to return 0 without modifying ERRORLEVEL.
  • I suppose existing success behavior should be preserved - .BAT scripts do not modify ERRORLEVEL upon successful set or clearance of a variable. .CMD scripts set ERRORLEVEL to 0 upon success. But we might want some switch to make .BAT behave like .CMD (low priority) See https://stackoverflow.com/q/34968009/1012053 for more info.
• /T - Trim all whitespace to the immediate left and right of the assignment = so that
  set /t var = value is the same as set var=value.
  This option would replace the set var = value syntax.
• /+ - Append the value to the end of the existing definition of the variable. This should also work with SET /P. This option would replace the set var+=appendedValue syntax.
• /E - Allow escape sequences in both the variable name and the value (also the SET /P prompt, but not any SET /P input)
• /Q - Interpret any "" within a quoted string as a single " literal. This would make it much simpler to build complex values with quotes and poison characters without having to figure out which portions the parser considers to be quoted, and which parts are not that would require ^ escapes.
• /C - Clear the value of the assigned variable before reading input. This is most commonly needed for SET /P. So instead of set "var="&set /p "var=Prompt: " you could simply do set /c /p "var=Prompt: ". But it would also be relavent when the assignment fails because the value is too long. Native behavior preserves the old value. This would effectively clear the definition if the value was too long.
• /L - If you get around to it, add a long integer math interpreter analagous to the native SET /A
• /F - If you get around to it, add a floating point math interpreter analagous to the native SET /A
• /P - Lots of potential modifications to the native behavior. This would require wholesale replacement of the existing SET /P code. If this is too complicated, then I guess we would need a CALLable @input extension:
  • Allow /A (and /L and /F if implemented) to be combined with /P. The user could enter a mathematical expression and the resultant value would be stored.
  • Honor and allow all content in the prompt, including leading = and whitespace. The native behavior inconsistently has problems.
  • Allow input of up to 8191 characters (perhaps more if assigning a $heap variable). Currently SET /P has a practical limit of 1021 characters.
  • Recognize any of LF, CRLF, and LFCR as end of line. Native SET /P only recognizes CRLF and LFCR.
  • Trailing input control characters should be preserved (except for end of line CRLF, LF, or LFCR). Native SET /P strips all trailing control characters.
  • If at end of file at start of SET /P, (or there is no available input on stdin) then return a unique non-zero value (2?) and set ERRORLEVEL to match. This will allow differentiation of empty line from end of file. This will be a major help for using SET /P to read a file, which is much faster than FOR /F. Note it is important that SET /P not change the file pointer and subsequent SET /P can later read text that has been appended.
  • Make SET /P to be reliable with pipes. Currently SET /P is a nightmare with pipes. This could be tricky when waiting for end of line. How long to wait before returning a partial line?

[adoxa]

If one space is removed, wouldn't it be just as reasonable to expect that all whitespace before and after the = should be removed?

It is reasonable, but that's not how CMD works. I cannot distinguish between spaces that should be preserved or stripped (without using additional options).

Also, I know that it is extremely unlikely that either the SET VAR = Value, or SET VAR+=AppendedValue patched behavior is likely to break any existing code.

That assigns AppendedValue to Var+, which is what existing code would expect. set VAR += AppendValue will do the append; I can't see anyone naming their variable with a trailing space-plus. Because I have the space there is why I added it to a normal assignment.

Currently XP returns 1 and sets ERRORLEVEL to 1 when attempting to undefine a nonexistent variable. All other versions do not. Fix XP behavior to match others.

That's a kernel issue (SetEnvironmentVariable itself is returning the error). Possibly I could work around it, but I'm not going to.

Return a unique non-zero value (1?) and set the ERRORLEVEL to match if a value cannot be set because the value is too long. Native behavior is to make no change to the variable, and to return 0 without modifying ERRORLEVEL.

How do you set a variable that is too long? CMD reads an 8Ki line, variables can be 32Ki. I created a 4Ki variable, echo failed to print it twice (i.e. echo !4Ki!!4Ki! output nothing); knocking off a character did work (echo !4Ki!!4Ki:~0,4095!). This looks to be a parsing issue, not specifically a SET issue.

[...] But we might want some switch to make .BAT behave like .CMD (low priority)

That's simple: ren *.bat *.cmd.

/T - Trim all whitespace to the immediate left and right of the assignment = so that set /t var = value is the same as set var=value. This option would replace the set var = value syntax.

/+ - Append the value to the end of the existing definition of the variable. This should also work with SET /P. This option would replace the set var+=appendedValue syntax.

I could do append and the spaces in the existing hook, so I didn't have to find any patches. This would be better, but I'm not sure if it's necessary.

/E - Allow escape sequences in both the variable name and the value (also the SET /P prompt, but not any SET /P input)

That sounds like another parser issue.

/Q - Interpret any "" within a quoted string as a single " literal. [...]

As does that. It's what string continuation is supposed to help with.

/C - Clear the value of the assigned variable before reading input. This is most commonly needed for SET /P. So instead of set "var="&set /p "var=Prompt: " you could simply do set /c /p "var=Prompt: ". But it would also be relavent when the assignment fails because the value is too long. Native behavior preserves the old value. This would effectively clear the definition if the value was too long.

Hm, that sounds like you actually want /P to assign an empty value. Although I think clearing it first would be easier to implement. If I do either.

/L - If you get around to it, add a long integer math interpreter analagous to the native SET /A

/F - If you get around to it, add a floating point math interpreter analagous to the native SET /A

It'd be /I (integer, but still 64-bit) and/or /C (calculator, using what's appropriate).

/P - Lots of potential modifications to the native behavior. This would require wholesale replacement of the existing SET /P code. If this is too complicated, then I guess we would need a CALLable @input extension:

Yes, "wholesale replacement" rather does imply a new function.

[adoxa]

Currently XP returns 1 and sets ERRORLEVEL to 1 when attempting to undefine a nonexistent variable. All other versions do not. Fix XP behavior to match others.

Don't know what I was thinking, this was trivial to fix.