hxd9622@ritcv.UUCP (Herman Darmawan) (07/25/87)
I ran troff but interrupted it halfway. After that, troff reports
"Typesetter busy" message. There is nobody else on the system. No
processes are using troff either. I looked for any possible lock file
that troff may maintain but no luck. I have even powered down the
system and brought it back up and it still reports the same thing.
HELP!!!
-+-+-+-
Herman Darmawan @ Rochester Institute of Technology
UUCP {allegra,seismo}!rochester!ritcv!hxd9622
BITNET HND9622@RITVAXCgwyn@brl-smoke.ARPA (Doug Gwyn ) (07/26/87)
In article <585@ritcv.UUCP> hxd9622@ritcv.UUCP (Herman Darmawan) writes: >After that, troff reports "Typesetter busy" message. REMINDER: When asking for help with a problem, give DETAILS such as what version of the software (UNIX, DWB, whatever) you're using, the exact command invocation, etc. Old troff (pre-DITROFF) reports "typesetter busy" when you attempt to open /dev/cat (Wang/GSI C/A/T typesetter interface) and either your C/A/T is in use by another troff OR you don't have such an animal attached to your system. I suspect the latter is the case. How DO you typeset stuff, anyway? Should you be using new (DI)troff instead? If you have a C/A/T emulator for some other printer, then perhaps you need to specify the troff -t option and route its output somewhere. Or did someone perhaps install a new release of troff? Without further details, it's pretty hard to know what your problem is.
tim@ora.UUCP (Tim O'Reilly) (07/29/87)
In article <585@ritcv.UUCP>, hxd9622@ritcv.UUCP (Herman Darmawan) writes: > I ran troff but interrupted it halfway. After that, troff reports > "Typesetter busy" message. There is nobody else on the system. No > processes are using troff either. I looked for any possible lock file > that troff may maintain but no luck. I have even powered down the > system and brought it back up and it still reports the same thing. Old troff expects to talk directly to a typesetter. Unlike most well-behaved UNIX programs, it does not write to standard output unless you tell it to. You must use the -t option to send output to standard out (which means you must also have a postprocessor to interpret the output for the typesetter or laser printer you want to send it to). If you don't use -t, you'll get this "Typesetter Busy" message. This (almost certainly) has nothing to do with the fact that you interrupted troff part way through. The standard usage these days, since most people don't have CAT typesetters directly connected to their systems, is: troff -t -mx -Tsomedevice | postprocessor | lp -dsomedevice If you need more general background on troff, it's covered pretty thoroughly in a number of commercially available books. I'm biased (since I helped write it), but I think the best is UNIX Text Processing by Dale Dougherty and Tim O'Reilly, published by Howard Sams. It's available in most technical bookstores ($26.95). In addition, we sell it by mail order (call 1-800-338-NUTS). -- Tim O'Reilly (617) 527-4210 O'Reilly & Associates, Inc., Publishers of Nutshell Handbooks 981 Chestnut Street, Newton, MA 02164 UUCP: seismo!uunet!ora!tim ARPA: tim@ora.uu.net
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/30/87)
In article <643@ora.UUCP> tim@ora.UUCP (Tim O'Reilly) writes: > troff -t -mx -Tsomedevice | postprocessor | lp -dsomedevice This isn't right, at least for most implementations of troff. Old (C/A/T) troff: troff -t -mx | cat-interpreter... New (DI) troff: troff -Tdevice-name -mx | postprocessor... Since -mx is actually an abbreviation for a filename, NOT an option (gross, isn't it?), it should follow all actual options. Many postprocessors handle spooling automatically so the user doesn't have to pipe into a spooler.
jay@unm-la.UUCP (Jay Plett) (07/30/87)
In article <6196@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: [ stuff deleted ] > Since -mx is actually an abbreviation for a filename, NOT an option > (gross, isn't it?), it should follow all actual options. -mx does indeed cause the file /usr/lib/tmac/tmac.x to be sourced. But it is an option. Makes no difference whatsoever where you put it on the command line. The file isn't sourced until after all the options are parsed. The only time order of options is significant is when you use multiple -m args (with newer releases of ditroff/nroff which allow them), in which case the macro files are sourced in the order stated. Still, they don't have to be consecutive and they may have other options interspersed. Like other options, -m options must precede any file- name arguments. -- Jay Plett UUCP: {cmcl2,ihnp4}!lanl!unm-la!jay {ucbvax,gatech}!unmvax!unm-la!jay ARPA: jxyp@lanl.gov
tim@ora.UUCP (Tim O'Reilly) (07/30/87)
In article <6196@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <643@ora.UUCP> tim@ora.UUCP (Tim O'Reilly) writes: > > troff -t -mx -Tsomedevice | postprocessor | lp -dsomedevice > > This isn't right, at least for most implementations of troff. > > Old (C/A/T) troff: > troff -t -mx | cat-interpreter... There are a number of postprocessors now available for otroff that make it work with laser printers, much as I've noted. Tplus from Textware International, and cat2dit/devps from Pipeline Associates come to mind. > New (DI) troff: > troff -Tdevice-name -mx | postprocessor... > Many postprocessors handle spooling automatically so the user > doesn't have to pipe into a spooler. Many don't. However, the caution should certainly be noted. There is a lot of variation out there. > Since -mx is actually an abbreviation for a filename, NOT an option > (gross, isn't it?), it should follow all actual options. I've never heard this one before. This is not essential. I've intermixed my macro options with other options in all kinds of order with no apparent differences in effect. -- Tim O'Reilly (617) 527-4210 O'Reilly & Associates, Inc., Publishers of Nutshell Handbooks 981 Chestnut Street, Newton, MA 02164 UUCP: seismo!uunet!ora!tim ARPA: tim@ora.uu.net