On Mon, 02 Apr 2012 14:43:16 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote: > So what if we instead modified the top level binary ("notmuch") to: > > * add an option to specify that commands are to be processed from stdin > (--batch) > > * when in batch mode the db is opened once at the beginning and locked > > * commands are processed from stdin in the exact same form they are > specified on the command line ("tag +foo -- from:bar", "search > tag:foo", etc.). > > * db is closed when EOF is reached. > > That seems like it would be a generally much cleaner interface, and much > more flexible. Yes, it's more flexible, but what are the real benefits of such flexibility? What other commands than tag/restore would truly benefit from this? I might add that nobody has asked for such flexibility. As to the cleanliness of the interface, all is well as long as no characters needing escaping are used. With them, things get hairy. On the command line, the shell provides the necessary escaping and quoting mechanisms, and parsing to subcommand argv. I think it would be confusing to require %NN style hex escaping on the command line where shell mechanisms can be used, but also it would be a lot of work to duplicate the shell escaping and quoting mechanisms to the stdin parsing. For simplicity, I'd use hex escaping for stdin, and leave the command line to the shell. Finally, I'm not sure how the config and database open/close could be cleanly duplicated in top level "notmuch" and the subcommands. Should there be logic in the subcommands not to open the config/database if they're already opened in top level? All of notmuch cli should also be reworked to pass the config and database on to the subcommands. Not all the commands need to open the database in read/write mode, and some commands don't need to open the database at all, so it would not make sense to move config/database open/close to top level completely. In summary, I don't see enough value in this to put all the work required into it. I think it's way more trouble than it's worth. BR, Jani.