add new shell command % replacement implementation

[frasertweedale]

Add new command % replacement machinery.

The new approach treats shell command replacement separately from mailcap file parsing.
That is, the command fields in the mailcap file are to be treated as opaque strings during
parsing and in the primary data type. Then this new machinery is used to take that opaque
string, and perform % substitution.

The substitutions are provided via the ShellCommandReplacementActions m record type.
m is some possibly-effectful context (e.g. IO). prepCommand caches results of command
replacement actions. The same replacement string occurring multiple times in the command
string does not result in the action being executed multiple times. See (or try for yourself)
the following example:

λ> let actions = ShellCommandReplacementActions ("temp.dat" <$ putStrLn "hello") undefined undefined undefined (pure . Just)
λ> prepCommand "cat \\%s %s %s | lynx -dump -stdin %{boundary}" actions
hello
Right (ShellCommand NoStdin ["temp.dat","temp.dat"] "cat %s temp.dat temp.dat | lynx -dump -stdin boundary")

The result data type ShellCommand contains:

• the command string with % substitutions applied
• a flag indicating whether or not to send the message body to the subprocess stdin
• a [FilePath] arising from %s and %F replacements. This is intended to assist cleanup (removal of temp files). Perhaps it could be a Set Filepath instead.

From purebred point of view, it would be necessary to construct the ShellCommandReplacementActions that return
properties of the MIMEMessage (e.g. Content-Type or number of sub-parts), write body to temp files, etc.

There are some TODOs. I also want to switch purebred-mailcap to depend on purebred-email and use the ContentType type from there.

Feedback much appreciated!

[romanofski]

I don't have much to offer in terms of whether this is heading in the right way. It certainly is heading in the right way than since I wouldn't have anything other to propose.

Would this deprecate or changeData.RFC1524.ViewCommand? As in, instead of parsing it as a template, we simply just parse the template as a ByteString for Command do then parse further?

[frasertweedale]

Would this deprecate or changeData.RFC1524.ViewCommand? As in, instead of parsing it as a template, we simply just parse the template as a ByteString for Command do then parse further?

Yes, it will replace ViewCommand, when it comes to integrate this work.