WAD @FILEREADB outputs a leading space ...

[vefatica]

... except on **EOF**. That makes it hard to test its output.

v:\> set h=%@fileopen[rats.txt,r,b]

v:\> do i=0 to 7 ( echo ^^>%@filereadb[%h,1] )
> 82
> 97
> 116
> 115
> 33
> 13
> 10
>**EOF**

 

[rconn]

... except on **EOF**. That makes it hard to test its output.

v:\> set h=%@fileopen[rats.txt,r,b]

v:\> do i=0 to 7 ( echo ^^>%@filereadb[%h,1] )
> 82
> 97
> 116
> 115
> 33
> 13
> 10
>**EOF**

WAD. @FILEREADB is intended to return "a string of space-separated numeric digits representing the ASCII value of each character" (see the help). You get a space even with one character. (It has always behaved this way, and changing it now would break every batch file that uses @FILEREADB.)

So the more normal usage would be:

echo %@fileread[%h,7]
 82 97 116 115 33 13 10 **EOF**

 

[vefatica]

Right! And regardless of whether it's outputting one or many numbers, testing its output is cumbersome. You have to put leading spaces in literal test strings, or use %TRIM or @WORD.

The bottom line is that it's grandfathered in. And it's too bad we're stuck with it. But it's a good thing TCC doesn't do that with all space-separated lists (compare to @ASCII, _IP, et al.).