I'm trying to port a simple automatic downloading script from
Windows to Linux. I run wget from inside a gnome-terminal or an
xterm. If somebody closes the window, wget keeps going,
invisibly, and redirects its output to a log file. This seems
specific to wget, not a general characteristic of th
I consider it a feature. Wget was designed specifically for
downloading in the background; it catches the hangup signal to it
knows not to write to the (now defunct) terminal. The idea is for
downloads in SSH/telnet/modem sessions to keep running if the user is
accidentally disconnected.
If I un
"Hrvoje Niksic" <[EMAIL PROTECTED]> wrote:
my wget (GNU Wget 1.10) on a crux-based system simply truncates the
# and everything after [...]
The part after the "#" in HTTP URLs is what some call a "fragment
identifier". [...]
oh dear - sorry for asking that stupid question - too much "low le
"Martin Koniczek" <[EMAIL PROTECTED]> writes:
>>> in contrast to the faq (http://www.gnu.org/software/wget/faq.html):
>>>
>> [...]
>>
>> The FAQ is very imprecise here with its use of the term "funny
>> characters". [...]
>
> this faq additionally misled me - perhaps just kill the # from the
> "fu
Alle 13:59, domenica 18 settembre 2005, Hrvoje Niksic ha scritto:
> > in contrast to the faq (http://www.gnu.org/software/wget/faq.html):
> >
> > 3.3 How do I download a URL with funny characters in it?
>
> [...]
>
> The FAQ is very imprecise here with its use of the term "funny
> characters". Th
Alle 00:50, sabato 10 settembre 2005, Steven M. Schweda ha scritto:
> A final kit for Wget 1.10.1a for VMS is available in the usual places:
>
> http://antinode.org/dec/sw/wget.html
>
> http://antinode.org/ftp/wget/wget-1_10_1a_vms/
> ftp://antinode.org/wget/wget-1_10_1a_vms/
>
>
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
From: Mauro Tortonesi <[EMAIL PROTECTED]>
> the wget code is going through a major refactoring effort. later on, just
> before releasing wget 2.0, i promise i will re-evaluate your patches and
> merge them if they're not too intrusive.
That would be nice. I believe that the only _very_ intr
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
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
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
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.
Latest version (1.10.1) turns out an UI bug: the thousand separator
(space according to my local settings) displays as "á" (character code
0xA0, see attch.)
Although it does not affect the primary function of WGET, it looks quite
ugly.
Env.: Win2k Pro/Czech (CP852 for console apps, CP1250 for win
"HonzaCh" <[EMAIL PROTECTED]> writes:
> Latest version (1.10.1) turns out an UI bug: the thousand separator
> (space according to my local settings) displays as "á" (character
> code 0xA0, see attch.)
>
> Although it does not affect the primary function of WGET, it looks
> quite ugly.
>
> Env.: Wi
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
"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
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
[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
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
19 matches
Mail list logo
