Re: [PATCH] Use exit 1 instead of die when req_Root fails.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 17, 2007 at 11:16:34 -0400, Brian Gernhardt wrote:
>
> On Oct 17, 2007, at 10:39 AM, Morten Welinder wrote:
>
>>>  made it into your repo.  It fixes test failures on my machine that have
>>>  been plauging me for months.
>>
>> That sounds more like a reason to fix the test.  "die" is the perl
>> standard way of reporting an error.  It will print the error message
>> on stderr, not on stdout like your version does.
>>
>> IMHO, of course.
>
> The problem is that die can exit with varying exit codes, and exit codes >= 
> 128 make the test suite assume something has gone wrong with the test.  In 
> particular, because $! (errcode) and $? (previous shell command return) are 
> both 0, it returns 255.  Or at least that's how it works out on my system.  
> I'm not sure why it doesn't do that on others.
>
> But the test is expecting a failure here and it appears to be failing in 
> the correct way, just with an error code test-lib.sh doesn't like.  I asked 
> on list the best way to fix it and Frank Lichtenheld said (and nobody 
> objected until now) that this was the best way to fix it.
>
> Also, the not printing on STRERR is identical to another section of code 
> just below mine:
>
>>     unless ($line eq 'anonymous') {
>>        print "E Only anonymous user allowed via pserver\n";
>>        print "I HATE YOU\n";
>>        exit 1;
>>     }
>
> However, amending my patch to print to STDERR is not difficult.

Hm. There are two kinds of errors in git-cvsserver and they should be handled
differently.

If the error is an invalid request (like the quoted one), there should be
normal print, to STDOUT, starting with "E", because it's an error message
that should be sent to the client.

On the other hand if the error is internal error in the script or it's
configuration, than the error should probably be reported via die, *without*
E at the begining (it will be prefixed with location anyway). Such message
will probably end up in the log rather than sent to the client.

-- 
						 Jan 'Bulb' Hudec <bulb@xxxxxx>

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux