romwa@gpu.utcs.toronto.edu (Mark Dornfeld) (08/02/88)
Is there a "standard" method for implementation of a $PRINTER environment variable in a user's shell? When several printers are on a single system, it is usually desirable to have user output appear on the printer closest to his/her work area instead of on a printer six floors up and on the other side of the building. The $PRINTER variable should contain the destination of the default printer for each user. I suspect it would have to get picked up by the spooler somehow so that the final command line would look like this: lp -d$PRINTER filename If anyone has implemented such an environment, please reply via Email. Thanks in advance. Mark T. Dornfeld Royal Ontario Museum 100 Queens Park Toronto, Ontario, CANADA M5S 2C6 mark@utgpu!rom - or - romwa@utgpu
danno@3b2.UUCP (Daniel Notov) (08/03/88)
In article <1988Aug2.085719.11489@gpu.utcs.toronto.edu>, romwa@gpu.utcs.toronto.edu (Mark Dornfeld) writes: > Is there a "standard" method for implementation of a $PRINTER > environment variable in a user's shell? On UNIX System V, the lp print spooler will search the environment for a variable named LPDEST. If it is set, the print job will be sent to that destination. No need to even include the "-d" option on the command line. This works on all AT&T 3B[1]x systems. -- Daniel S. Notov | {monster,uunet}!onm3b2!danno Ogilvy & Mather, Inc. | (212) 907-4255 New York, NY |
jfh@rpp386.UUCP (John F. Haugh II) (08/03/88)
In article <1988Aug2.085719.11489@gpu.utcs.toronto.edu> romwa@gpu.utcs.toronto.edu (Mark Dornfeld) writes: >Is there a "standard" method for implementation of a $PRINTER >environment variable in a user's shell? yes, it is spelt "LPDEST". i frequently use it on three systems connected by ether and uucp to route print requests. i can even provide model scripts for anyone wanting to know how to queue lp requests over uucp. just as soon as pigs.UUCP returns to the air ... -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- apologizes to Dennis O'Connor
jeff@drexel.UUCP (Jeff White) (08/04/88)
In article <1988Aug2.085719.11489@gpu.utcs.toronto.edu>, romwa@gpu.utcs.toronto.edu (Mark Dornfeld) writes: > Is there a "standard" method for implementation of a $PRINTER > environment variable in a user's shell? When several printers > are on a single system, it is usually desirable to have user > output appear on the printer closest to his/her work area > instead of on a printer six floors up and on the other side of > the building. > > ... > > If anyone has implemented such an environment, please reply via > Email. > I've modified the login program to do exactly that (we run 4.2 BSD and have source code to it). Basically, I just duplicated all the code in login that sets up the terminal type, and changed it so it sets a PRINTER variable instead. It uses a file called /etc/lprtype, the same format as ttytype, except instead of the terminal type, I just specify the name of a printer. The nice thing about it is that is is setup automatically (no way to accidentally or on purpose remove the code from a .login file, for example), and it chooses the printer based on what terminal you are logged in to, not who you are logged in as. Since it is an almost complete duplication of Berkeley code, I'm not sure if I could legal send out a copy of my updated program, or even the modifications. Perhaps someone of the legal persuasion could answer this for me. Just as an additional note, I also wrote two other modifications which may be of interest. The first was the ability to specify priorities to people logging in. Our computer is primarily for faculty and grad student research, but occasionally we have 1 or 2 undergrad courses on it, and we wanted to be able to have those people run at a lower priority. I created a file called /etc/priority which handles all of it. Part of it is shown below. # Format of /etc/priority file # {user,group name}:{u,g}:{priority}:{display code}:{message id}:{type of acc} # {string}:{string*1}:{int}:{int}:{string}:{string*1} # display code: -1 (don't show), 0 (user optional), 1 (force display) # message id is name of file to display, located in /etc/priors # type of account: r (research), e (educational/class), c (commercial) uucp:u:1:0::r nick:u:0:0::r jeff:u:0:0::r lisa:u:1:0::r Y901:g:0:1:y901:e In login, the code makes two passes over this file. First it checks to see if the group you belong to is listed (the first field must match and the second field must be a 'g'). say you belonged to group Y901. The priority file says that your priority will be set to 0 (unchanged), and that the message file y901 (in the default directory /etc/priors) will always be displayed (if it was set to 0 (user optional), a .priority file (or something like that - I forget the exact name) could be created so that a message would not appear (like .hushlogin). A second pass is then made to see if a username match is made. If it is, these values are used. This was implemented so that, for example, a class could have it's priority reduced, but the instructor or T/A (also using a class account), could have his priority set to a higher, more normal priority. The other modification I made was to have the ability to display a separate, unique motd for each terminal. I created a directory call /etc/motds, and in it are the names of the terminals (h1, p0). After /etc/motd is displayed, login checks to see if a file exists for the terminal, and if it is readable, displays it. We use it because we have a lot of different terminals (ordinary vt100's, Qume text and graphics terminals, a Tektronix color terminal, and also some Mac's), and it allows us to give some information about each terminal. Some examples are: ---- This is a Tektronix 4105 graphics terminal. To go into graphics mode, type '4105' (use 'gclear' to clear screen'). To go into editing (text) mode, type 'vt100'. ---- ---- If you are using MacTerminal/DU_Talk and plan on doing file transfer between the Mac and the Vax, make sure that the remote computer is set up to be a Macintosh and the transfer protocol is Xmodem under the File Transfer Setting menu (also equivalent to MacTerminal 1.1 and Mac Xmodem). You should then use the commands macsend and macput on the Vax. As a quick note, both commands with the '-u' option allow uploading and downloading of text files. ---- I think this is a really useful feature, especially for anyone is a public access environment with lots of different equipment. If you have questions about any of this, feel free to respond. Jeff White Drexel University - ECE Dept. rutgers!bp!drexel!jeff
paul@ozdaltx.UUCP (08/07/88)
I have utilized an original software switching program at my office since February without a problem. It utilizes the 'env' setting, the LPDEST assignment, a modification of the mkuser.prof to create the calls to a program I dubbed "setprt" in the /etc directory - which cat the shell script line out to an executable file in the particular users directory. The "lp" command is used to queue the printer - and works fine! This approach maybe not the cleanest or simplest method... but IT WORKS! 8-B Paul Snave
robert@computing-maths.cardiff.ac.uk (Robert Evans) (08/09/88)
In article <1988Aug2.085719.11489@gpu.utcs.toronto.edu>, romwa@gpu.utcs.toronto.edu (Mark Dornfeld) writes: > Is there a "standard" method for implementation of a $PRINTER > environment variable in a user's shell? When several printers > are on a single system, it is usually desirable to have user > output appear on the printer closest to his/her work area > instead of on a printer six floors up and on the other side of > the building. I do this for our Ultrix system using the "ev" capability in the /etc/gettytab terminal configuration data base. I want prints from terminals in one room to go to printer "lp1" instead of the default "lp". These terminals are all hard-wired. The type fields in /etc/ttys for the special files corresponding to the terminals in this room reference entries in /etc/gettyab which contain the field:- :ev=PRINTER=lp1: This environment variable is passed by getty to login and hence to the shell. The man page gettytab(5) for Ultrix 2.0 states that login recreates its environment so that this technique wouldn't work. However, this is not true as the following comment from the source of login shows: * * Revision 1.6 84/10/25 14:12:23 jg * Undid utmp changes. Added -p flag to preserve environment passed * from getty. * It may be true on some versions of UNIX though. The man page for gettytab for SunOS 3.5 also lists the "ev" capability. One problem we had in having PRINTER set, was that it altered the destination of prints produced by Adobe's PostScript filter programs psroff, ptroff and enscript. By default, these send their output to device PostScript but if PRINTER is set, they send it there instead. Since this is never what is intended here, I've changed the scripts psroff and ptroff and the binary enscript to use a variable LASER for an alternative destination instead of PRINTER. -- -- Robert Evans, Dept of Computing Maths, University College Cardiff, PO Box 916, Cardiff, Wales, UK, CF2 4YN. Tel: +44 (0)222 874000 x 5518 E-mail: R.Evans@computing-maths.cardiff.ac.uk UUCP: R.Evans@cf-cm.UUCP
haugj@pigs.UUCP (Joe Bob Willie) (08/09/88)
In article <4907@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes: > In article <1988Aug2.085719.11489@gpu.utcs.toronto.edu> romwa@gpu.utcs.toronto.edu (Mark Dornfeld) writes: > >Is there a "standard" method for implementation of a $PRINTER > >environment variable in a user's shell? > > yes, it is spelt "LPDEST". i frequently use it on three systems connected > by ether and uucp to route print requests. i can even provide model scripts > for anyone wanting to know how to queue lp requests over uucp. just as > soon as pigs.UUCP returns to the air ... ok, pigs is back on the air and as i've received a number of requests for the models i use (they are really QUITE simple ;-), i'm including them here. to use this model, install the file below as /usr/spool/lp/model/remote and then edit the resultant file after it is installed using lpadmin. you will then need to edit your L.cmds file to allow lp commands from the machine which is doing the calling. real easy ... the machine named below is on the ethernet with pigs. after you install this model you will need to change pifo to your remote machine's name. good luck. oh, this is shareware, please send $10 to my retirement fund ;-) - john. ----------------------- cut as /usr/spool/lp/model/remote ----------------- # # @(#)remote 1.1 4/19/84 # lp interface for remote line printer # # SCCS @(#)remote 1.1 machine=pifo copies=$4 shift; shift; shift; shift; shift files="$*" for file in $files do cat "$file" 2>&1 echo "\014\c" done | uux -n - "$machine!lp -s -n$copies" exit 0 -- jfh@rpp386.uucp (The Beach Bum at The Big "D" Home for Wayward Hackers) "Never attribute to malice what is adequately explained by stupidity" -- Hanlon's Razor