#31 17 May 2018 23:58

green
Member
From: Великие Луки
Registered: 13 May 2018
Posts: 18

Re: error in CMD SET

You are wrong about difference of SET versions. There are no different versions of SET in this case. SET returns exactly same result, regardless of using context: command line, or script. Your mistake comes from misconception, that SET operators evaluation (A) connected (associated) with in-script percent char evaluation (B). Indeed, you are do wrong, and these evaluations always happen separately. Firstly, the B evaluation takes place, and the A evaluation takes place after. In-script evaluation (B) evaluate only three things: script numbered parameters, SET variables, and literal percent char. If interpreter meets percent char in a script, it inspects, what char goes immediately next.

  • If it's percent char, then we have %% and it's converted to literal percent char.

  • If it's decimal digit char, then we have %n and it's converted to script numbered parameter #n.

  • If it's asterisk char, then we have %* and it's converted to script parameters line, but zero-numbered parameter with trailing white-space chars subtracted, and white-space chars in the end of the parameters line subtracted.

  • If it's char, other than percent char, or decimal digit char, or asterisk char, then interpreter seeks next nearest percent char, and text between first and second percent char is treated as SET variable name, so we have, for example, %variable%, and it's converted to variable contents (if variable not exist, then the interpreter treats it as empty variable, so it's contents is empty string).

After the script line is inspected by interpreter from left to right, and evaluation B is ended, it's no way to return to B evaluation. And after it, some another types of evaluations take place, and then the turn comes to evaluation A, which corresponds to the SET syntax. Same rules apply to any other command too, for example, FOR. Evaluation B in such form takes place only in a script, and never performed in direct command line. In direct command line, we have different form of B evaluation, which consists from only one rule.

  • If interpreter meets percent char in a direct command line, it inspects, what char goes immediately next. If it's percent char, then first percent char is leaved as it is, and evaluation continues from second percent char, but if it's char, other than percent char, then interpreter seeks next nearest percent char, and if it's not found, the percent char leaves, as it is, but if it's found, then text between first and second percent char is treated as SET variable name, so we have, for example, %variable%. If variable with such name exists, then the text %variable% is converted to variable contents, otherwise the text %variable% is leaved as it is (not converted to empty string). Note, that in this case, variable name can begin with decimal digit or asterisk, what impossible in a script.

  1. 17%%5 in a script gives 2, because double percent is evaluated to one literal percent char, so we have 17%5, which results to 2.

  2. 17%5 in a script gives 17, because %5 is evaluated to fifth script numbered parameter, and because of fifth parameter's emptiness, %5 is evaluated to empty string

  3. 17%20 in a script gives 170, because %2 is evaluated to second script numbered parameter, and because of second parameter's emptiness, %2 is evaluated to empty string

Overall, you can understand now, that the error was in your conception, but not in the interpreter, not in the least. The interpreter works exactly as declared, there are no any errors, and no interpreter bugs in any of these cases.

Last edited by green (18 May 2018 12:32)

Offline

#32 18 May 2018 12:12

Simon Sheppard
Super Administrator
Registered: 27 Aug 2005
Posts: 976
Website

Re: error in CMD SET

Yes I understand whats happening when % is used in a script.

When I describe this as being buggy I don't mean there are errors in the code, if you use it exactly as intended it gives the right results, but that if you make a simple error like using one % instead of two you would expect (in 2018) that this would result in some error message or returning 0 or NAN, but not just give you seemingly random numbers returned.
This is because of CMD's early roots in MSDOS of the 1980s but I'm concious that not everyone will be aware of that history and will have perhaps reasonable (or unreasonable) expectations about how well it should handle user errors.

You can argue about what the definition of a bug is, I think most people will consider it a bit wider than just 'does it perform to spec' but also does it handle predictable user errors gracefully.

I think we are pretty much on the same page about how this behaves, I'm going to make a couple more small changes today, but then I'm going to be out of town for a few days.

Thanks again for all the feedback - it is useful.

Offline

#33 18 May 2018 12:25

Simon Sheppard
Super Administrator
Registered: 27 Aug 2005
Posts: 976
Website

Re: error in CMD SET

And now of course I find Dave Benham's more detailed description of the process:
https://stackoverflow.com/questions/409 … 12#7970912

Offline

#34 18 May 2018 12:37

green
Member
From: Великие Луки
Registered: 13 May 2018
Posts: 18

Re: error in CMD SET

There are no random numbers returned, and there are no situation (in your examples), where 0 or NAN should be returned, and there are no errors. Where did you get random number? Or where NAN should be returned?

Offline

#35 18 May 2018 13:53

Simon Sheppard
Super Administrator
Registered: 27 Aug 2005
Posts: 976
Website

Re: error in CMD SET

17%20
gives 170

For someone who doesnt understand WHY it's returning that number they are going to see it as a random/incorrect result, most modern languages, even spreadsheets will give an error message when given invalid syntax.

It is arguable that you might want to include a parameter value directly into the SET/A command, but most people will follow the standard practice of reading all parameters into variables and then use the variables within the code, it makes the script easier to read and more maintainable. PowerShell actually enforces this through the param() statement.

So for anyone with those expectations i.e. they have used other languages and perhaps only use CMD scripts on the odd occasion, this will seem like buggy behaviour.

I think of this as usability in software design, it's not enough to just make something that works, it should work the way users expect it. I am probably rather extreme in this opinion but to me a failure in usability is a bug just as bad as some software returning 2+2=5.

I think the importance of usability in IT is vastly underestimated by many people. I have worked with IT systems where literally 75% of end users are getting the wrong answer and the supplier still can't see any problem because "the software is working correctly."

Offline

#36 18 May 2018 15:48

green
Member
From: Великие Луки
Registered: 13 May 2018
Posts: 18

Re: error in CMD SET

First of all, the syntax in every of the examples is valid. And if the syntax isn't valid, then an error message is directed by interpreter to StdErr, of course.
I agree with you about the usability issue in that aspect, that it's a major problem. But rather, than shifting the blame to programmers, which create interpreters, compilers, or languages in general, I think, if we work with good language (the Windows command script language is good enough), the blame lies on the users themselves, because they not learned the language enough. The CMD documentation fully covers all the given examples (in this forum topic), doesn't contradict them, and sufficiently detailed for adequate coverage of associated issues. If you can demonstrate difference between documentation and interpreter behaviour, then write about it here. I guess, you will not have found any discrepancies between documentation and the examples.

Offline

#37 18 May 2018 16:03

Pyprohly
Member
Registered: 26 Nov 2014
Posts: 37

Re: error in CMD SET

green wrote:

One's complement may mislead unexperienced users

My proposal to revoke the change that was committed is an attempt on correctness. The suggestion that “one's complement may mislead unexperienced users” is just not relevant to the intention of my proposal, even if it was a reasonable claim.

green wrote:

But remark about number machine representation and calculation should be added, and that remark will be, certainly, about Two's complement.

It’s not SS64 place to discuss two complement in detail. There are other places on the web better equiped to talk about the nitty gritty details of computing internals.

green wrote:

I know English not good. May be, the sentence I wrote, be better, if like below? Or that sentence will have same meaning?

Changing the order of clauses doesn’t change it’s meaning. I was questioning your choice on the word “proof”.

In general, experiencing something doesn’t provide sufficient evidence for a proof, because there may be edge cases you haven’t been exposed to, and proofs are supposed to always guarantee correctness.

edit: Redacted uncalled-for comment on language


@Sheppard,
While you’re out of town, don’t forget to consider the issues I’ve mentioned in my first post to this thread:

* change “Two's complement minus 1” to “one’s complement”—one’s complement is two’s complement plus one. Also consider my suggested description for it: “Bitwise negation (one's complement)”, similar to what it was previously.
* change “Subtract (or unary)” to “Subtract (or negation)”—“unary” could refer to any operator that takes one operand. For a list of operators that can be considered unary (at least in C++), see: https://msdn.microsoft.com/en-us/library/hetcw0tx.aspx

Btw, on the percent symbol discussion, “bug” may be a misnomer. In the context of programming if something doesn’t align with expectations but has a straightforward workaround then consider it a “gotcha”.

Last edited by Pyprohly (19 May 2018 01:37)

Offline

Board footer

Powered by FluxBB