murthy@algron.cs.cornell.edu (Chet Murthy) (05/25/90)
I just started using recursive folders in MH to organize my mail by subject - I have 62 folders as of today. I want to organize them as a tree, with only the folders at the leaves of the tree actually containing messages. So what I want is a way to tell MH to not look for messages in a folder when it has found a subfolder, and not look for folders in folder where it has found a message. Thus, the folders command would only have to look at one file in the directory in order to determine if it (1) should read every file, i.e. every file is a subfolder, or (2) it should just read the directory, to summarize the per-folder data. Is this possible? I have a LOT of mail archived this way. Also, is it possible to get MH to compress/uncompress messages automatically? --chet-- --chet-- murthy@cs.cornell.edu
jdpeek@RODAN.ACS.SYR.EDU (Jerry Peek) (05/25/90)
> ...what I want is a way to > tell MH to not look for messages in a folder when it has found a > subfolder, and not look for folders in folder where it has found a > message... Well, a quick-and-dirty way to do that is by feeding the output of folders to grep -v, like this: % folders | grep -v 'has no messages' it won't show lines for folders that are empty. Count the blanks carefully. BTW, the folder(1) man page under MH6.6 says that: lsproc: Program to list the contents of a folder but the mh-profile(5) man page doesn't list any "lsproc." What is it? (I don't have source code handy.) > Also, is it possible to get MH to compress/uncompress messages > automatically? I wrote a set of shell scripts called "zrefile", "zscan", and "zfolders" that handle compressed "tar" archives of MH messages. I've used them for months now, and they seem to work fine. They're sort of slow, but they sure save a lot of disk space because: - all the messages are glued into one file, so each message doesn't necessarily consume a whole block of disk space - the compression squeezes all the extra padding and crud out of the "tar" file. No guarantees that they'll work for you, but I'd be glad to send a shar file of them to anyone who wants them. --Jerry Peek; Syracuse University Academic Computing Services; Syracuse, NY jdpeek@rodan.acs.syr.edu, JDPEEK@SUNRISE.BITNET +1 315 443-3995