Re: Long lines with postmap

On Sunday, May 09, 2004 at 17:49 CEST,
Wietse Venema <wietse@porcupine.org> wrote:

> I suggest giving the user interface some thought. "-l" for "long"
> neither rings a bell that RFC822 is involved, nor does it ring a
> bell that it controls table lookups.

"-u" for "unfold" would be true to RFC (2)822, but would confuse
since "-f" already is "fold".

> In addition, it would be nice if the code gave consistent
> treatment to:
>=20
> +-------------
> |% postmap -q - maptype:mapname <<EOF
> |some
> | multi-line
> | text
> |EOF
> +-------------
>=20
> and
>=20
> +-------------
> |% postmap -q 'some
> | multi-line
> | text' maptype:mapname
> +-------------

What would be the semantics of the latter case if multiple keys
are specified as input? For example, should the two cases below
be equivalent?

$ cat > /tmp/foo
Subject: A long
subject line
X-Foo: bar
^D
$ postmap -lq "`cat /tmp/foo`" maptype:mapname
$ postmap -lq - maptype:mapname < /tmp/foo

If they should be equivalent, I think postmap should be rewritten
somewhat so that there only is one query function that is used for
both modes, and that the input key-splitting takes place elsewhere.

If they should not be equivalent, what would be the semantics of
the command below?

$ postmap -q 'Subject:
A multi-line header
some other text' maptype:mapname

(Please, slap me with a clue stick if required.)

--=20
Magnus B=E4ck
magnus@dsek.lth.se