By registering with us, you'll be able to discuss, share and exchange private messages with other members of our community.

SignUp Now!

Block Comments

The latest version of Take Command will include block comment functionality.

An easy way to add that to older versions is with two aliases:


I write big batches and connected files in weave, where you extract the code out of the comment. The barch has one short comment saying where it was produced from,
Unfortunately, that approach will fail if the block comments include an unpaired ENDIFF, or an unpaired IFF, or something that looks like one of those to the parser.
Weave means that you create the batch from a source file, and then untangle the batch from it. The simplest form is simply to turn the print processor on and off, rather like

set batch=batchname
echo REM made from %_batchname > %batch%
begin comment
  Comments go here
end comment
begin text > %batch
  Code goes here
end text
rem and so forth

I wrote a really advanced form of weave, which allows you to make several files up, and use native rexx variables and operations in the script. You can do things like produce rows of data from a table etc.

Here's how one might approach an IFF statement in 4NT. It's a fairly complex thing, and we really have to make sure it's all kept together. It's pretty easy to see how the payees are selected here.

!src and !lbl are labels, while !lbl and !end are implicit returns. !src and !end mark an active block of code, so the line at 'Here is... ' is not loaded into memory. !inc LBL runs the code from a label LBL to its implicit return. Nesting is limited by REXX's arrays (ie very large).

!src switchpayee
iff condition1 then
!inc condition1               ;  Payee male
elseiff condition2 then
!inc condition2              ; Payee female
elseiff condition3 then
!inc condition3             ; Payee company
!inc condition0           

Here is what happens at each case.

!src condition1
code for condition 1 goes here
!lbl condition2
  code for condition 2 goes here
!lbl condition3

The feature here is that the whole ENDIFF is given here clearly, with no further need of documentation. The includes can point to the same set of code, or of it's modular, you can include several !inc between the lines, or point several conditions to the same block (ie condition3 could have been 'condition1'.

Once this is written, the actual conditional codes are then documented separately.

None of this documentation appears in the actual code, and redundant code can be bypassed and still left in the source code (i put debug statements in like this).

Using ! to open commands comes from editing the JP software 4DOS.HLP file too much. Many of my text editors fold on !topic, which i use as a way to create a live index for the file, as well as keeping a tab on the current point.

I've used this sort of stuff to write blank floppy diskette images, which involve repeated writing of the same code.
Last edited:
Unfortunately, that approach will fail if the block comments include an unpaired ENDIFF, or an unpaired IFF, or something that looks like one of those to the parser.

I realize that. But even a built-in true COMMENT ... ENDCOMMENT would cause similar problems.

Previously, I would "comment" out code by actually adding IFF 1 EQ 0 THEN ... and ENDIFF to blocks. But the alias technique makes the code a lot more readable. Plus, I often put test code to do things like deliberately introduce an error, and in those cases it's not a block comment.
I actually do use IFF 1 EQ 0 THEN ... and ENDIFF, and I agree that your approach is more readable, but my approach makes it clearer that I cannot have unmatched IFF or ENDIFF or ELSEIFF lines. I'm thinking of using

Another approach is
  Comments can be entered here
Last edited:
Use a heredoc?
echo << ThisIsAComment > nul
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore magna
aliqua. Ut enim ad minim veniam, quis nostrud exercitation
ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit
esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
occaecat cupidatat non proident, sunt in culpa qui officia
deserunt mollit anim id est laborum.
Another approach is
  Comments can be entered here

dcantor's solution works, but not in an alias. The TEXT statement makes the parser scan for ENDTEXT which fails if "hidden" in an alias.

John's solution needs unique delimiters for each block, which makes the use of aliases problematic too.

I wonder if there is a (albeit small) performance hit when using solutions based on redirecting to the nul device. Does any transfer actually take place, internally? I have no idea. If so, I would expect the IFF/ENDIFF solution the be faster.