On Sat, Apr 17, 2010 at 03:27:21AM -0400, Jeff King wrote:
quoted text
> On Fri, Apr 16, 2010 at 08:29:40PM -0600, Matthew Ogilvie wrote:
> > The whole tradeoff between noise ("{script} syntax OK"), portability
> > (PIPESTATUS is a bashism), or really ugly contortions with redirecting
> > extra file descriptors (to avoid PIPESTATUS) seems to be the biggest
> > downside of the idea behind this patch.
> 
> Why do you need to run it through grep? Doesn't:
> 
>   echo 'use strict; bogosity' >foo.pl
>   perl -wc foo.pl
> 
> properly set the exit code? I get:
> 
>   $ perl -wc foo.pl
>   Bareword "bogosity" not allowed while "strict subs" in use at foo.pl line 1.
>   foo.pl had compilation errors.
>   $ echo $?
>   255

Yes, "perl -cw"'s exit code is always good, but the standard error is
needlessly noisy in the success case:

  $ perl -cw -e 'print "hi\n"'
  -e syntax OK
  $ echo $?
  0

Which then leaves a choice among not-great options:

1. Accept the noise output from make and perl.  If we are willing to
   accept this, then a simpler and/or uncoditional patch would be fine.

2. Filter out the "{scriptName} syntax OK" noise with grep (or sed),
   but then $? is grep's status (not perl's), and you have to go
   through contortions to properly test perl's status:

    2a. Use PIPESTATUS, but this is a non-portable bashism.
        My current version of the patch elects to do this, but
        leaves the check disabled to (hopefully) avoid portability
        issues.  (A second advantage of leaving it disabled [or at
        least disablable] is if someone is in a cross-compile
        environment and the target perl path is different 
        from the build perl path.)

    2b. Use a portable technique that involves echoing the status
        redirected to file descriptor 3, then pulling the status out
        of file descriptor 3 outside the pipeline.  This is frankly
        kind of complicated and hard to read.

So, I take it you would be happy with the noisy output?
Anyone else have an opinion?  If someone knows a cleaner
way to resolve this, or if the group consensus is that we like the
patch's concept but would rather resolve the noisy output some
other way (perhaps just accept it), I could change the patch.

--
Matthew Ogilvie   [mmogilvi_git@miniinfo.net]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html