On 11/02/14 10:23, Pierre Neidhardt wrote: > 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. >
That does not seem a bad option. A
