China DOS Union

### 1、Ordinary for statements ignore text starting with a semicolon:

Content of test.txt:

;abc

ai

::te

,te st

 test

Test code:

@echo off

for /f "delims=" %%i in (test.txt) do echo %%i

pause

This trap does not exist in the statements of type test.txt, more test.txt, and findstr .* test.txt without using for.

### 2、When using findstr /n .* test.txt with tokens=1* delims=: in the for statement, all colons at the beginning of the line will be filtered:

test.txt is the same as 1;

Test code:

@echo off

for /f "tokens=1* delims=:" %%i in ('findstr /n .* test.txt') do echo %%j

pause

General solutions to solve problem 1 and problem 2:

A little more complicated one:

@echo off

for /f "delims=" %%i in ('findstr /n .* test.txt') do (

    set "str=%%i"

    call set "str=%%str:*:=%%"

    call echo "%%str%%"

)

pause

The most concise one (After testing, this solution is not universal, because "delims= eol=" will filter out the content with quotes at the beginning of the line. It seems that it is really driving the tiger away from the front door and letting the wolf in from the back door. Quotes and semicolons cannot be taken into account):

@echo off

for /f "delims= eol=" %%i in (test.txt) do echo %%i

pause

In the concise solution, the order of "delims= eol=" cannot be reversed, otherwise deviations will occur.

I don't know what other traps the powerful for will have that will make us jump in without knowing, please everyone collect them so that we can take fewer detours when writing code in the future.

[ Last edited by namejm on 2007-5-17 at 09:17 PM ]

First of all, what I want to say is that the FOR statement ignores lines starting with "semicolons" by default, not colons.

Secondly, in the command "for /f "eol= delims=" %%a in (xxx) do command", no lines starting with any symbol are ignored, that is to say, all contents will be displayed........

Almost all tutorials say that delims should be placed at the end. I just found out today that there are also traps.

Another thing to note, it can't be called a trap, any program naturally can't take all aspects into account, this is where we need to pay more attention in our daily lives.

Originally posted by 9527 at 2007-1-24 16:42:
First of all, I want to say that the FOR statement by default ignores lines starting with a semicolon, not a colon.

　　Hehe, thanks for the reminder, the typo has been corrected.

Secondly, in the command "for /f "eol= delims=" %%a in (xxx) do command", no lines starting with any symbol will be ignored, that is, all contents will be displayed...

　　This solution will ignore lines starting with spaces. Brother, just test it and you'll know.

Originally posted by pengfei at 2007-1-24 16:51:
Another point worth noting, it can't be said to be a trap. Any program naturally can't take into account all aspects, and this is where we need to pay more attention in our daily lives.

　　These points worth noting are not mentioned anywhere in Microsoft's user manual. Whether it's a bug it deliberately ignores, a problem too small to mention, or it hasn't noticed, it's impossible to know. But from the user's perspective, there are bugs with no formal explanation, which are like hidden traps waiting for others to fall into ^_^

[ Last edited by namejm on 2007-1-24 at 05:59 PM ]

"delims= eol=" order cannot be reversed

It's not like that in for /?

Hehe, the /? in for also says: eol=c - refers to the end of a line comment character (just one). I'm really angry - heh, actually it filters out lines starting with c. I don't know which guy did the translation, his English is too bad.

Let's get back to the main point. What I said about the order not being reversible doesn't refer to all situations, but rather that in order to handle line contents starting with semicolons and colons simultaneously, this order can't be reversed.

Originally posted by namejm at 2007-1-25 08:31:
　　Haha, the /? for for also says: eol=c - refers to the end of a line comment character (just one). I'm really frustrated. - Hehe, actually it filters out lines starting with c. I don't know which guy did the translation, E...

Sweat, just realized there's such a big super error in for /?, really dizzy

for /f "eol= delims=" %%i in (test.txt) do echo %%i "eol= delims=" cannot be reversed, and no errors were found in local testing.

It seems that the comments in for /? are really a bit problematic.
eol=c - refers to the end of a line comment character (just one)
delims=xxx - refers to the delimiter set. This replaces the default delimiter set of spaces and tabs
default delimiter set.

There is ambiguity in our understanding of the above description. eol filters lines whose first character matches. Just like the default delimiter of delims is space or TAB. And the default first character of eol to filter is the ; character, but for /? does not explain.

Brother namejm's explanation gives the solution code, for /f "delims= eol=" %%i in (test.txt) do echo %%i Its function is the same as "delims=" to cancel the default space as a delimiter, and "eol=" to cancel the ; as a delimiter.

The following code is to filter lines whose first character is a colon, and cancel the default semicolon delimiter.

@echo off

for /f "delims=  eol=: " %%i in (test.txt) do echo %%i

pause

test.txt

abc

:123

4:56

;

;def

::

   dok:cto:::

The eol delimiter can only be one. The above code deliberately has two delimiters in elo, but only filters lines whose first character is :, and blank lines are not filtered.

It takes half an hour to read a post... It really is a classic post..............................

The following code filters lines starting with a colon and cancels the default space and tab delimiters.
CODE:
--------------------------------------------------------------------------------

@echo off
for /f "delims= eol=: " %%i in (test.txt) do echo %%i
pause

It should be
The following code filters lines starting with a colon and cancels the default space and tab delimiters.

It seems that I can only study basic things more. I didn't understand thoroughly.

...Hehe. Microsoft still has this bug... Oh my

There are more bugs in set /?...

Well! Many details are worth pondering