Re: rsync --progress stops completion

[Bart Schaefer <schaefer@brasslantern.com>]

On Sep 19,  1:40pm, Oliver Kiddle wrote:
}
} > _cryptsetup - offers all options when completing after "-", but will
} >  only allow one option to appear on the command line, as if all options
} >  are mutually exclusive.
} 
} I can't reproduce this.

I can't either, now.  It may have had something to do with the set of
options I randomly selected for testing.  Sorry for the false alarm.

} > _bzr - complains to stderr if bzr is not in $path
} > _surfraw - complains to stderr if surfraw is not in $path
} > 
} > The latter two make me think that _call_program should do something
} > with stderr -- probably just throw it away, rather than make every
} > caller add its own redirection.
} 
} Note that a significant number of programs send their --help output to
} stderr. They're easily identified by searching for 2>& if the functions
} need adjusting to avoid breaking them.

Right, but that's an entirely different situation; if the --help output
goes to stder, then 2>&1 has to appear in the 'command' zstyle and in
the arguments passed to _call_program.  I'm talking about "command not
found" sorts of errors, which just garble up ZLE to no good effect.

} _call_program could throw away
} stderr unless something like -e is passed. But should -e imply 2>&1?

No, this can't work.  _call_program runs an "eval" on the value of the
"command" zstyle in preference to its argument list, so it has no way
of knowing whether it's appropriate to insert "2>&1".

On the other hand its silly for every single use of _call_program that
*does not* need 2>&1 to have to use 2>/dev/null.

There are 229 uses of _call_program in the completion tree:
  16 redirect stderr to stdout
 107 redirect stderr to /dev/null
 106 do not redirect stderr at all

I'm guessing that all of those latter 106 *ought to* use 2>/dev/null,
because if they needed 2>&1 they'd be broken already.

If nearly half of all functions are getting this wrong, and 90%+ of
all functions need a certain behavior, that behavior probably should
be the default, don't you think?

} The advantage of an explicit 2>/dev/null is everyone knows what it does
} without checking the manual.

An explicit 2>/dev/null where?  In the completion function use of
_call_program?  Except that anyone looking at function source as an
example for a new function has a 50/50 chance of choosing the wrong
example, as things currently stand.

(One could argue that the whole completion system should be capturing
stderr somewhere and showing it to the user in a controlled way rather
than letting it scramble the display, but that's a larger issue.)