nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nmh-workers] mhlist output format


From: Paul Fox
Subject: [Nmh-workers] mhlist output format
Date: Fri, 18 Apr 2014 12:07:49 -0400

in trying to adopt better habits in mime-world, i've been writing a
small interactive "what should i do with this attachment?" script for
myself.

first question:  am i correct that mhlist is the only way to
dump the property tree of a MIME message?

what i've found is that currently mhlist's output is very hard for a
script to use, since the output is a bit too free-form:

$ mhlist -verbose -disposition cur
 msg part  type/subtype              size description
   3       multipart/mixed           385K
             
boundary="_004_EA08D62AB2897A468B9CEADFB1D8A15F14D79AB9MAILBX02quantac_"
    1     multipart/alternative     5438
             
boundary="_000_EA08D62AB2897A468B9CEADFB1D8A15F14D79AB9MAILBX02quantac_"
    1.1   text/html                 4548
             charset="big5"
    1.2   text/plain                 144
             charset="big5"
    2     application/x-zip-compre  281K Battery Test  Result.zip
             name="Battery Test  Result.zip"
             disposition "attachment"
               filename="Battery Test  Result.zip"
               size="288054"
               creation-date="Thu, 11 Jul 2013 05:23:35 GMT"
               modification-date="Thu, 11 Jul 2013 05:23:35 GMT"


so i experimented a bit, and added a -script option to mhlist which
changes the above output as below.  differences are that the leading
columns always contain at least a placeholder value, the content type
(and some other) fields are no longer truncated arbitrarily, and the
'=' separator that's present on some (but not all) parameters is
eliminated.  the presence/absence of double-quotes probably still needs
cleaning up:

$ mhlist -script -verbose -disposition cur
 msg part  type/subtype              size description
   3 -     multipart/mixed           385K
  -  -       boundary 
"_004_EA08D62AB2897A468B9CEADFB1D8A15F14D79AB9MAILBX02quantac_"
  -  1     multipart/alternative     5438
  -  -       boundary 
"_000_EA08D62AB2897A468B9CEADFB1D8A15F14D79AB9MAILBX02quantac_"
  -  1.1   text/html                 4548
  -  -       charset "big5"
  -  1.2   text/plain                 144
  -  -       charset "big5"
  -  2     application/x-zip-compressed  281K Battery Test  Result.zip
  -  -       name "Battery Test  Result.zip"
  -  -       disposition "attachment"
  -  -         filename "Battery Test  Result.zip"
  -  -         size "288054"
  -  -         creation-date "Thu, 11 Jul 2013 05:23:35 GMT"
  -  -         modification-date "Thu, 11 Jul 2013 05:23:35 GMT"


it occurred to me later that perhaps i should simply have started from
the -debug output (trimmed for brevity below), and not bothered with
the careful tweaking of the "real" output.  with the elimination of
the truly debug-only output, and a few more tweaks, this could become
the output of the new -script option instead:

...
  partno "2"
  Content-Type: application/x-zip-compressed; name="Battery Test  Result.zip"
    type    "application"
    subtype "x-zip-compressed"
    comment ""
    magic   ""
    parameters
      name="Battery Test  Result.zip"
    type 0x1 subtype 0x0 params 0x0
    showproc  ""
    termproc  ""
    storeproc ""
  Content-Transfer-Encoding: base64
    transfer encoding 0x1 params 0xeec020
  Content-Description: Battery Test  Result.zip
  Content-Disposition: attachment; filename="Battery Test  Result.zip";         
size=288054; creation-date="Thu, 11 Jul 2013 05:23:35 GMT";     
modification-date="Thu, 11 Jul 2013 05:23:35 GMT"    disposition "attachment"
    disposition parameters
      filename="Battery Test  Result.zip"
      size="288054"
      creation-date="Thu, 11 Jul 2013 05:23:35 GMT"
      modification-date="Thu, 11 Jul 2013 05:23:35 GMT"
    read fp 0x0 file "3" begin 9042 end 398168
    decoded fp 0x0 file "/home/pgf/Mail/mhlistodMZls"


so:  any thoughts on whether this sort of "script readable" output
capability should be added to mhlist?  and, if so, what form should the
output take?  (xml crossed my mind, but that would make it a lot harder
for "simple" scripts to parse.)

paul
----------------------
 paul fox, address@hidden (arlington, ma, where it's 35.6 degrees)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]