home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!not-for-mail
- From: gwyn@smoke.brl.mil (Doug Gwyn)
- Newsgroups: comp.std.unix
- Subject: Re: 1003.7.1/Palladium/Existing Practice
- Date: 21 Jan 1993 10:30:25 -0800
- Organization: U.S. Army Ballistic Research Lab, APG MD.
- Lines: 19
- Sender: sef@ftp.UU.NET
- Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
- Message-ID: <1jmq41INNfku@ftp.UU.NET>
- References: <1jhnamINNlth@ftp.UU.NET> <1jhvrnINNrdm@ftp.UU.NET>
- NNTP-Posting-Host: ftp.uu.net
- X-Submissions: std-unix@uunet.uu.net
-
- Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
-
- In article <1jhvrnINNrdm@ftp.UU.NET> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
- > Also, there was already precedent set within POSIX by the POSIX.2
- >inclusion of lp(1) as a command line interface for printing. This has
- >been studiously ignored by the vendors promoting Palladium --
-
- It's been a while since I've seen POSIX.2 drafts, but unless something
- has radically changed from existing "lp" practice, one should note that
- there need be little connection between an interface such as "lp" and
- the guts of a spooling system. As previously noted, MDQS includes
- Bourne shell scripts implementing useful subsets of "lp" and "lpr"
- even though the "lp"/"lpr" user requests all get translated into MDQS-
- specific operations within these implementations. Presumably something
- similar could be done to provide "lp" functionality for any reasonable
- UNIX/POSIX spooling system.
-
-
- Volume-Number: Volume 30, Number 34
-