Loading ...
Sorry, an error occurred while loading the content.

Re: More Apple hosery of CUPS

Expand Messages
  • thad_floryan
    ... Hi Joan! I was almost thinking of dumping all of the Apple CUPS and installing the one from my RedHat 9 system (circa 2003) along the lines of how I just
    Message 1 of 9 , Jun 2, 2012
    • 0 Attachment
      --- In linux@yahoogroups.com, "jleach728@..." <jleach728@...> wrote:
      > --- In linux@yahoogroups.com, "thad_floryan" <thad@> wrote:
      > > [...]
      > > Note the Apple CUPS doesn't have the option to disable the
      > > pre-filter [except with the -l option to lpr] so it filters
      > > EVERYTHING (all the PostScript) and only blank empty pages are
      > > printed. This almost looks like a Poeterring-ism. :-)
      > >
      > > Interestingly, I'm unable so far to find the default setting fo
      > > the number of copies in any Apple CUPS configuration file on
      > > CentOS, so the code must be assuming it's always 1 unless
      > > overridden by option on a printer command.
      >
      > Couldn't another CUPS file be adapted to run on Centos? Maybe from
      > another RPM or source distro? I know I've read how other things lik
      > this can happen, at least we can hope...

      Hi Joan!

      I was almost thinking of dumping all of the Apple CUPS and installing
      the one from my RedHat 9 system (circa 2003) along the lines of how I
      just simply copied the executable for the "appt" program from that
      RedHat box to CentOS 6.2 and it worked perfectly.

      I'm really busy this weekend so I'll "live" with the "lpr -l file.ps"
      for the time being as a workaround.

      As I wrote here previously, that "appt" program comprises produced C
      code from both lexx and yacc and I had to use a Solaris system to
      create usable files which would handle, for example, the "ñ" in the
      nick-name, Neña. of my housekeeper, Magdalena, on the appointment
      calendar produced by the "appt" program. None of the GNU equivalents
      for lexx and yacc, flex and bison respectively, processed those files
      correctly and I didn't (and still don't) have the time to make changes
      once I discover the source of the problem.

      For the curious:

      procyon bash 5998/6000> which appt
      /usr/local/bin/appt

      procyon bash 5998/6000> ll /usr/local/bin/appt
      -rwxr-xr-x 1 thad thad 18948 Jun 15 2005 /usr/local/bin/appt*

      procyon bash 5998/6000> file /usr/local/bin/appt
      /usr/local/bin/appt: ELF 32-bit LSB executable, Intel 80386, \
      version 1 (SYSV), dynamically linked (uses shared libs), for \
      GNU/Linux 2.2.5, stripped

      procyon bash 5998/6000> uname -a
      Linux procyon 2.6.32-220.17.1.el6.x86_64 #1 SMP Wed May 16 \
      00:01:37 BST 2012 x86_64 x86_64 x86_64 GNU/Linux

      procyon bash 5998/6000> cat /etc/issue
      CentOS release 6.2 (Final)
      Kernel \r on an \m

      and here's one program I compiled on CentOS during March 2012 when
      I was still setting-up the new system:

      procyon bash 5998/6000> ll /usr/local/bin/pcal
      -rwxr-xr-x 1 thad thad 181218 Mar 22 20:36 /usr/local/bin/pcal*

      procyon bash 5998/6000> file /usr/local/bin/pcal
      /usr/local/bin/pcal: ELF 64-bit LSB executable, x86-64, \
      version 1 (SYSV), dynamically linked (uses shared libs), \
      for GNU/Linux 2.6.18, not stripped
    • ed
      ... Hash: SHA1 ... Reminds me of a comment from here a few years ago: Can t Usually Print Shit Well, that seems quite true now. ... Thanks for the tip. For
      Message 2 of 9 , Jun 3, 2012
      • 0 Attachment
        -----BEGIN PGP SIGNED MESSAGE-----
        Hash: SHA1

        On Sun, Jun 03, 2012 at 02:30:53AM -0000, thad_floryan wrote:
        > Long-time group members may recall my prior comments how Apple hosed
        > CUPS when they bought it from Easy Software Products in 2007; CUPS'
        > history is here: <http://en.wikipedia.org/wiki/CUPS>.
        >
        > Welllll, I found another new Apple CUPS brain-deadism a short while ago
        > when attempting to print a PostScript file exported from xfig on my
        > new CentOS system per "lpr file.ps" -- nothing printed. The common
        > usage "lpr file.ps" works fine on all my other systems as do enscript
        > and friends.

        Reminds me of a comment from here a few years ago:

        "Can't Usually Print Shit"

        Well, that seems quite true now.

        > A little bit of research turned up a [new to me] option for lpr, "-l",
        > which is documented as:

        Thanks for the tip. For what it's worth I frequently print to file and
        then use

        lpr -o number-up=2 -o Duplex=DuplexNoTumble file.ps

        I guess I'll just have to add a bash alias

        alias lpr="lpr -l"

        or something. As yet I've not needed this on Debian Squeeze.

        - --
        Best regards,
        Ed http://www.s5h.net/

        -----BEGIN PGP SIGNATURE-----
        Version: GnuPG v1.4.10 (GNU/Linux)

        iEYEARECAAYFAk/LffEACgkQ4dyr7s6PRYiGyQCaAnZpDeRknF7d/4HDSlaPjVxC
        ZYgAn21p91Lo1VvsobIrC7iPmCl+r9VU
        =hrDL
        -----END PGP SIGNATURE-----
      • thad_floryan
        ... You re very welcome! I m going to experiment later today with copying the: /etc/cups/lpoptions file from my old RedHat box over the empty one on CentOS 6.2
        Message 3 of 9 , Jun 3, 2012
        • 0 Attachment
          --- In linux@yahoogroups.com, ed <ed@...> wrote:
          >
          > On Sun, Jun 03, 2012 at 02:30:53AM -0000, thad_floryan wrote:
          > > Long-time group members may recall my prior comments how Apple
          > > hosed CUPS when they bought it from Easy Software Products in
          > > 2007; CUPS' history is here: <http://en.wikipedia.org/wiki/CUPS>.
          > >
          > > Welllll, I found another new Apple CUPS brain-deadism a short
          > > while ago when attempting to print a PostScript file exported
          > > from xfig on my new CentOS system per "lpr file.ps" -- nothing
          > > printed. The common usage "lpr file.ps" works fine on all my
          > > other systems as do enscript and friends.
          >
          > Reminds me of a comment from here a few years ago:
          >
          > "Can't Usually Print Shit"
          >
          > Well, that seems quite true now.
          >
          > > A little bit of research turned up a [new to me] option for lpr,
          > > "-l", which is documented as:
          >
          > Thanks for the tip.

          You're very welcome!

          I'm going to experiment later today with copying the:

          /etc/cups/lpoptions

          file from my old RedHat box over the empty one on CentOS 6.2 and see
          what happens. Having to add the "-l" on CentOS seems regressive.

          > For what it's worth I frequently print to file and
          > then use
          >
          > lpr -o number-up=2 -o Duplex=DuplexNoTumble file.ps
          >
          > I guess I'll just have to add a bash alias
          >
          > alias lpr="lpr -l"
          >
          > or something. As yet I've not needed this on Debian Squeeze.

          That should work fine. I've have to add an Emacs alias:

          alias emacs='emacs -nw '

          ever since X11 support was added which I really don't need for 99.99%
          of my usage.

          Several other printing matters:

          1. I don't know if you recall the several articles I posted about the
          enscript program for printing; I use enscript very heavily; see:

          <http://tech.groups.yahoo.com/group/linux/message/58744>

          <http://tech.groups.yahoo.com/group/linux/message/59166>

          and this one with better examples and usage:

          <http://tech.groups.yahoo.com/group/linux/message/60395> March 2012

          2. I grabbed the source RPMs from RedHat for RHEL and CentOS of CUPS
          along with the sources at <http://www.cups.org/software.php> along
          with my source archives going back to the beginning.

          A quick perusal shows that what most, if not all, distros are
          foisting on their users as "CUPS" is a poor, stripped-down version
          of the real thing and w-a-y out of date. Quick preview:

          10043529 cups-1.1.23-source.tar.gz Before Apple bought it
          4616188 cups-1.4.2-44.el6_2.3.src.rpm RHEL/CentOS today
          5448006 cups-1.4.8-source.tar.gz one OLDER version
          10590059 cups-1.5.2-source.tar.gz early 2012 version cups.org
          10590389 cups-1.5.3-source.tar.gz cups.org today 3-JUNE-2012

          Note that a "full" tar.gz is inside an RPM along with some 100+
          patches, and yet the RPM for RHEL and CentOS is smaller than all
          the versions of CUPS I could find.

          ~V~E~R~Y~ interesting (and suspicious) and I'll examine this
          further later this week; I'm busy now with urgent personal stuff.

          If anyone wants to examine the contents of an RPM or DEB without
          actually "installing" it on one's system, see:

          <http://tech.groups.yahoo.com/group/linux/message/60510>
          or
          <http://tech.groups.yahoo.com/group/linux/message/60643>
          or
          <http://www.g-loaded.eu/2008/01/28/how-to-extract-rpm-or-deb-packages/>
        • thad_floryan
          ... Though both alias examples above are OK, there is a difference between hard and soft quotes which is why I, out of habit, always use hard quotes for most
          Message 4 of 9 , Jun 3, 2012
          • 0 Attachment
            --- In linux@yahoogroups.com, "thad_floryan" <thad@...> wrote:
            > --- In linux@yahoogroups.com, ed <ed@> wrote:
            > > [...]
            > > For what it's worth I frequently print to file and
            > > then use
            > >
            > > lpr -o number-up=2 -o Duplex=DuplexNoTumble file.ps
            > >
            > > I guess I'll just have to add a bash alias
            > >
            > > alias lpr="lpr -l"
            > >
            > > or something. As yet I've not needed this on Debian Squeeze.
            >
            > That should work fine. I've have to add an Emacs alias:
            >
            > alias emacs='emacs -nw '
            > [...]

            Though both alias examples above are OK, there is a difference between
            hard and soft quotes which is why I, out of habit, always use hard
            quotes for most bash items unless I want shell expansion to occur.

            A hard quote (') protects everything inside it.

            A soft quote (") permits certain things (e.g., shell variables) to be
            expanded by the shell.

            Quotes toggle, so an example of disabling quoting for a part of an
            expression is:

            'stuff and 'unquoted stuff' more quoted stuff'
          • thad_floryan
            Another oddity of [RHEL s/CentOS ] CUPS: procyon bash 2715/2717 pwd /etc/cups procyon bash 2715/2717 ll total 56 -rw-------. 1 root lp 128 Mar 19 22:29
            Message 5 of 9 , Jun 3, 2012
            • 0 Attachment
              Another oddity of [RHEL's/CentOS'] CUPS:

              procyon bash 2715/2717> pwd
              /etc/cups
              procyon bash 2715/2717> ll
              total 56
              -rw-------. 1 root lp 128 Mar 19 22:29 classes.conf
              -rw-------. 1 root lp 0 Dec 7 14:35 classes.conf.O
              [...]
              -rw-r-----. 1 root lp 2947 Mar 19 22:34 cupsd.conf
              -rw-r-----. 1 root lp 4064 Dec 7 14:35 cupsd.conf.O
              [...]
              -rw------- 1 root lp 1360 Jun 3 01:12 printers.conf
              -rw------- 1 root lp 1360 Jun 2 21:18 printers.conf.O
              [...]
              -rw-r----- 1 root lp 110 Jun 3 16:44 subscriptions.conf
              -rw-r----- 1 root lp 392 Jun 3 01:12 subscriptions.conf.O

              Think those ".O" suffixes are like logrotated files (e.g., file.0,
              file.1, file.2, file.3, ...)?

              Nope, those ".O" are uppercased "oh", not zero.

              And, of course, no documentation as to why the "oh" suffix.

              :-)
            • ed
              ... One of the things I dislike about logrotate is that although the format YYYY-MM-DD normally suffices it doesn t support %H or %k, so normally I end up
              Message 6 of 9 , Jun 4, 2012
              • 0 Attachment
                On Mon, Jun 04, 2012 at 01:40:41AM -0000, thad_floryan wrote:
                > [...]
                > -rw-r----- 1 root lp 110 Jun 3 16:44 subscriptions.conf
                > -rw-r----- 1 root lp 392 Jun 3 01:12 subscriptions.conf.O
                >
                > Think those ".O" suffixes are like logrotated files (e.g., file.0,
                > file.1, file.2, file.3, ...)?
                >
                > Nope, those ".O" are uppercased "oh", not zero.
                >
                > And, of course, no documentation as to why the "oh" suffix.
                >
                > :-)

                One of the things I dislike about logrotate is that although the format
                YYYY-MM-DD normally suffices it doesn't support %H or %k, so normally I
                end up setting dateformat to -%Y%m%d-%s. Compromises.

                --
                Best regards,
                Ed http://www.s5h.net/



                [Non-text portions of this message have been removed]
              • thad_floryan
                ... Heh! I sure dated [no pun] myself; I just now looked in CentOS /var/log and I see the logs are suffixed -YYYYMMDD and not .0, .1, ... . Wonder when
                Message 7 of 9 , Jun 4, 2012
                • 0 Attachment
                  --- In linux@yahoogroups.com, ed <ed@...> wrote:
                  >
                  > On Mon, Jun 04, 2012 at 01:40:41AM -0000, thad_floryan wrote:
                  > > [...]
                  > > -rw-r----- 1 root lp 110 Jun 3 16:44 subscriptions.conf
                  > > -rw-r----- 1 root lp 392 Jun 3 01:12 subscriptions.conf.O
                  > >
                  > > Think those ".O" suffixes are like logrotated files (e.g., file.0,
                  > > file.1, file.2, file.3, ...)?
                  > >
                  > > Nope, those ".O" are uppercased "oh", not zero.
                  > >
                  > > And, of course, no documentation as to why the "oh" suffix.
                  >
                  > One of the things I dislike about logrotate is that although the
                  > format YYYY-MM-DD normally suffices it doesn't support %H or %k, s
                  > normally I end up setting dateformat to -%Y%m%d-%s. Compromises.

                  Heh!

                  I sure "dated" [no pun] myself; I just now looked in CentOS' /var/log
                  and I see the logs are suffixed "-YYYYMMDD" and not ".0, .1, ...".

                  Wonder when that changed? I haven't had much need to examine logs for
                  a long time now since all my systems are operating fine.

                  FWIW, I included a ".0, .1, ..." logrotate-like sequence at the end
                  of my makehosts script (note this is a [minor] bug fix) [20 KB tar]:

                  <http://tech.groups.yahoo.com/group/linux/files/makehosts_V2.01.tar>
                Your message has been successfully submitted and would be delivered to recipients shortly.