On 14-02-11 10:12:04, Allan McRae wrote:
> On 11/02/14 02:23, Pierre Neidhardt wrote:
> > On 14-02-10 11:06:51, Andrew Gregory wrote:
> >> On 02/09/14 at 07:41pm, Pierre Neidhardt wrote:
> >>> If input cannot be parsed, it is not desirable to output it along other
> >>> valid
> >>> entries. This would make pacsearch output unpredictable.
> >>>
> >>> Signed-off-by: Pierre Neidhardt <[email protected]>
> >>> ---
> >>> contrib/pacsearch.in | 7 ++-----
> >>> 1 file changed, 2 insertions(+), 5 deletions(-)
> >>
> >> -1. pacsearch is a thin pacman wrapper and should not hide output.
> >> Since it doesn't do any real argument parsing, a user can pass an
> >> option that alters pacman's output (-q for instance) and this would
> >> hide all output from the user without giving any indication of an
> >> error.
> >
> > Then I suggest to print a message to stderr instead, since outputing
> > unparseable
> > lines among the regular output can introdcue subtle bugs in programs using
> > pacsearch output.
> >
>
> Do you have an example with unparsable output?
Yes, as aforementioned by Andrew:
pacsearch -q pacman
Here -q is seen as an option, not a package. Same thing with -v, and so on.
Otherwise, we could just add '--' before 'ARGV', this would prevent this issue
and then 'unparseable output' would never happen.
--
Pierre Neidhardt
What good is it if you talk in flowers, and they think in pastry?
-- Ashleigh Brilliant
