Master 512
Forum by Robin Burton
Beebug Vol. 10 No. 6 November 1991
Before we leave batch files, the topic which has occupied the Forum for the past three issues, I have one more tip to pass on.
David Harper, who you'll remember sent a letter about the '/C' switch for COMMAND.COM, also mentioned this item at the same time, but it's had to wait until now for a suitable point to squeeze it in.
HIDING OUTPUT
In Vol.10 No.2 I mentioned that one or two of you had asked how to suppress the screen output from batch files, and I offered some ideas.
David pointed out something else which I should have remembered but didn't, so thanks again to him. My excuse is that these days I don't get much chance to explore or even to use the system unless there's a specific reason.
I've mentioned redirecting output in the Forum a couple of times, but in its usual context, which is to transfer data to real files and devices. In fact, there's also a 'pseudo' device in DOS Plus called 'NUL:' (note that the single 'L' in the spelling is not a mistake.)
You can use 'NUL:' just as you'd use a real file or device name in batch files or in manual commands to re-direct screen or other output to it. This is what I described in Vol.10 No.2. 'NUL:' acts as a printer 'sink', swallowing all output which would otherwise be sent to the printer. For example, using 'NUL:' to suppress screen output from a copy command the syntax is:
COPY FILE1 FILE2 >NUL:
The copy works OK, but there's no display. Disadvantages of using 'NUL:' are non-existent. You should remember though, if you're short of disc space and don't want to split your batch file into two jobs as was explained previously, there's more typing. 'NUL:' does offer savings both in file space and execution time, but you'll have to supply the '>NUL:' suffix for every command for which the output is to be suppressed. However, creating batch files is a simple job and it's usually a 'one-off' exercise so this is a small hardship.
The advantages, however, far outweigh this single possible negative. Using a 'real' temporary file, as I explained before, both slows down the job and, if you're being tidy, the temporary file needs deleting afterwards each time too. Using two batch files but employing 'NUL:' in place of a temporary file is a much better idea. The end result is similar to the temporary file, but without the disadvantages.
However, don't get the idea that this facility is the perfect answer for all such problems. As usual there's a caveat.
As I mentioned in Vol.10 No.2, though I didn't explain it fully there, when you redirect screen output you need to be careful which commands are affected. If the resulting output from a command is something which is intended to change the screen display (basically all commands which are executed in the 512 by means of BBC micro 'VDU' operations), re-directing will cancel the effects of the command. This is still true when you re-direct to 'NUL:' instead of to a file, and it's easy to demonstrate.
Re-direction can be used manually as well as in batch files, so let's take a simple example such as 'CLS' and try it manually. In the 512 (but not in PCs) the similarity of DOS's 'CLS' command to the BBC Basic command is more than just skin deep. Both issue the equivalent of 'VDU12'. First try 'CLS' and the screen clears normally, just to prove I've nothing up my sleeve. If you now type:
CLS >NUL:
absolutely nothing happens. Well, that's not quite true, but it might as well be. What does happen is that the BDOS passes the output from the 'CLS' command to the XIOS as usual. Next though, instead of the output being directed to the default device 'CON:' within the XIOS (and from there being translated to a VDU12 through the Tube to the BBC micro), it is directed to device 'NUL:', which means it's never physically output anywhere. Try these two example batch files, called TEST.BAT and TEST1.BAT, to see better what happens.
ECHO OFF
ECHO THIS IS BATCH FILE 1
REM Call the second file
TEST1 >NUL:
ECHO THIS IS BATCH FILE 2
REM Now try some other commands
BACKG
CLS
PCSCREEN 7
DIR
COPY TEST.BAT TEMP.FIL
You can see what the commands would do 'normally' in the second file, but if you try running the job you'll find that, in effect, all the commands in the second file are pointless with the sole exception of COPY, the only command which is not directly concerned with console output. After the job ends you'll find there is indeed now a TEMP.FIL, which clearly proves that the second file really did execute. This in turn proves that not only the visible screen output, but that all the screen changes have been cancelled by the re-direction to 'NUL:'
The final point is that using 'NUL:' doesn't get round the other problem mentioned last time either. You're still stuck with at least the first command on the screen. In this case the 'ECHO OFF' in TEST.BAT will be displayed (and 'no', you can't have 'ECHO OFF >NUL:', it doesn't work!).
There are some dodges which can minimise this problem: David mentioned one which I might include in a future issue, but in fairness it's a bit fiddly. In practical terms it's almost as effective and much easier if you follow the 'ECHO OFF' by 'CLS' on the next line and hope no-one was watching the screen too closely!
CURIOSITIES
As I mentioned before, I rarely get time just to 'poke around' in the system these days, I'm usually programming or writing. This is a pity, because it can be quite entertaining and it's surprising what you can find.
For example in some jobs, such as writing and checking batch file examples for the Forum, I'm switching between the BBC micro and the 512 repeatedly. As a result, in these circumstances I occasionally type something like '*.' when what I really mean is 'DIR'. It's not surprising that it doesn't work, but I wonder how many of you have done this sort of thing and found that it doesn't cause an error either. At the DOS prompt type:
*This is rubbish
and see what happens. Nothing! There's no 'Bad command or filename' and in fact there's no action of any sort. It also works in batch files in exactly the same way, the line behaves as if it's not there, apart from the display if echo is on. If you experiment a bit you'll find that '.' , '}', ',' and numerous other characters can be used instead of '*' with the same result.
I've known about these oddities for a long time, but I've never found any practical use for them, except that they can be used as REMs in batch files and save the typing of two more characters. Have any of you any ideas?
You may remember that I wrote about piping a while ago, in Vol.9 No.7 to be precise. This is the method by which the output from one process can be fed directly to another as its input, and it uses the vertical bar symbol, '|'.
I discovered a curiosity (a bug?) associated with this a while ago, and you can try this one yourself too. Make sure you have a disc in the current drive, then enter the following command exactly as shown.
|This does nothing
When you've entered it, the usual DOS prompt returns without an error, but then try to do something else, or more accurately anything else. You can type into the command line as usual, but no matter what you enter, including any of DOS's built-in commands, the only thing you'll get out of the system from now on is 'File not found'.
The only way out of this is to re-boot, but when you've done that issue a 'DIR' on the disc you were using and take a look at the directory. You should find an extra file, called '%PIPE650.$$$'. If you now 'TYPE' that file you'll find it's empty.
You can certainly get data into the file, and to prove it, next try:
|BACKG
There'll be no visible output from BACKG and the immediate effect is that you'll end up with the same situation as before: further commands don't work. However, after re-booting this time you'll see, if you 'TYPE %PIPE650.$$$', that the screen output from BACKG was written to the file, giving exactly the same result (apart from the effective hang-up in this case) as:
BACKG >%PIPE650.$$$
I'll let you play with that one on your own, but I may come back to it in the future.
COMPETITION RESULTS
You'll remember that in 512 Forum, in Vol.10 No.4, we had a competition which closed on September 20th. I didn't think the answers were too hard to work out but I might have mis-judged, because I have to say that I was disappointed by the fact that there were only four correct entries.
The four members concerned each win a £20.00 prize which they can spend on Essential Software products of their choice. The names of the four, including membership numbers are:
R.G. Shrubsall of Newcastle upon Tyne (membership No. T103435)
S.J. Bowden of London (0111290)
A.D.S. Benham, also of London (036673)
D.T. Blyth of Epsom, Surrey (022920)
The answers to the number of files which would be produced in sets 'A' to 'H' in sequence by the example batch file are:
| Set | Files in set | Running Total | |||||
| A | 8 | 8 | |||||
| B | 36 | 44 | |||||
| C | 120 | 164 | |||||
| D | 330 | 494 | |||||
| E | 792 | 1286 | |||||
| F | 1716 | 3002 | |||||
| G | 3432 | 6434 | |||||
| H | 6435 | 12869 | |||||
As you can see, the number of files in each succeeding set is growing steadily but relentlessly, and that was the reason for the the second part of the question, "Would any individual set, up to 'Z', produce a million files?".
The answer is "Yes". Assuming it were a practical possibility, set 'U' would generate 1,184,040 files and the running total would have reached 4,292,144.
As is usual with this sort of problem, the best approach to finding the answer is to understand the way the mechanism that generates the files works, after which it's remarkably simple. The competition didn't ask you for the method you'd used, but R.G. Shrubsall's entry included his approach. It was ingenious and based purely on numeric theory. He says he thought writing a program wasn't necessary.
I have a programmer's mentality, so naturally I disagree. I thought a short Basic program was the obvious approach. D.T. Blyth thinks the same and included his program too. The other two didn't explain their method, but there weren't any prizes for that so it didn't matter.
I know we're straying into 'BBC' territory somewhat, but if any of you want to see the results for sets 'A to 'Z' just enter and run this Basic program. It can actually be entered as one line if you like, but for clarity I've split it into five.
DIM F%(8):F%(1)=1:O%=0
FOR S%=ASC"A" TO ASC"Z":F%=0
FOR L%=1TO8:F%(L%)=F%(L%)+F%(L%-1)
F%=F%+F%(L%):NEXT
O%=O%+F%:PRINTCHR$S%,F%,O%:NEXT
It will list the answers both for each set, and in total from 'A' to 'Z', in about a second. If you run it in mode 0 (or 128), starting with a clear screen all the answers will be shown without paging.
By way of explanation, a one dimensional array of nine elements, F%() is set up in the first line and is used to calculate the number of files (with names of length L% characters) in each set, S%. F%(1) is initially seeded with 1, representing the original start file, then for each set F% accumulates the total of files produced, while O% accumulates the overall running total.
As you can see, two loops and simple addition is all that was needed. If you initially thought the problem too difficult I hope that now you've seen the answers you don't think it was unreasonable.