🚀 go-pugleaf

In article <1991Mar19.052103.9026@ferret.ocunix.on.ca>
clewis@ferret.ocunix.on.ca (Chris Lewis) writes:

[I wrote]
>>>	Just so.  Now think how many things break if "lpr B" lists B
>>> if the printer is a simple lineprinter but produces a fancy graphic
>>> if we upgrade it to a LaserWriter.
>
>On the contrary, I'd suggest that it was no longer broken.

	Bleeah!  If you've been listing a project to the lineprinter, as
it develops, for weeks, months, years;  and you come in one morning to find
a shiny new printer in place;  and you type "lpr myfile" just as you always
used to;  and you get an abstract greyish bitmap instead of your listing;
where then is the break?

>A truly smart spooler would figure out what printers are appropriate
>for a given magic cookie, and route the results there.  Otherwise,
>you're expecting everybody to remember which printers can handle a given
>format and/or remember lots of obscure options to tell the printer to
>go into the correct mode.

	But this is backwards from the original problem.  Should a file
with *no* cookie be cooked automagically?  For which printer?  Should
I have to remember lots of cookies, so that when I have a file which, by
chance, starts with a magic cookie for some remote printer, I remember to
encapsulate it by hand to that it gets listed locally instead of graphiced
[:-)] remotely?

	Why does anything need to be so smart?  *My* files don't usually
have the magic cookies -- the cookies are put in by the programs that
create the formats, and those programs can equally well direct the
results to the appropriate printer [at least as an option].  The spooler
should look after just one activity -- shovelling files, correctly
sequenced and separated, out to printers [etc].  Serious smarts should
be handled by conversion programs (equivalently, by virtual printers).

>		 But I would contend that someone generating postscript
>usually doesn't want to see the postscript listing, they want to see
>the "graphic" that the postscript listing represents.  In those rare
>occasions where the user wants to see the internal language, [...]

	PostScript gets generated two ways -- by program, and by hand.
When it is generated by program, you're right.  But when I write PS,
certainly I want to test it, but I also want to get file listings.

>Run the bare postscript thru "pr" - not only do you get the output
>nicely paginated with page numbers, the "%!" doesn't even get recognized
>because it's no longer first in the file.

	So:  you say "lpr file" to get graphics or some listings, and
		"pr file | lpr" to get other listings.
	     I say "lpr file" to get graphics, and "list file" to get
		listings [or I would, except that the actual commands
		are more mnemonic for our actual devices].
	I know which I prefer!

>>If you object to files starting with %! being treated different from
>>others that don't, what is your view on executable files that start
>>with #! /bin/sh ?????

	I don't much care for it.  But I can live with it, recognising
it as an efficiency hack for the kernel;  note that the actual behaviour
(eg on SunOS) is the opposite way round from your spooler.  If I try to
run a shell script that doesn't begin "#! /bin/sh", it fails, rather than
calling up some mythical ensheller.

>More to the point, what about when "file" says:
>
>    executable (RISC System/6000 V3.1) or object module not stripped
>
>Blindly routing it to a printer is stupid.

	Better than blindly turning it into PostScript!

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk