[PATCH 1 of 1] acl: skip unneeded lines in hg output

Cameron Simpson cs at zip.com.au
Tue May 29 19:29:01 CDT 2012


On 30May2012 01:55, Mads Kiilerich <mads at kiilerich.com> wrote:
| Cameron Simpson wrote, On 05/30/2012 01:14 AM:
| > On a purely stylistic note, I prefer to write this kind of thing thus:
| >
| >    sed -e '
| >      /^files:/d
| >      /^bundling:/d
| >      /^changesets:/d
| >      /^manifests:/d
| >      /^searching for changes/d
| >      /^all remote heads known locally/d
| >      /^invalidating branch cache/d
| >      '
| 
| Are sure that style _really_ is cross platform - also to dinosaur *nix 
| and os/x?

To dinosaur *NIX, yes. I grew up on V7. OS/X (MacOSX, yes?) of course!
It's BSD derived, which is V7 derived! I'm using OS/X right now,
actually.

| > There are a few problems with this.
| 
| This is 'just' a test and doesn't have to be as stable and 
| well-engineered as normal shell scripts used in production on arbitrary 
| input. Keeping it minimal and as simple as possible (and perhaps even 
| simpler than that) is also important.

Perhaps, but gratuitous 2>&1 is always cause for concern, and the loss
of exit status can easily be an issue in general.

It is easy enough to bundle the core logic from something like filter_fd
into a shell function and then use it clearly and expressively and
have correct/reliable behaviour in general. If one does a lot of this
output tidying then you end up using such a utility function a fair bit;
I've always found it better to write something of wide applicability
carefully once and them use it in favour of a simplistic but buggy idiom,
especially if the resulting idion is still readable.

| You might however be right in this case - I don't know.

elifarley will be well familiar with the use case; let's see what his
opinion is.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Mine is not to wonder why, Mine is but to look and say 'Here We Go Again...'
        - Blaine Hufnagle, <shadow at pro-haven.cts.com>, DoD#7192


More information about the Mercurial-devel mailing list