Do ... /L and quoted strings

#1
Hello.

/me again

Is there a way to iterate through quoted strings using Do/EndDo?

For loop works, as expected:
For %x in ("a b" c) echo %x
Result is
"a b"
c

Results of Do loop are unexpected:
Do x in /L "a b" c
Echo %x
EndDo
Produces
"a
b"
c

Could you help?
Best regards.
(TCC LE 13.06.77 Windows 7)
 

rconn

Administrator
Staff member
May 14, 2008
10,495
94
#3
Hello.

/me again

Is there a way to iterate through quoted strings using Do/EndDo?

For loop works, as expected:
For %x in ("a b" c) echo %x
Result is
"a b"
c

Results of Do loop are unexpected:
Do x in /L "a b" c
Echo %x
EndDo
Produces
"a
b"
c
The FOR loop thinks you're echoing filenames, so the double quoted string is interpreted as a single argument. The DO loop thinks you're echoing strings -- and a double quote doesn't mean anything in a string.

If you want to use DO, you can iterate the arguments using @WORD.
 
#4
The FOR loop thinks you're echoing filenames, so the double quoted string is interpreted as a single argument. The DO loop thinks you're echoing strings -- and a double quote doesn't mean anything in a string.

If you want to use DO, you can iterate the arguments using @WORD.
It is not a bug, it is a feature :)
Thanks anyway.

Muchas gracias
 
#5
The FOR loop thinks you're echoing filenames, so the double quoted string is interpreted as a single argument. The DO loop thinks you're echoing strings -- and a double quote doesn't mean anything in a string.
This is inconsistent with the way command (and alias) parameters are counted -
Code:
[I]command [/I]"a b" cdef
command has two parameters - a quoted string ("a b") and an unquoted string (cdef).
 
#7
My note
I'm treating Do ... EndDo as a modern replacement of old-style For. The reasons: Do ... EndDo supports indentation, [most of] all For ... statements has it counterparts in Do/EndDo and last, but the most important: the block between Do and EndDo can be multi-lined.
Of course,I can use command grouping together with For, but it is ugly. Ugly and bad.
We have got great Iff/ElseIff/Else/EndIff block, we have got incredible switch statement (CaseAll - it is fantastic), Do/Leave/Iterate/EndDo block (it is a real block, not a statement). Why the results of Do /L are unexpected? As Steve Fabian told before: "Same issue in TCC ..." - yes, it is an issue.

From command line - I'm using FOR:
for %x in ( C: D: E: ) chkdsk %x /f
sometimes global:
global if isdir test rd /s test
but inside the batches - always Do/EndDo.

But for sure - it is a minor issue,
nothing compares to 4DOS/4NT/TCC (jpsoft fan since windows 3.1)

best wishes
 

rconn

Administrator
Staff member
May 14, 2008
10,495
94
#8
This is inconsistent with the way command (and alias) parameters are counted -
Code:
[I]command [/I]"a b" cdef
command has two parameters - a quoted string ("a b") and an unquoted string (cdef).

Those aren't strings, they're command arguments. And quoted command line arguments are treated as filenames. (Before LFN's, there wasn't any concept of double quoting having any meaning on the command line.)

You're trying to redefine 20-year-old syntax and meaning. There is absolutely zero chance of my changing the existing syntax -- particularly since there are several alternate ways of handling this.
 
#9
Nope. Don't redefine anything.
One of the key factors of success was COMPATIBILITY (compatibility with command.com, cmd and previous versions).
I was always sure, that every external bat can be executed from 4dos/4nt/tcc. I was always sure, that every old btm can be run again. There is no word "obsolete" in your docs and it is great.
We are suggesting to add in the future another just switch to get fully replacement of ugly For command.
Don't redefine anything.

Greetings from PL
 
#10
No, I am not asking to change the existing syntax. But I expected the command
Code:
[B]for %x in (a b ab "a b") echo %x[/B]
and the command
Code:
[B]do x in /L a b ab "a b" (echo %x[/B])
to have identical outputs, but they don't. The basic difference between actual behavior and expectation is how the OP and I viewed the "stringset" following /L, in other words, we forgot that due to its ancestry in and the necessity of compatiblity with COMMAND.COM and CMD.EXE, true strings exist in TCC in only very limited ways.

OTOH Charles Dye's suggestion of a form of DO which honors quoted strings as FOR does (and as command argument parsing does) would make programming considerably simpler.