michaelm@bcsaic.UUCP (Michael Maxwell) (12/16/86)
[the line eater eater was here] I have a friend who wants to collect lots of files in a telecommunications session, then print them later on (like overnight). The trouble is that MS-DOS, wretched excuse for an OS that it is, only allows 10 files to be in the print queue at a time. And since the print command just queues things up, you can't just run it in a loop and tell it to print one file after another. (It will go through the loop 10 times, then die.) My next thought (thinking in terms of Unix shell scripts) was that I could make some kind of a loop like the following in a batch file: for %F in * print1 %F The file print1.bat would contain something like: print %1 <sleep until "print" command returns "queue empty msg"> --taking advantage of the fact that "print", w/o any arguments, just tells you what's in the queue. But there are several problems with this idea; how do you get DOS to sleep? (I'd like to not worry about programming in assembler, thanks! And putting in some kind of loop to check the output of "print" until the queue is empty sounds like a good way to keep the printer from getting anywhere fast.) And how can a batch file tell what the "print" command returns? I could redirect the output of "print" into a file, but how do you get DOS to compare the contents of two files and return the result in some kind of errorlevel (or something else that "if" can use--note that "print" returns errorlevel 0 regardless of whether there's anything in the print queue)? Maybe something along the following lines would work: for %F in * print2 %F --where print2.bat contains: again: print %1 if errorlevel 1 goto again Again, this seems wasteful of machine cycles... (I may not have the syntax right, I don't have a PC here.) I'm sure someone's done this before, and probably with error checking (printer out of paper, etc.). Pointers? Tested methods? -- Mike Maxwell Boeing Advanced Technology Center arpa: michaelm@boeing.com uucp: uw-beaver!uw-june!bcsaic!michaelm
michael@orcisi.UUCP (12/18/86)
> My next thought (thinking in terms of Unix shell scripts) was that I could > make some kind of a loop like the following in a batch file: > for %F in * print1 %F > The file print1.bat would contain something like: > print %1 > <sleep until "print" command returns "queue empty msg"> Would for %f in * do copy %f lpt1: do the job? I believe "print" is only really needed when you want to use the printer in the background.
petera@utcsri.UUCP (Peter Ashwood-Smith) (12/18/86)
> [the line eater eater was here] > I have a friend who wants to collect lots of files in a telecommunications > session, then print them later on (like overnight). The trouble is that > MS-DOS, wretched excuse for an OS that it is, only allows 10 files to be in > the print queue at a time. And since the print command just queues things up, Why not just cat all of the files together with 'copy' and then print the entire mess? If you need a better connection between files ie an extra FF or something then write your own 'cat'. Peter Ashwood-Smith. University of Toronto.
cramer@kontron.UUCP (Clayton Cramer) (12/18/86)
> I have a friend who wants to collect lots of files in a telecommunications > session, then print them later on (like overnight). The trouble is that > MS-DOS, wretched excuse for an OS that it is, only allows 10 files to be in > the print queue at a time. And since the print command just queues things up, > you can't just run it in a loop and tell it to print one file after another. > (It will go through the loop 10 times, then die.) > Easy. One of the command line switches on PRINT the first time you run it allows you to specify the depth of the PRINT queue -- you can expand it to as many as 31 files. > Mike Maxwell Clayton E. Cramer "You cannot bring about prosperity by discouraging thrift. You cannot strengthen the weak by weakening the strong. You cannot help the wage earner by pulling down the wage payer. You cannot further the brother- hood of man by encouraging class hatred. You cannot keep of out of trouble by spending more than you earn. You cannot build character and courage by taking away man's initiative and independence. You cannot help men permanently by doing for them what they could and should do for themselves." -- Abraham Lincoln
news@cit-vax.Caltech.Edu (Usenet netnews) (12/19/86)
Organization : California Institute of Technology Keywords: From: tim@tomcat.Caltech.Edu (Tim Kay) Path: tomcat!tim michaelm@bcsaic.UUCP (Michael Maxwell) writes: >make some kind of a loop like the following in a batch file: > for %F in * print1 %F >The file print1.bat would contain something like: > print %1 > <sleep until "print" command returns "queue empty msg"> >--taking advantage of the fact that "print", w/o any arguments, just tells you >what's in the queue. But there are several problems with this idea; how do >you get DOS to sleep? (I'd like to not worry about programming in assembler, > [etc.,etc.,...] Rather than print file why don't you use copy file prn This will print the file and then return to the batch file. You might have to add a command to page eject after each file, such as echo ^L > prn Is this what you are after? Timothy L. Kay tim@csvax.caltech.edu Department of Computer Science Caltech, 256-80 Pasadena, CA 91125
crimmins@uxc.cso.uiuc.edu (12/19/86)
/* Written 2:29 pm Dec 16, 1986 by michaelm@bcsaic.UUCP in uxc.cso.uiuc.edu:comp.sys.ibm.pc */ >session, then print them later on (like overnight). The trouble is that >MS-DOS, wretched excuse for an OS that it is, only allows 10 files to be in >the print queue at a time. And since the print command just queues things up, >you can't just run it in a loop and tell it to print one file after another. >(It will go through the loop 10 times, then die.) > >My next thought (thinking in terms of Unix shell scripts) was that I could >make some kind of a loop like the following in a batch file: > for %F in * print1 %F Why not avoid the whole mess with print by using type or copy instead? You could easily write a batch loop like you have above. For example, for %%f in (*.prn) do type %%f>prn will print all files with an extension of .prn and there are no limits on the number of files. Note that this will not insert form feeds between files. If you want them, you can create a file that contains only a form feed character by typing copy con ff.txt (or any other appropriate filename), typing a ctrl-L, and then pressing <F6> and return. Then modify your batch file to say for %%f in (*.prn) do copy %%f+ff.txt prn This should eliminate your problem and give you the same results as print would have. ---- Dan Crimmins University of Illinois at Urbana-Champaign Computing Services Office - Micro Consulting Dept. ARPA: crimmins@uiucuxc.cso.uiuc.edu BITNET: crimmins@uiucuxc.bitnet CSNET: crimmins@uiucuxc.csnet UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!crimmins
tom@vrdxhq.UUCP (Tom Welsh) (12/19/86)
In article <88@bcsaic.UUCP>, michaelm@bcsaic.UUCP (Michael Maxwell) writes: > [the line eater eater was here] > I have a friend who wants to collect lots of files in a telecommunications > session, then print them later on (like overnight). The trouble is that > MS-DOS, wretched excuse for an OS that it is, only allows 10 files to be in > the print queue at a time. And since the print command just queues things up, > you can't just run it in a loop and tell it to print one file after another. > (It will go through the loop 10 times, then die.) > A real stupid way is : copy *.* lpt1: The disadvantages of this are: 1) You got put the stuff you want to print in a directory by itself so you don't print unwanted stuff 2) You don't get top-of-form on each file like in PRINT 3) You can't use the machine for anything else
ashok@softart.UUCP (Ashok C. Patel) (12/20/86)
I'm not sure about versions of DOS < 3.0 but version > 3.0 have a /Q option to the "print" command. This lets you define the queue size. According to my manual, the queue size can be extended to 32. The first time you invoke print do it this way: print /Q:32 This will set up a 32 entry queue. (this is what the manual says anyway) For queues greater than 32, you will have to resort to much trickery (some of which has been posted already). ------------------------- Ashok C. Patel Softart Microsystems Inc.
boykin@custom.UUCP (12/20/86)
>I have a friend who wants to collect lots of files in a telecommunications >session, then print them later on (like overnight). The trouble is that >MS-DOS, wretched excuse for an OS that it is, only allows 10 files to be in >the print queue at a time. If you're running DOS version 3.0 or later, the initial PRINT command, i.e. the one which specifies the output device and causes a portion of print to become resident, accepts an argument to specify the maximu number of files in the queue. The default is 10, max is 32 (probably still not as much as you would like though!) the command looks like this: print/q:32/D:PRN filename... When we're looking to do more than 32 files we use the version of PR we wrote to send output directly to the printer, i.e.: PR *.C *.H > PRN That also has the advantage of making the output look a little nicer. Joe Boykin Custom Software Systems
michaelm@bcsaic.UUCP (Michael Maxwell) (12/23/86)
In article <88@bcsaic.UUCP> michaelm@bcsaic.UUCP (me) writes: >I have a friend who wants to collect lots of files in a telecommunications >session, then print them later on (like overnight). The trouble is that >MS-DOS, wretched excuse for an OS that it is, only allows 10 files to be in >the print queue at a time. And since the print command just queues things up, >you can't just run it in a loop and tell it to print one file after another. >(It will go through the loop 10 times, then die.) Thanks to all who replied; no need to keep those cards and letters coming. For anyone who may be interested, the solutions are generally of the form-- for %F in * type %F > lpt1: --`type' of course does not start up a background process, so the loop prints out one file after another. (I haven't tested it yet, but I'm hoping the expansion of "*" into 137 file names won't cause the command line to exceed DOS's limitation on the length of a command line...) -- Mike Maxwell Boeing Advanced Technology Center arpa: michaelm@boeing.com uucp: uw-beaver!uw-june!bcsaic!michaelm