(BWDIC!) ~^: use shell-style expansion for arguments (Ralph Keller)..
commitbdf61d26cd15ddec46cc5912dd0cbb9f34ea2f20
authorSteffen Nurpmeso <steffen@sdaoden.eu>
Fri, 29 Nov 2019 23:42:19 +0000 (30 00:42 +0100)
committerSteffen Nurpmeso <steffen@sdaoden.eu>
Sun, 29 Dec 2019 20:28:50 +0000 (29 21:28 +0100)
treeb0a2ad3b3fbf3e48146168caa8f45d20914a56de
parentdc05b19c1efe2ae59debc982abd79549bcf55652
(BWDIC!) ~^: use shell-style expansion for arguments (Ralph Keller)..

Indeed we handled `~^' and `digmsg' differently, but furthermore
turned the shell-parsed data of the latter into whitespace
separated data, which made it impossible to (gracefully, or at
all!) use e.g. attachments with whitespace in their names.

So make this backward incompatible change which possibly hurts
noone, and use the powers of shell quoting to support it all,
including leading and trailing whitespace in arguments.

This increases the interaction protocol version number of
*on-compose-splice* to "0 0 2", as from now on we also quote the
output, since consumation of it via `read' (or read(1)) would $ifs
($IFS) normalize the input anyway.  All that could be done would
be (for ourselves):

  defined x {
    set ifs=
    read vany
    unset ifs
    vpospar set $vany
    # And now assign the desired real fields
    set status=$1 bla=$2 etc
  }

That really is sick!  So instead i also have introduced the
`readsh' command which works like `read' but splits fields at
shell token boundaries.  That commit happened much later than
this, later often rebased, one, though.
Anyway, now you can do from a *on-compose-splice*

  echo '~^header show subject'; read stat name; readsh sub; read i

There would be better examples.

Not that i really like it, but like this leading and trailing
whitespace, intervening whitespace, and whatever else can be
expressed on the input and output side exactly and reproduceably.
mx-config.h
mx-test.sh
nail.1
src/mx/cmd-tab.h
src/mx/dig-msg.c