Re: [PATCH] new fmtpipe updates
* On 2007.03.11, in <20070312035724.GC28995@xxxxxxxxxxxxxxxxx>,
* "Brendan Cully" <brendan@xxxxxxxxxx> wrote:
>
> I think I prefer force-quoting or sending the input via stdin. It
> means the receiver has to be a little smarter about parsing, I know,
> but there isn't a different quoting scheme for piped vs non-piped
> format strings. I suspect you could probably get the shell to do the
I might be completely missing your point, so please let me know if
I'm talking oranges to your apples.
Maybe I'm only speaking for myself, but it seems that part of the goal
should be that the filter script can look at parts of the expanded text
separately, as discrete delimited tokens -- not have to anticipate the
expansion and parse the interesting information out of whatever the
format string expands to. This is very hard to do, if the script isn't
specially formulated to know what it's being handed. For example, it's
hard to have a simple utility script that knows how to set an xterm
title to any arbitrary value without knowing what the layout is of the
text it's being handed.
Supporting that goal means that we have to permit arbitrarily many
tokens, whether they're arguments to the program, or separate lines of
input. (I think stdin would work fine, but would pose a homologous
problem.) The question is how to discern within mutt where those
boundaries lie, if the user doesn't say. The present solution is to
assume/require that the user has told mutt about these boundaries, which
is pretty consistent with mutt's other assumptions.
I think a lot of interesting use cases are lost if we always coerce
script input (whether arguments or stdin) to a single field.
Stuffing quotes around every token post-expansion is probably no help,
not what the user intends. Stuffing them around input tokens and then
expanding leads to incorrect expansions. And if you expand each input
token and then surround its individual expansion with quotes, then you
basically get fmtpipe.3.
> I'm also a little nervous about what happens in your second patch
> if people are naive about quoting (though I haven't actually tried
> it). What happens, for instance, if an unquoted %? has spaces in it:
>
> %?M? foo ? bar?
That would be four arguments, and whether it comes out as intended
depends on how the script deals with multiple arguments. (For example,
if the script consists of "echo $@", then it will work fine. If there
are multiple adjacent spaces in the string, it becomes troublesome. And
if the script analyzes arguments separately, there may be other issues.)
To me this feels like "Doctor, it hurts when I do this" -- if
%?M? foo ? bar?
doesn't make your script easy to write, then code it as
'%?M? foo ? bar?'
It's the script's output that really counts; the input is just
how you formulate stuff to make things easiest for your script.
> By the way, it would probably also be good to handle \| at the end of
> a string.
Agreed. I wasn't sure how to go about this non-pathologically, though
(since the end of the string might have \\| as well) without actually
carrying out a full parse. This is where Thomas's suggestion of an
alternate syntax looks appealing....
Still, a special case for '\|' is likely to match all the realistic
situations, even if it's not algorithmically pure.
--
-D. dgc@xxxxxxxxxxxx NSIT University of Chicago