On Sun, Oct 5, 2014 at 5:05 PM, David Mason <dma...@ryerson.ca> wrote:
> In the interests of getting into the code a bit, I looked at > implementing this. Making it truly a quiet option was going to > require fairly major surgery, but after a bit of thought, I realized > that all I really needed was the exit status. I thought of making > update always exit with this status (a 1-line change), but I was > worried about legacy issues so I added that with a switch (patch > attached - 1 line of code beyond declaring and parsing the switch). > So instead of ``fossil update -q" I would write ``fossil update -s -n > >/dev/null". I think this is better as it's more incremental and also > more orthogonal. > Gotta love users who provide patches :). + if ( statusFlag ) fossil_exit(nUpdate==0); > } > As you mention, there "might" be legacy issues pending there, but if there are, none of them are immediately obvious to me. The "praise" command says Andy B. has touched that code more often than anyone but Richard, so i'd be interested in hearing his opinion of it. It still seems horribly inefficient, though, considering all the db-level work it does there, knowing it's going to roll back the transaction. Another option comes to mind which would, i think, provide a one-call solution and might avoid major surgery: the ability to squelch output at the app level, such that fossil_print() and friends become no-ops when called when the squelch flag is set. For example (haven't tried this, just looked over the code): in main.c, (struct Global), add an integer member called disableOutput (it will be memset to 0 at startup, so use disableOutput instead of enableOutput). In fossil_print() (and similar output routines), check for that flag, doing nothing if it has a truthy value. In (fossil update), set that flag if --quiet is used. The question then becomes, "do we squelch error messages, too?" (And, if "no," can we separate that output without more notable surgery. Initial brief analysis suggests that it wouldn't be too much work.) Care to take a crack at such a patch? The major funcs which would need a check for the flag are fossil_print() and (if error messages should also be hidden) fossil_fatal(). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
