Double Colon or REM?

[ng2010]

I am new in MS DOS batch files. Can anyone tell me which is the best way to add multi line comment in a batch file.

:: or REM or if any other wayout.

Please suggest.

[Salmon Trout]

No multiline comments in dos. Start EACH comment line with REM. Do not use ::

[gpl]

You could fake a multiline comment, as the batch only parses the lines it encounters.
Try this

Code: [Select]

@echo off
goto skipheader
=======================================
my test batch
with multiline comments
=======================================

----------- carry on
:skipheader
echo Lets go

[ng2010]

Thanks all for the solution.

[Salmon Trout]

Remember that each label name must be unique.

[ng2010]

Hi Salmon,

Thanks for your suggestion, but I am reading one article http://www.chebucto.ns.ca/~ak621/DOS/Bat-Tips.html which says REM can cause problems under certain circumstances.

[BC_Programmer]

Thanks for your suggestion, but I am reading one article http://www.chebucto.ns.ca/~ak621/DOS/Bat-Tips.html which says REM can cause problems under certain circumstances.

The article writer is misinformed. First, redirection does not occur with REM statements, at all, from what I can tell.


Also, those "tips" are clearly for the pure DOS implementation of Batch.

[Salmon Trout]

Windows 7 and Windows XP and Windows 2000...

Code: [Select]

S:\>rem > remtest.txt

S:\>dir r*
 Volume in drive S is USB01
 Volume Serial Number is 2C51-AA7F

 Directory of S:\

File Not Found

Code: [Select]

S:\>rem | find "rem"

S:\>


[tikbalang]

"REM" is a batch command which gets executed even if there is no comment. "::" is a place marker with the name ":". unless there is a "GOTO" command that references it, it will be completely ignored.

use "::" for multiline comments. REM will slow down the batchfile.

[BC_Programmer]

"REM" is a batch command which gets executed even if there is no comment.

Salmon Trout just proved you wrong. If it was treated like any other batch command, the "remtest.txt" file should have existed. As he clearly shows the file does not exist, so redirection does NOT occur with REM.

"::" is a place marker with the name ":". unless there is a "GOTO" command that references it, it will be completely ignored.

And this is why you shouldn't use it. Try using it in a nested for or if statement and tell us how successful you are.

use "::" for multiline comments. REM will slow down the batchfile.

I'm sorry, there are two things you're misunderstanding here:

First, there is NO multiline comment for batch. a multiline comment is something like /* and */ used to delimit C++/C#, java, etc multiline comments, or { and } in Pascal, and various convolutions in other languages. everything is ignored from the starting character until it finds the ending character. There is no equivalent construct in batch.

Also try using your pretend comment ( :: ) within a batch file using NT command extensions and nested blocks.

Secondly, if REM can slow a batch file down enough to matter, then you should be using batch in the first place.

[Salmon Trout]

and it's the same in a script on all of those 3 operating systems.

Code: [Select]

@echo off
rem > rem.txt
rem | find "rem"
dir rem.txt
pause


Code: [Select]

S:\Test\Batch\After 03-07-2010\remtest>remtest2.bat
 Volume in drive S is USB01
 Volume Serial Number is 2C51-AA7F

 Directory of S:\Test\Batch\After 03-07-2010\remtest

File Not Found

[Salmon Trout]

However...

Code: [Select]

@echo off
rem %~


Code: [Select]

S:\Test\Batch\After 03-07-2010\remtest>remtest3.bat
The following usage of the path operator in batch-parameter
substitution is invalid: %~


For valid formats type CALL /? or FOR /?


[Salmon Trout]

And...

Code: [Select]

@echo off
rem /?



Code: [Select]

S:\Test\Batch\After 03-07-2010\remtest>remtest4.bat
Records comments (remarks) in a batch file or CONFIG.SYS.

REM [comment]
Given the definition of the "REM" command, one could reasonably expect it to accept ANY sequence of characters, regardless of whether that would constitute a syntax error in another context. But we all know the nature of variable substitution and how it happens before the command is fully parsed, and that this causes apparently buggy behaviour, at least when considered by newbies. I think this is a natural consequence of the way it has developed from the very simple workhorse tool of a very simple o/s to a still very simple tool of an incredibly complex o/s environment.