©opy[it]®ight wrote:After hours of trial-and-error i've (once again) come to this place to hopefully get an explanation or solution for my FINDSTR batch troubles.
(...)
BUT i doubt i did it correctly and even don't know why it works, so hopefully one of you batch-guru's can assist/educate me.
The problem is, that 2 parsers are involved:
- the cmd parser, and
- the findstr parser.
The tokenizer is affected by the strings, to make these affects visible i use this notation (per character):
- open a string: /
- close a string: \
- within a string: +
- outside a string: -
Within a string all characters (except closing character) is handled as a normal character, so space, '>', have no special meaning.
You could say that after tokenization, each character belongs to one token.
We assume the tokens are numbered starting with 1.
So the following displays the strings and tokenization:
Code: Select all
Case1:
/+++++++++++++++++++\-----/+\----------------/+++\/+\----------/++++
"!SystemPath!FINDSTR" /IC:"\"selectedProfile\": \"" "!PROFILES!">NUL
11111111111111111111122222222222222222222222222222222222222222222222
Token 1: ["!SystemPath!FINDSTR"]
Token 2: [ /IC:"\"selectedProfile\": \"" "!PROFILES!">NUL]
Case2:
/+++++++++++++++++++\--------/++++++++++++++++\---/\-/++++++++++\----
"!SystemPath!FINDSTR" /IC:^"\"selectedProfile\": \"" "!PROFILES!">NUL
111111111111111111111222222222222222222222222223333344444444444445555
Token 1: ["!SystemPath!FINDSTR"]
Token 2: [ /IC:^"\"selectedProfile\"]
Token 3: [: \""]
Token 4: [ "!PROFILES!"]
Token 5: [>NUL]
The command and all its parameters are passed to findstr, but the redirection [>NUL] is not part of it, so the following command lines are passed to findstr
(as i don't know the content of your variables i still use them, but they are replaced when findstr is called;
in addition i use the same format to show string content and tokens as the findstr parser "sees" it;
note that the ^ is resolved):
Code: Select all
Case1:
/+++++++++++++++++++\-----/+++++++++++++++++++++++\-/+++++++++++++++
"!SystemPath!FINDSTR" /IC:"\"selectedProfile\": \"" "!PROFILES!">NUL
11111111111111111111122222222222222222222222222222233333333333333333
Token 1: ["!SystemPath!FINDSTR"]
Token 2: [ /IC:"\"selectedProfile\": \""]
Token 3: [ "!PROFILES!">NUL]
Case2:
/+++++++++++++++++++\-----/+++++++++++++++++++++++\-/++++++++++\
"!SystemPath!FINDSTR" /IC:"\"selectedProfile\": \"" "!PROFILES!"
1111111111111111111112222222222222222222222222222223333333333333
Token 1: ["!SystemPath!FINDSTR"]
Token 2: [ /IC:"\"selectedProfile\": \""]
Token 3: [ "!PROFILES!"]
So they are both valid findstr parameter strings: Token 3 is interpreted as filename (from both findstr instances).
In case 1 this filename does not exist (i assume), so the result is an error.
In addition, it does, what you wanted it to do (if i see it right
); search for the string (without []): ["selectedProfile": "].
A simple solution that should work is, to write the >NUL at the front of the command (line string), where it is recognized correctly:
[code]
>NUL "!SystemPath!FINDSTR" /IC:"\"selectedProfile\": \"" "!PROFILES!"
>NUL "!SystemPath!FINDSTR" /IC:^"\"selectedProfile\": \"" "!PROFILES!"
penpen