norm@dad.org writes:
Ken Hornstein <kenh@pobox.com> writes:But after the scan is complete and before I do the rmm, the script might have put a new message in +inbox, which rmm would remove.There aren't _wonderful_ solutions, because this is a higher-level problem; other programs can change the state of your inbox between commands. Unless you want to do something like Kevin Cosgrove suggested, this is fundamental to your design. You could do some higher-level locking where you prevent your script from running while you read your inbox.I solved my particular problem by realizing that inc works fine when I point it to a file containing just one message and no message dividers. But it does illustrate what I think might be a more fundamental problem with nmh: there is no way for that a user-written script can participate in nmh's internal locking mechanism
Access to internal locking mechanisms would be nice. A related thing that would be nice would be if commands would have flags not to modify state. An example is inc -nochangecur, but I want one that goes further than this, refraining from modifying the context and the cur sequence. norm@dad.org writes:
So I wonder if there is some way that this problem could be
resolved. Would it be very hard to implement a couple of new nmh commands?
Maybe something like this:
nmhlock [ -timeout milliseconds] (returns a token in stdout)
nmhunlock token
Norman Shapiro
Having used nmh but not having read the relevant source code, my impression is that there is not one global lock; rather, there is a separate lock for each mbox file, for the context file, and for each .mh_sequences file. Would someone expound on this? Here are some things I do instead of using the internal locks. For interactive commands, I know not to run multiple conflicting programs at once. I fetch mails to an mbox regularly with getmail and cron, (Even better is to have them mailed to the host you are running nmh on, but that is hard because mailers have become so incorrectly picky about how the receiving server should act.) and then I can quickly load them with inc whenever I want to view new mails. In some cases I check for running user processes instead of a lock. I figure, if I am not logged in, some things may be okay, even though there is still a race condition. I use this for deciding whether it's okay to print out my emails and remove them from the Unseen-Sequence. See ejmejl rprint.in, attached or at this address: https://krabben.twilightparadox.com/fossil/ejmejl/artifact/7ef31229d55087eb When simultaneously executed commands promise to keep to separate folders, I create a fake HOME directory. This is how I use nmh as a contacts manager. See ch lib/ch/init, attached or at this address: https://krabben.twilightparadox.com/fossil/ch/artifact/995b419bf1629c6f When two programs might using the same folder but one only reads, I tried setting the .mh_sequences mode to 640 and having another user access the folder, but I think the file got modified anyway. I guessed the program might have used setuid, but I didn't figure out why that happened. Another possibility in this case would be to symlink all of the messages to a different folder with a different .mh_sequences file. I missed the suggestion of Kevin Cosgrove. Could you refer me to that? With Appreciation, Krullen Van De Trap
rprint.in
Description: rprint.in
init
Description: init