Discussion:
Problem with enscript
Add Reply
Dave Horsfall
2018-11-16 00:21:13 UTC
Reply
Permalink
Sierra, latest Macports, GNU Enscript 1.6.6.

Some time ago I discovered that an upgrade (dunno what) had blown away all
my crafted printer definitions, so "enscript" was no longer working; the
error is "lpr: The printer or class does not exist".

I have defined the printer to be "laser-tc" i.e. a laser printer accessed
via the USB port on my Time Capsule, and this has worked for ages.

The "lpr" command itsekf works fine, but when piped from "pr" looks ugly.

Running "enscript -v" shows nothing useful.

I tried to move /usr/bin/lpr aside to replace it with a shell script to
echo its arguments, but:

ozzie:/usr/bin [4]# mv lpr lpr.real
mv: rename lpr to lpr.real: Operation not permitted
ozzie:/usr/bin [5]# cp lpr lpr.real
cp: lpr.real: Operation not permitted

so I guess the file system is protected somehow (even from root!).

If anyone here is using "enscript" can you please tell me how you got it
going? It worked OK here for years, until as I said all my printer
definitions were suddenly blown away (reason unknown).

Thanks.

-- Dave
Ryan Schmidt
2018-11-16 03:17:20 UTC
Reply
Permalink
Post by Dave Horsfall
Sierra, latest Macports, GNU Enscript 1.6.6.
Some time ago I discovered that an upgrade (dunno what) had blown away all my crafted printer definitions, so "enscript" was no longer working; the error is "lpr: The printer or class does not exist".
I have defined the printer to be "laser-tc" i.e. a laser printer accessed via the USB port on my Time Capsule, and this has worked for ages.
The "lpr" command itsekf works fine, but when piped from "pr" looks ugly.
Running "enscript -v" shows nothing useful.
ozzie:/usr/bin [4]# mv lpr lpr.real
mv: rename lpr to lpr.real: Operation not permitted
ozzie:/usr/bin [5]# cp lpr lpr.real
cp: lpr.real: Operation not permitted
so I guess the file system is protected somehow (even from root!).
That's called System Integrity Protection. It's a new macOS feature as of OS X 10.11 El Capitan. You cannot modify files installed by Apple unless you turn SIP off, but you should not do that. It is a protection against malware.
Post by Dave Horsfall
If anyone here is using "enscript" can you please tell me how you got it going? It worked OK here for years, until as I said all my printer definitions were suddenly blown away (reason unknown).
Dave Horsfall
2018-11-16 23:20:44 UTC
Reply
Permalink
Post by Ryan Schmidt
That's called System Integrity Protection. It's a new macOS feature as
of OS X 10.11 El Capitan. You cannot modify files installed by Apple
unless you turn SIP off, but you should not do that. It is a protection
against malware.
So how do I turn it off? I've been using Unix for 40+ years, and I think
I know what I'm doing: I want to see how "enscript" is calling "lpr" so
that I can see what is broken ("lpr" works fine by itself). I suppose
that I can always futz around with $PATH, but I won't be surprised if it
doesn't work ("/usr/bin/lpr" could be hard-wired for all I know) and it'll
have to wait until later.

Let me guess: sign off (losing all my sessions) and sign on again as
"root" (which I've had to do to restore files outside my home directory
with Time Machine)? Install my shim, sign on again as myself, see what's
wrong, sign on again as "root" to undo what I did to debug a problem, then
sign on again, repeating as necessary? Why not just let me modify the
root file system, and take the responsibility for it?

Sometimes I think that Apple goes too far in protecting users from
themselves...

-- Dave
Ryan Schmidt
2018-11-17 00:14:12 UTC
Reply
Permalink
Post by Ryan Schmidt
That's called System Integrity Protection. It's a new macOS feature as of OS X 10.11 El Capitan. You cannot modify files installed by Apple unless you turn SIP off, but you should not do that. It is a protection against malware.
So how do I turn it off? I've been using Unix for 40+ years, and I think I know what I'm doing: I want to see how "enscript" is calling "lpr" so that I can see what is broken ("lpr" works fine by itself). I suppose that I can always futz around with $PATH, but I won't be surprised if it doesn't work ("/usr/bin/lpr" could be hard-wired for all I know) and it'll have to wait until later.
Let me guess: sign off (losing all my sessions) and sign on again as "root" (which I've had to do to restore files outside my home directory with Time Machine)? Install my shim, sign on again as myself, see what's wrong, sign on again as "root" to undo what I did to debug a problem, then sign on again, repeating as necessary? Why not just let me modify the root file system, and take the responsibility for it?
Sometimes I think that Apple goes too far in protecting users from themselves...
You can of course turn System Integrity Protection off. You can find instructions by searching online. If you turn it off to run your experiment, I strongly recommend turning it on again afterward. SIP is intended to prevent unauthorized modifications to your operating system. This is good protection to have.
Bill Cole
2018-11-17 04:55:00 UTC
Reply
Permalink
Post by Dave Horsfall
Let me guess: sign off (losing all my sessions) and sign on again as
"root" (which I've had to do to restore files outside my home
directory with Time Machine)? Install my shim, sign on again as
myself, see what's wrong, sign on again as "root" to undo what I did
to debug a problem, then sign on again, repeating as necessary?
WORSE.
Rather than just logging in as root, (which you COULD do in a shell,
after all...) you have to reboot into single-user or "Recovery Mode" to
switch it on and off with the 'csrutil' tool.
Post by Dave Horsfall
Why not just let me modify the root file system, and take the
responsibility for it?
It's not about you. It's about rootkits.
Post by Dave Horsfall
Sometimes I think that Apple goes too far in protecting users from
themselves...
Given the prevalence of rootkits as a dominant form of malware in the
modern world, it isn't really Apple just protecting us from ourselves,
it is protecting us from a broad range of possible attacks.
--
Bill Cole
***@scconsult.com or ***@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Loading...