> > - etcpath to searchpath. > > I created a new routine searchpath to replace etcpath. If given > > a filename without leading '/' or '~' it searches the folder > > and all its parents before searching ~/Mail and /etc/nmh. > > While I was writing this into nmh the same feature was also put > > into exmh, but nmh would be a cleaner location? > > Aren't there usability and security concerns with this? Won't some people > suddenly start getting different components files than the ones they expect > if they don't change their .mh_profile to prepend '~/<`mhparam path`>' to > all components filenames? > > I think it'd be safer to check the current directory (but not its parent > tree -- why do you need that?) *last*, with an option to force the > components file in the current directory by using './'..., just like with > $PATHs. With current directory you mean current folder, or really current directory? I agree it's probably wise to check for './' and '..' cases as well as '/' and '~'. I need it because I have groups of mailboxes that I treat the same. I have a group of work-related mailboxes that need my work email address in the from header, private mails get a different from. By using a recursive search I only have to have one component file for work or private (To see where I'm coming from, I have 200 mailboxes with 27000 mails, and I like to keep things manageable). Security concerns? The user still gets to see the mail before he sends it, doesn't he? The routine only searches in the user's mailfolders. I can't imagine any security concerns, but then I do have to admit I don't understand all the uses people have for nmh like public folders. Usability concerns? If the user has files called 'components' in a mailfolder, I think we can assume in 99.99% of the cases that user want to use that file for mails composed from that folder. The recursiveness could be a little trickier. If a user has folders a and a/b, with a components file in a, I can imagine circumstances where he wouldn't want to use that components file from a/b. I still think that won't happen too often. > Frankly, though, you'd increase the chances of the patches getting applied > if the new features were implemented across the board and if you updated the > documentation to reflect the changes (you didn't mention whether or not > you'd done this). That's why I first sent my request for interest to the list. Stuff works satisfactorily for me now. If nobody wanted it, I wouldn't have bothered with documentation and parts that I don't use. I'll split up the searchpath and components changes and flesh them out a bit more, and put them on the list when they work. Thanks for the feedback. Tobias
