Phil, Tim,
I've checked in revised smartd.8 and smartd.conf.5 files into CVS. Please
have a look at these to see how I am proposing changing the -m and -M exec
syntax.
Note: I have not yet modified the code to accomodate this, but will do so
unless I hear strong objections.
Phil, if we go this route I suggest backing out the "double
quote" interpretation version of strtok(). I'd also be grateful for your
help in modifying the error messages for -m (since now the argument is
optional) and -M exec.
-m (with no ADDRESS) argument should ONLY give an error and exit if
-M exec PATH is absent.
-M exec PATH should give an error and exit if PATH is not a single word
(with the standard definition of white space).
Cheers,
Bruce
On Fri, 31 Jan 2003, Bruce Allen wrote:
> Hi Tim, Phil,
>
> I spent some time testing my code this morning and immediately discovered
> two nasty things:
>
> (1) There is NO platform independent way to put double quotes (") into an
> nroff/troff document. Writing man pages with double quotes is very
> hard to do. When I displayed my man pages, some essential double
> quotes were missing.
>
> (2) The implementation of smartd.c that I checked into CVS last night
> is 'hard to use' when one tries putting a little script into the -M
> exec argument because of the way quote and double-quote interpretation
> is done by shells and by the smartd.conf parser.
>
> I thought a bit about some possible solutions. One was the following.
> If the argument to -M exec contains spaces, then enclose it in braces {}.
> The parser could then count open/close brace pairs and terminate at the
> correct closing brace. This makes it easy for users to include double
> quotes into their -M exec arguments.
>
> But after some further thought, I realized that this is actually a
> nightmare. We are not guaranteed about what the users shell will require,
> and there is no guarantee that the braces will be needed in pairs, etc.
> We'd end up producing a utility that could only be used after some
> extensive experimentation on a given system. [We've all done this before,
> having to reverse engineer some utility to try and pass arguments to it
> correctly, etc. Let's not create a similar hassle for our users.]
>
> So I now have a proposal to make things simpler and more reliable:
>
> I think we should require that the argument to -M exec is a path (a single
> "word" with NO embedded spaces). Let's eliminate any double quoting from
> smartd.conf.
>
> The original reason for the double quotes was to allow the imbedding of %s
> (for the drive) and other arguments after the executable. But this is now
> moot. By exporting environment SMARTD_* variables, we give users easy
> access to any of the information that they might need about the device
> path, type, problem, etc.
>
> Also, I have a proposed change to the syntax. I propose that we make the
> -m Directive mandatory. There will be two possible way to invoke it:
>
> (1) -m user@... -M exec /path/to/executable
>
> In this case, we'll run "/path/to/executable" with the mail message on
> stdin, and the command-line arguments:
> -s "$SMARTD_SUBJECT" $SMARTD_MAILER
>
> This is the syntax that will be used when people want to specify
> an alternate path to /bin/mail, for example. Or when they
> want to replace /bin/mail with a customized script, but still want
> trivial access to the mail message that would ordinarily be sent.
>
> (2) -m -M exec /path/to/executable
>
> Note that THERE IS NO ARGUMENT to -m.
>
> In this case we'll run /path/to/executable with nothing on stdin,
> and no command line arguments.
>
> If the user wants to provide command line arguments to their executable,
> they can wrap it in a script if needed.
>
> I think that this would give us a consistent, simple and predictable
> extenral interface. And I think users could work within it, without much
> difficulty. It still allows a three-line solution to the original issue
> that Tim raised.
>
> Comments?
>
> Cheers,
> Bruce
>
>
|