Stupid Mofo Mutt

I'm still growling on this one... I send CLI email all the damn time via Linux or OSX, either with the output of a cron script or something along the lines of:

$ cat /var/log/maillog | mail -s root

or

$ mail root < /var/log/maillog

Works fine- no worries. But this morning I needed to send some larger files via attachment- and they were pretty huge, ~30megs and getting them there another way wasn't an option, so something like:

$ uuencode -m fulllogs.tar.gz - > fulllogs.tar.gz.uu
$ mail root < fulllogs.tar.gz.uu

...just was going to suck, as once it'd been uuencoded it was more like 70+ megs... an email that big wasn't the problem, but I sure as hell didn't want to have to cut and paste all of the text and run it through a decoder and the standard mail doesn't allow for attachments. All I wanted to do was attach the damn thing.

I know mutt has some MIME attachment options, but try as I might I couldn't get it to work, but I did find metamail which fit the bill, which would encode the message, pipe it to splitmail to be broken up and then sent on it's merry way. You can set the size at which it splits... which I didn't at first, and ended up with 360 seperate emails hitting my account to be joined which the mail client choked on. But using something like:

$ metasend -e base64 -S 1000000 -f fulllogs.tar.gz

...broke it up into less pieces (with each individual file being much larger in bytes) that my mail client (GyazMail, OS 10.2) was able to join them, which brought me to my next hiccup. You can't save the joined email (which is straight forward to join, i'll give them that) but you can double click it and it pulls the file into stuffit expander, which decompresses it. Of course I couldn't find it to save the life of me, but I could see where stuffit said it was supposedly putting the files it'd just untarred. So I quit GyazMail, and did a:

% /usr/libexec/locate.updatedb
% locate fulllogs

...which of course are nowhere to be found. Non-deterred, I did a:

% /usr/libexec/locate.updatedb
% sudo find / -iname "*fulllogs*" -print

...again, no love from the missing files. Fired up GyazMail, went through the process again, minus having to join the files... then did a search. Success! Stuffit was set to decompress the files into the directory in which the archive was stored- which is normally the preferred behavior, as if you double-click on a foo.tar.gz on your ~/Desktop, well, you want the decompressed foo/ to end up on your desktop. Unfortunately GyazMail was storing the mofo's in /private/tmp, and stuff was decompressing to /private/tmp, and when GyazMail quit the temp files associated with it were wiped away... taking the files I wanted with it.

Now I was really mad, as being able to do something like:

$ mutt -s "maillogs" -a "fulllogs.tar.gz" root

...should basically have done what I wanted, but I was getting thrown into some weird screen I couldn't get out of. Spent more time with it... and it turns out I'm just a moron. Since I hadn't specified a body, mutt was throwing me into "interactive mode"... in this case using vi as I hadn't set setenv for anything different. Since I never use vi, and am a pico -w guy when I am editing text via the CLI I didn't realize what I was in or how to get out of it. Turns out all vi was waiting for was "escape + : wq" and I was in the mutt client I expected... hit y, and the message and attachment sent out perfectly. Even worse, all I would have had to have done was a:

$ mutt -s "I Hate Mutt" -a "fulllogs.tar.gz" foo@bar < /dev/null

...would have sent it off perfectly the first time. Pretty stupid for it to have taken 3 hours to get it all sorted out, but I suppose it serves me right for sticking with pico instead of picking up vi which is du jour. Just plain stupid.