[SOLVED] @ForTEntireLine isn't preserving my line ?

[Ed Dyreen]

'
Why don't I get usebackq to work with @ForTEntireLine

Code: Select all

set @ForTEntireLine=for /f ^^^"usebackq eol^^=^^^%$LF%%$LF%^%$LF%%$LF%^^ delims^^=^^^" %%^! in

Code: Select all

set @ForTEntireLine=for /f ^^^"eol^^=^^^%$LF%%$LF%^%$LF%%$LF%^^ delims^^=^^^" %%^! in

Because the normal @ForTEntireLine isn't preserving my line

Code: Select all

%@ForTEntireLine% ( '$Debug, "This Works", "r?Enum=This Works"' ) do echo.$token=%%!_
or
%@ForTEntireLine% ( "$Debug, "This Works", "r?Enum=This Works"" ) do echo.$token=%%!_

Some symbols seems to cause problems, = and ( and )

[dbenham]

You need to escape the space between usebackq and eol. Go back and re-read the original post where jeb introduced how to set EOL = <LF>, and then read the responses to that post. I don't have the link handy, but it has been referenced many times.

untested:

Code: Select all

set @ForTEntireLine=for /f ^^^"usebackq^^ eol^^=^^^%$LF%%$LF%^%$LF%%$LF%^^ delims^^=^^^" %%^! in

Because the normal @ForTEntireLine isn't preserving my line

Can you be more specific. I have yet to see it fail when properly applied.

Dave Benham

[Ed Dyreen]

'
This seems to be problematic

Code: Select all

%@ForTEntireLine% (" ( '$Debug, "This Works", "r?Enum=This Works"' ) ") do echo.$token=%%!_

completely fails...

[dbenham]

The macro only takes care of setting EOL and DELIMS options so that the entire line is treated as one token and no lines are skipped because of the leading character. You still have to worry about making sure special characters and standard token delimiters are either escaped or quoted. Since you have quotes within your string, you have to keep track of what is quoted and what isn't.

Keep in mind - the standard parser compression of multiple unescaped, unquoted token delimiters into a single space is wholly separate from the FOR token processing. The parser token delimiters are space, semicolon, comma and equals (possibly the non-breaking space as well, I can't remember).

With normal (no usebackq), you need to escape the = because it is not within quotes:

Code: Select all

%@ForTEntireLine% (" ( '$Debug, "This Works", "r?Enum^=This Works"' ) ") do echo.$token=%%!_

With USEBACKQ the outer most double quotes need to be changed to single quotes and the commas and right parenthesis need to be escaped:

Code: Select all

@ForTEntireLine% (' ( '$Debug^, "This Works"^, "r?Enum=This Works"' ^) ') do echo.$token=%%!_

On XP the spaces that are not within quotes should probably be escaped as well. You well know why

If you have consecutive unquoted spaces then they MUST be escaped, regardless of Windows version, or else the parser will compress them down to one space.

Dave Benham

[Ed Dyreen]

'
Don't know why but this variation seems to work

Code: Select all

set @ForTEntireLine=for /f ^^^"usebackq^^ eol^^=^^^%$LF%%$LF%^%$LF%%$LF%^^ delims^^=^^^" %%^! in

So I can use it to preserve my line like

Code: Select all

%@ForTEntireLine% ( '$Debug, "r?Enum=This Works"' ) do echo.$token=%%!_
expected:
$token=$Debug, "r?Enum=This Works"☺☻♣E#File cannot be found

Using usebackq results in the XP for bug: ☺☻♣E#File cannot be found
But not using usebackq won't preserve special characters without escaping.
I really need to preserve special characters.
And if I do this

Code: Select all

2>nul ( %@ForTEntireLine% ( '$Debug, "r?Enum=This Works"' ) do echo.$token=%%!_ )

The bug is suppressed but then I loose error channel.

I really hate this bug, it's giving me a headache

[dbenham]

Code: Select all

set @ForTEntireLine=for /f ^^^"usebackq^^ eol^^=^^^%$LF%%$LF%^%$LF%%$LF%^^ delims^^=^^^" %%^! in

So I can use it to preserve my line like

Code: Select all

%@ForTEntireLine% ( '$Debug, "r?Enum=This Works"' ) do echo.$token=%%!_
expected:
$token=$Debug, "r?Enum=This Works"☺☻♣E#File cannot be found

Using usebackq results in the XP for bug: ☺☻♣E#File cannot be found
But not using usebackq won't preserve special characters without escaping.
I really need to preserve special characters.

I think you fooled yourself Ed. On my XP I get the XP bug AND the unquoted comma is stripped after $Debug.

In your macro application it doesn't matter because the comma is redundant with the space - you are only looking to delimit your macro parameters so you don't need both. But the unquoted/unescaped comma is causing the XP FOR bug. Actually the unquoted/unescaped space can also cause the XP bug under certain circumstances.

I don't think there is any mystery:
- To preserve special characters, (including standard token delimiters , ; = <space>) , they must either be quoted or escaped.
- To avoid FOR /F XP bug, you must never pass an unquoted/unescaped standard token delimiter. This is true even if you are NOT using USEBACKQ. A string like "This "example,"" can cause the XP bug because the , is not escaped or quoted. Go back and reread my posts about the bug.


Dave Benham

[Ed Dyreen]

'
You mean this link, I still don't understand why jeb is escaping a space but it's not that important
Sort tokens within a string & Disable FOR /F EOL option
viewtopic.php?f=3&t=1811&start=0

Code: Select all

for /F ^"usebackq^ skip^=1^ eol^=^

delims^=^" %%a in ('!str!') do (
  setlocal disableDelayedExpansion
  echo '%%a'
  endlocal
)

Damn ben, that just sucks ! So you are telling me I can't do this without getting the for bug Grrr !
( '$Debug, "r?Enum=This Works"' )
but I can do it like I did it in the old days
( '$Debug¦"r?Enum=This Works"' )
and if I set delim=, I will still get the bug

Maybe I can suppress the bug and still get what I want...

How about this

Code: Select all

set @ForTEntireLine=2^>nul ( for /f ^^^"usebackq^^ eol^^=^^^%$LF%%$LF%^%$LF%%$LF%^^ delims^^=^^^" %%^! in
set    @TEntireLine=do set "$token=%%^!" ) ^&for /f "tokens=*" %%^! in ( echo."^!$token^!" ) do

%@ForTEntireLine% ( '$Debug, "r?Enum=This Works"' ) %@TEntireLine% echo.$token=%%!_

I will test this later...


We both want to solve it don't we ?

[dbenham]

Assuming you work out the kinks in your code above - You are still not suppressing the XP bug. You are just hiding the evidence.

The gibberish output indicates that memory is at least being read inappropriately. Heaven help you if memory is also being written to inappropriately. Even if the bogus error message is redirected to nul, I still can envision unpredictable nasty consequences.

From one of your prior posts in another thread:

You should know that although the for ' bug is ugly, it does not cause my script to crash.
So I am ignoring it for now...

There is one more thing. when I run my script many times in VM, letting it define many variables.
After a while the script starts running slowly. Some sort of memory leak ?

Hmmm, Perhaps there is a correlation between your performance problem and the ignored bug I'm not saying there is or isn't. But it certainly is a possibility. I would never want to rely on code that exhibits the XP FOR bug.

We both want to solve it don't we ?

Yes, but I think you are chasing unicorns with your current direction.

I'm very close to success with these proposed ideas that you have seen before. I've still got a few kinks to work out, and there are a few inaccuracies in the post. But it should be enough to get you on track.

My development efforts are stalled due to other responsibilities. But I still hope to publish my results within the next 6 weeks.

Dave Benham

[Ed Dyreen]

'[SOLVED]

☺?♥♠a♀???☻?☻ for weirdness ♠☺??↨??$error = 7 niet vinden.
viewtopic.php?f=3&t=1972