At 02:05 2001-12-16 -0500, Don Hammond did say:
dmesg |head -1 may not reliably do what you expect.
... which is why the emitted comment above says "(if discernable)"
foobar, but it seems less than reliable. Isn't uname a standard unix
utility, making it a candidate where portability matters?
I was sort of hoping to determine which specific flavour of *nix (though
the dmesg doesn't emit this on the first line either).
This one's a minor nit, but I'd replace the procmail|fgrep|sed pipeline
that assigns to mymailbox with:
mymailbox=`procmail -v 2>&1 |awk '/system mailbox/ {print $NF}'`
It's one less process, minor (and imprecisely observed) performance
gain, and (possibly most important) one less wrapped line. ;-)
Performance isn't a concern here - this is a diagnostic that might get run
half a dozen times in the process of a user attempting to determine why
their config doesn't work. It isn't going to be run when messages are
received.
Martin McCarthy posted a useful bit for determining the procmail defined
SENDMAIL, and that works equally well for determining the $DEFAULT (which
_is_ what procmail is emitting as the "system mailbox", right?) That
allows the process to skip a post filter altogether. Then, David posted an
eval that just schleps a number of configuration variables all at
once. I'm using that.
As far as reporting permissions in numeric format, the following will do
it. I'm not sure if it's close to what you had in mind,
What I have in mind is something that will report perms in pretty much the
same format as one might set them using chmod, since so many newbies so
obviously don't comprehend the rwx bitmask representation. This would
allow us to say "is the file mode 0600 ?" and not end up with a newbie
response of "huh?"
but it allows you to get rid of the LSCMD contortion.
The LSCMD contortion is to get the long date format (BSD and GNU differ in
options). That is only obtained for consistency and in the offchance that
at some point we'll care about the actual file date on something. -L was
added just to resolve symlinks (generally an issue on the executables, not
the dirs - some program files might be symlinks to where the program file
really resides), and might be removed on a file or two as the script is
revised so that we can determine the intermediate perms.
Since this presumably only
needs to run on *nix and you're already assuming perl is available,
For lack of a consistent way to obtain the FQDN (hostname isn't good for that).
[snip - perl code]
Unfortunatley, this becomes a second file which must be distributed (or a
very long list of continued lines within this script). If used as an
inline eval for perl, we end up in the position of not being able to call
it from multiple places easily. One possibility I guess would be to have
the script emit it as a perl program under /tmp/ and then execute it from
there. Not pretty.
I'll see about mangling it into an inline perl eval to include into the
script and run some tests.
$SENDMAIL -d0 < /dev/null | fgrep -vi "Recipient names"
Note that the pipe through fgrep is merely intended to remove what might be
misinterpreted by someone as an error message.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail