Hrvoje Niksic wrote:
> But I wonder if that's overengineering at work.
I don't think so. The overarching concern is to do what's "expected". As you
noted elsewhere, on a Unix system, that means exit(0) in the case of success
-- preferably with exit(meaningful_value) otherwise. As I recall this c
[EMAIL PROTECTED] (Steven M. Schweda) writes:
> I don't want to seem like a chronic complainer (although that might
> be an accurate description), but "return 0" is exactly the wrong thing
> to do.
Wget is a Unix program. Unix programs do return 0 on success.
C does provide EXIT_SUCCESS and EXI
From: Hrvoje Niksic <[EMAIL PROTECTED]>
> "Tony Lewis" <[EMAIL PROTECTED]> writes:
> > It seems to me that the easiest way to deal with exit codes is to have a
> > single function to set the exit code. For example:
> >
> > setexitcode(WGET_EXIT_SUCCESS);
> > or
> > setexitcode(WGET_EXIT_QUOTA
"Tony Lewis" <[EMAIL PROTECTED]> writes:
> Steven M. Schweda wrote:
>
>> Having the exit codes defined in a central location would make it easy
>> to adapt them as needed. Having to search the code for every instance
>> of "return 1" or "exit(2)" would make it too complicated.
>
> It seems to me
Steven M. Schweda wrote:
> Having the exit codes defined in a central location would make it easy
> to adapt them as needed. Having to search the code for every instance
> of "return 1" or "exit(2)" would make it too complicated.
It seems to me that the easiest way to deal with exit codes is to
Mauro Tortonesi <[EMAIL PROTECTED]> writes:
> yes, but i was thinking to define wget specific error codes.
I wouldn't object to those. The scripting people might find them
useful.
Alle 18:06, lunedì 19 settembre 2005, Hrvoje Niksic ha scritto:
> Mauro Tortonesi <[EMAIL PROTECTED]> writes:
> > mmh, i don't understand why we should use VMS-specific values in
> > wget.
>
> The closest Unix has to offer are these BSD-specific values which few
> programs use:
>
> /*
> * SYSEXIT
From: Mauro Tortonesi <[EMAIL PROTECTED]>
> >Ideally, the values used could be defined in some central location,
> > allowing convenient replacement with suitable VMS-specific values when
> > the time comes. (Naturally, _all_ exit() calls and/or return statements
> > should use one of the pre
Mauro Tortonesi <[EMAIL PROTECTED]> writes:
> mmh, i don't understand why we should use VMS-specific values in
> wget.
The closest Unix has to offer are these BSD-specific values which few
programs use:
/*
* SYSEXITS.H -- Exit status codes for system programs.
*
* This include file atte
Alle 09:06, sabato 17 settembre 2005, Steven M. Schweda ha scritto:
>I suppose that it's a waste of time and space to point this out here,
> but native VMS status codes include a severity field (the low three
> bits), with popular values being (from STSDEF.H):
>
> #define STS$K_WARNING 0
I suppose that it's a waste of time and space to point this out here,
but native VMS status codes include a severity field (the low three
bits), with popular values being (from STSDEF.H):
#define STS$K_WARNING 0 /* WARNING */
#define STS$K_SUCCESS 1
Alle 18:58, mercoledì 14 settembre 2005, Hrvoje Niksic ha scritto:
> Owen Cliffe <[EMAIL PROTECTED]> writes:
> > Is there a good reason why retrieve tree doesn't just return the
> > status of the last failed operation on failure?
>
> The original reason (which I don't claim to be "good") is because
Owen Cliffe <[EMAIL PROTECTED]> writes:
> Is there a good reason why retrieve tree doesn't just return the
> status of the last failed operation on failure?
The original reason (which I don't claim to be "good") is because Wget
doesn't stop upon on error, it continues. Because of this returning
I'm not sure if this is a bug or a feature, but with recursive
operation, if a get fails and retrieve_tree bails out then no sensible
error codes are returned to main.c (errors are only passed up if the
user's quota was full, the URL was invalid or there was a write error)
so retrieve_tree always r
14 matches
Mail list logo
