🚀 go-pugleaf

In article <1991Apr11.031926.19901@cs.uow.edu.au> david@cs.uow.edu.au (David E A Wilson) writes:
>I have run into a bug in the sort(1) command on a Sun4 running SunOS 4.1.1.
>This occurs both with /usr/bin/sort and /usr/5bin/sort. The problem also
>appears on a Sequent Symmetry running Dynix 2.0v2 (both ucb sort and att sort)
>and finally with the sort command compiled using the 4.3-bsd tahoe sources.
>
>The bug is as follows. I am trying to sort on the 2nd character of the second
>field of a colon separated record. If this character compares equal I then
>sort on the 1st character of the 2nd field.
>
>/usr/bin/sort -t: +1.1 -1.2 +1.0 -1.1 <<!
>abc:Ab:xyz
>def:zA:pqr
>!
>
>This results in:
> ...
>abc:Ab:xyz
>def:zA:pqr
> ...
>Which is incorrect. ...
>
>The problem appears to be in the skip function used to find the start and end
>of sort keys. Patching it to add one to the end pointer fixes my problem but
>may introduce other problems.

That is what you have to do.  If you RTFM very carefully, the bug is in the
IMPLEMENTATION, such that +m.n does not mean the same as -m.n !!  It seems
perverse, but you need:

	/usr/bin/sort -t: +1.1 -1.3 +1.0 -1.2

-- 
Paul S. Sawyer             {uunet,attmail}!unhtel!paul    paul@unhtel.unh.edu
UNH CIS - - Telecommunications and Network Services      VOX: +1 603 862 3262
Durham, New Hampshire  03824-3523                        FAX: +1 603 862 2030

Before coming to the real point, some environmental information first:

In our firm we mostly work with NCR computers (i.e. Towers, about 330 of them,
all SysV versions), but there are also a Sun (old BSD), a few T.I.'s (XenixV)
and since about one year some (about 200) Nixdorf Targons (all SysV boxes).

We have NCR's since about 1984 and most of the software is written on those
and ported to the other types.
Up until the moment we started with none-NCR machines we always worked with
NCR's lpr(1)/print(1) spooler (a Berkeley thing, as I was told), whith which
we NEVER have had ANY problem. In those days we chose that spooler just for
it's better functionallity over lp(1), i.e. forms support, adjustable priority
and things like that.
BTW, all systems are used in administrative environments, and during the day
MUCH printwork is done (most systems have AT LEAST two printers connected,
also fast (1000lpm) line printers).
I mention all this just to illustrate that lp-problems mean SEVERE problems.

When we bought none-NCR systems we were forced to switch to lp(1) and since
the introduction of Sys V.3, NCR decided not to support the lpr/print(1)
spooler anymore. So, on all systems we have lp(1) running now.

Here the flame starts burning:

Things we discovered were:

	1. The serious problem:
	   Print requests get lost, specially when a printer gets out of
	   paper or is switched off-line for changing ribbon or even when
	   it is disabled! (not to be mixed up with cancelled) etc.
	   The problem has been investigated and the causes are obvious.
	   NO, they have NOTHING to do with a bad interface program!
	   Basically they point to bad lpsched design:
	   When lp starts, it causes lpsched to fork a copy in order to
	   do the job. lpsched than opens the port (if it can). Now, when
	   ANYTHING wierd occurs (it gets a SIGHUP or SIGTERM (caused by
	   cancel or disable (YES!!), timeout-on-write or timeout-on-open
	   (what lunatic invented these ?), setting the printer off-line
	   for changing ribbon/paper/toner, paperjam or whatever) it first
	   THROWS THE PRINTREQUEST AWAY and next informs the interface,
	   mostly by passing a SIGTERM to it.

	   Now, from a user's point of view, the very last thing a print
	   scheduler may do is throwing requests away, unless the user
	   orders to do so (ONLY by a *cancel* request) OR when the print
	   has been done successfully (that is, lpsched receives an exit
	   code of 0 (zero) from the interface program).

	   As anyone with experience in administrative environments
	   can tell, this is a very nasty habbit, since sometimes
	   entire production-runs have te be re-runned: many programs
	   update files while printing and endless paper has not been
	   invented yet. OK, on paperjam they sometimes have to do that
	   anyway, but that is obvious to the users.

	   I need to tell that lp is always called with the -c flag,
	   causing the file to be spooled up before printing, since
	   generally files need to be available for update immediately
	   after the printrequest has been performed.

	   All suppliers of the various systems have been informed about
	   the subject, all can reproduce it and all agree that this is
	   very bad design, but since it is an AT&T standard utility, none
	   of them is willing/allowed to dig into it.
	   Merely, a single update will not be sufficient, since on the
	   next OS update or when receiving a new type of system we are
	   stuck again.

	   This problem has now raised a grade of severeness that here and
	   there on management-level the continuity of Unix in these
	   environments has become discutable.

	2. The security hole:
	   lp works with a scheduler (lpr didn't), which is suid'd/sgid'd
	   to itself (i.e. lp/lp or lp/bin, varies per manufacturer), thus
	   arranging that private files CANNOT be printed, and here comes
	   the security hole: you HAVE to make directories/files searchable/
	   readable by OTHERS to be able to print your things.
	   Here and there one really gets the impression that Unix IS a product
	   that is raised by students and hobbyists, when things like that
	   still live after god-knows-how-long-lp-exists-now. UNBELIEVABLE!!!
	   The problem is, that commercial companies seldom have direct
	   access to the original designers (e.g. AT&T) so maybe they never
	   hear about this ? 

	Problem 2. is as bad as problem 1. but less serious (working around
	with chmod's, how very unprofessional it is of course) at least keeps
	production procedures going...

Questions (mostly related to problem 1.):

	1. Who can tell me a way to get the sources of lpsched in order to
	   get rid of at least problem 1.

	2. Where to obtain a spooler that prints rather than purge
	   printrequests (this is NOT my favorite option, unless it is
	   supplied including source files, since it should run on
	   many different systems with different OS(versions))

	3. How to inform/discuss with the RIGHT people at AT&T (or Unix
	   Foundation or so it is called now, I think) to get rid of these
	   problems in the very near future

	4. Just get rid of the problems (please no nonsense about interfaces,
	   that's not where the problems reside)


Many thanks to all you readers, especially thos who can contribute something.

Dick.

In article <1991Apr11.031926.19901@cs.uow.edu.au> david@cs.uow.edu.au (David E A Wilson) writes:
>I have run into a bug in the sort(1) command on a Sun4 running SunOS 4.1.1.

No, it's just a feature.

>/usr/5bin/sort -t: +1.1 -1.2 +1.0 -1.1 <<!

That should have been
	sort -t: +1.1 -1.3 +1.0 -1.2
as documented and shown in an example in the SVR2 manual entry SORT(1).

This is admittedly a strange design that is hard to use correctly.
My guess is that it may have actually been meant to work differently
when it was first implemented, but now that the "sort" utility is in
wide use the specifications cannot be changed without breaking many
applications.

Don't be afraid to hack the lp code, or even to write your own version
of lpsched.  That's what UNIX(R) is all about -- writing your own
programs and tweaking the distributed source code.

In the meantime, you can print private files with

	lp < myfile
or
	for FILE in myfile*; do lp < $FILE; done

You can even write your own "lp" script or alias that inserts the "<"
before running /usr/bin/lp.  The only difficulty is that the name of the
file won't appear on the banner page.
-- 
Col. G. L. Sicherman
gls@corona.att.COM

gwyn@smoke.brl.mil (Doug Gwyn) writes:
>No, it's just a feature.
>>/usr/5bin/sort -t: +1.1 -1.2 +1.0 -1.1 <<!
>That should have been
>	sort -t: +1.1 -1.3 +1.0 -1.2
>as documented and shown in an example in the SVR2 manual entry SORT(1).

It looks like the SunOS 4.1.1 manual is in error then:
---------------------------------------------------------------------------
  Field Specification Options
     -tc  Use c as the word delimiter  character;  unlike  white-
          space  characters,  adjacent  delimiters  indicate word
          breaks; if : is the delimiter character, :: delimits an
          empty word.

     sort-field
          This is a  combination  of  options  that  specifies  a
          field,  within  each  line,  to  sort on.  A sort-field
          specification can take either of the following forms:
               +sw[cf]
               +sw -ew[cf]

          where sw is the number of the starting word  (beginning
          with  `0') to include in the field, ew is the number of
          the word before which to end the field,  and  cf  is  a
          string  containing  collating  flags (without a leading
          `-'.) When  included  in  a  sort-field  specification,
          these  flags  apply  only to the field being specified,
          and when given, override other collating flags given in
          separate  arguments (which otherwise apply to an entire
          line).

          If the -ew option is omitted, the  field  continues  to
          the end of a line.

          You can apply a character offset to sw and ew to  indi-
          cate  that a field is to start or end a given number of
          characters within a word, using the notation: `w.c'.  A
          starting  position  specified in the form: `+w.c' indi-
          cates the character in position c (beginning with 0 for
          the  first  character),  within  word  w (1 and 1.0 are
          equivalent).  An ending position specified in the form:
          `-w.c'  indicates  that the field ends at the character
          just prior to position c (beginning with 0 for the del-
          imiter  just prior to the first character), within word
          w.  If the -b flag is in effect, c is counted from  the
          first non-white-space or non-delimiter character in the
          field, otherwise, delimiter characters are counted.
EXAMPLES
     Sort, in reverse order,  the  contents  of  input-file1  and
     input-file2, placing the output in output-file and using the
     first character of the second field as the sort key:

          sort -r -o output-file  +1.0  -1.1  input-file1  input-
          file2

     Sort, in reverse order,  the  contents  of  input-file1  and
     input-file2  using  the  first  non-blank  character  of the
     second field as the sort key:

          sort -r +1.0b -1.1b input-file1 input-file2
---------------------------------------------------------------------------
-- 
David Wilson	Dept Comp Sci, Uni of Wollongong	david@cs.uow.edu.au

I discovered the bug in lpsched a few years ago and even posted the information
and a source code fix to this newsgroup.  As you have observed, lpsched has a
rather nasty bug that causes files to be dequeued upon termination of the
interface script - regardless of success or failure.  For those without source
code, it is fairly trivial to code the interface script to take into account
this "feature" - which is what I did for the machines I administer.  If anyone
wants a copy of how I did it, I would be happy to send one.

For those with source, here is the diff of the original vs. the fixed versions
of lpsched.c:
608c608
<               resetstatus(1, 1);
---
>               fclose(rfile);
609a610
>                       resetstatus(0, 1);
616,617c617
<                       fclose(rfile);
<                       unlink(rname);
---
>                       resetstatus(1, 1);
705c705
<  *    if dflag != 0 then delete outputq entry and remove associated data
---
>  *    if oflag != 0 then delete outputq entry and remove associated data

Note that the entire LP package was rewritten and expanded in SVR3.2.  The
lpsched bug was fixed as a side-effect.  Three new features were added:
access to forms, easier administration of filters and a menu interface for
administration.  Lpsched is now setuid root but does setuid() before calling
the interface script.  Lp is no longer setuid/setgid, so your second problem
will also disappear.  In the meantime, as someone else suggested, you can
put a wrapper around the lp command to make sure protected files are sent
to the real lp program via stdin.  I did something similar but for a very
different reason.

regards,
L. Mark Larsen
lml@atlas.att.com

In article <1950@ahds.UUCP> dick@ahds.UUCP (Dick Heijne CCS/TS) writes:
> 	   lp works with a scheduler (lpr didn't), which is suid'd/sgid'd
> 	   to itself (i.e. lp/lp or lp/bin, varies per manufacturer), thus
> 	   arranging that private files CANNOT be printed,

Problem 1 is a major boner, but this can be handled just by doing:

	cat file | lp

> 	1. Who can tell me a way to get the sources of lpsched in order to
> 	   get rid of at least problem 1.

There are a couple of PD, freeware, or GNUware spoolers out there in the
various comp.sources.* archives.

> 	3. How to inform/discuss with the RIGHT people at AT&T (or Unix
> 	   Foundation or so it is called now, I think) to get rid of these
> 	   problems in the very near future

Ha. ha. ha. ha. ha. They can't even be convinced to get a summer student
to run through the sources replacing "cannot open FROBOZZ" with at *least*
perror.
-- 
Peter da Silva.  `-_-'  peter@ferranti.com
+1 713 274 5180.  'U`  "Have you hugged your wolf today?"