I can't figure out the right syntax for this. Both approaches seem to
have defects. There are comments in line below.
On Sunday, 11 March 2007 at 23:02, David Champion wrote:
> * 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.
I think you can feed the line into stdin, and then let shell tokenize
it. You can use '' inside the string to assist shell, and then return
something with % at the end if you need to get the padding right, I
guess. I'm no shell programmer, but if you quote things properly in
your variable, you might be able to do something like this:
#!/bin/sh
dequoted () {
i=1
while [ $# -gt 0 ]
do
echo $i: $1
shift
i=$(($i + 1))
done
}
read line
eval dequoted $line
% echo 'foo "foo bar" baz' | ./tmp.sh
1: foo
2: foo bar
3: baz
I think that resembles fmtpipe.3, without the danger of losing %? (see
below)
> 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.
That doesn't sound quite right. If the arguments are unquoted, mutt
will no longer do its own if-else expansion, because each term is
being fed to the formatter independently. So you're really back to
doing your own quoting. I tried running my regular status_format
through a script that does echo "$@", and unsurprisingly I got a
result like this:
=Lists.mutt-dev (5.1M) [Msgs:1807 New:0? Del:0? Flag:0? Tag:0? Post:0?
Inc:0?] (threads/date)
with some rather strange padding at the end. This seems undesirable to
me at least.
> > 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....
hmm. Right, I guess you'd have to count the consecutive backslashes
before the |. Even means pipe, odd means don't. Ugly.
> Still, a special case for '\|' is likely to match all the realistic
> situations, even if it's not algorithmically pure.
Attachment:
pgpcqlAQcHqeV.pgp
Description: PGP signature