Welcome!

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

SignUp Now!

WAD @FILEREADB outputs a leading space ...

May
12,846
164
... except on **EOF**. That makes it hard to test its output.
Code:
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**
 
... except on **EOF**. That makes it hard to test its output.
Code:
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:

Code:
echo %@fileread[%h,7]
 82 97 116 115 33 13 10 **EOF**
 
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.).
 
Back
Top