On Mar 6, 2021, at 22:46, Jeffrey Walton wrote:
> I'm building Wget 1.21.1 on an old PowerMac with OS X 10.5. Debian
> still lacks a stable image for the G5's, so I keep using Apple's OS X.
>
> $ make
> make all-recursive
> Making all in lib
> make all-am
> ...
> CC
On Sat, Mar 6, 2021 at 10:37 PM Jeffrey Walton wrote:
>
> Hi Everyone,
>
> I'm building Wget 1.21.1 on an Apple M1. Things go well for a while, and then:
>
> % make
> /Library/Developer/CommandLineTools/usr/bin/make all-recursive
> Making all in lib
>
On Sat, Mar 6, 2021 at 10:37 PM Jeffrey Walton wrote:
>
> Hi Everyone,
>
> I'm building Wget 1.21.1 on an Apple M1. Things go well for a while, and then:
>
> % make
> /Library/Developer/CommandLineTools/usr/bin/make all-recursive
> Making all in lib
>
Hello again,
when writing the sed script I finally stumbled upon the bug as there
were much more stylesheets in the original webpage than on the local
directory, and it is really easy to reproduce. I will file a bug via the
official form at savannah.gnu.org.
The problem is, that MediaWiki or at
Hello,
I was able to track the problem down a bit more. I excluded the biggest
part which are the image downloads and played around with downloading
different sets of pages:
The following command downloads pages A-b (about 140 files in total) and
works fine:
wget --recursive --no-clobber
Thanks for clarification! How will wget interpret these CIDR parts of
variable no_proxy?
Will it ignore these parts of the variable?
13.02.2021, 20:31, "Tim Rühsen" :
Hi,
On 07.02.21 19:19, Gi Actor wrote:
Hello!
I've tried searching the archive
On 13.02.21 19:00, Eli Zaretskii wrote:
From: Tim Rühsen
Date: Sat, 13 Feb 2021 18:23:31 +0100
Try without " or leave away the spaces between these and the URL.
(Possibly I am misguided but your mailers line breaks.)
wget --no-check-certificate
> From: Tim Rühsen
> Date: Sat, 13 Feb 2021 18:23:31 +0100
>
> Try without " or leave away the spaces between these and the URL.
> (Possibly I am misguided but your mailers line breaks.)
>
> wget --no-check-certificate
>
Hi,
On 07.02.21 19:19, Gi Actor wrote:
Hello!
I've tried searching the archive but didn't find any recent discussions
about ability to recognize subnet masks in variable "no_proxy" for
avoiding passing traffic through proxy servers.
May I know if anything is planned in
Hi,
Try without " or leave away the spaces between these and the URL.
(Possibly I am misguided but your mailers line breaks.)
wget --no-check-certificate
"https://www.datos.gov.co/api/views/gt2j-8ykr/rows.csv?accessType=DOWNLOAD;
BTW, we don't officially support Windows builds of Wget.
Hi,
this looks like you are using a basic feature of wget. Seeing this fail
is unexpected.
Is your URL ftp or http ?
Which version of wget are you using (wget --version) ?
Regards, Tim
On 09.02.21 17:34, Eitan03 wrote:
Hi,
Instead of rewriting the whole thing I'll just link the overflow
Hello,
Cherise Haywood writes:
> I am trying to download specific .zip files from this website:
> https://www2.census.gov/geo/tiger/TIGER2012/ROADS/
>
> I have used several iterations of wget to yield only the folders (
> directories) being formed, but absolutely no data being downloaded.
>
>
hi team,
Is this mailing list the right address for these issues?
On Fri, Jan 22, 2021 at 11:35 PM Dolev Farhi
wrote:
> hi Wget team!
>
> When making an HTTP GET request with Authorization header, together with
> the follow redirect flag (-L), e.g.:
>
> wget -v --header="Authorization:
Hello Tim,
Tim Rühsen wrote:
> On 25.01.21 17:28, Felix Dietrich wrote:
>> Hello,
>> I noticed that wget does interrupt its --wait between retrieval of
>> multiple files when my terminal window gets resized.
>> the “xsleep” function (in utils.c) only supports the continuation of
>> interrupted
Hi,
On 26.01.21 15:19, Vincent Lefevre wrote:
Hi,
In texi2pod.pl from wget 1.21:
# Change double single quotes to double quotes.
s/''/"/g;
s/``/"/g;
This seems to be done unconditionally. But this is incorrect in
verbatim text, such as
@example
wget -X '' -X
Hi Felix,
On 25.01.21 17:28, Felix Dietrich wrote:
Hello,
I noticed that wget does interrupt its --wait between retrieval of
multiple files when my terminal window gets resized. Reading through
the sources it seems that the “xsleep” function (in utils.c) only
supports the continuation of
On 25.01.21 10:00, wrote:
Dear Sir,
After making without error message, I used the command "make check" to check. There
are 6 items failed as follows. Is there any program on my pc (Red Hat Enterprise
Linux Server release 6.2) absent?
Likely the gnutls-devel package is missing (or
On 2021-01-26 15:19:02 +0100, Vincent Lefevre wrote:
> In texi2pod.pl from wget 1.21:
>
> # Change double single quotes to double quotes.
> s/''/"/g;
> s/``/"/g;
>
> This seems to be done unconditionally. But this is incorrect in
> verbatim text, such as
>
> @example
> wget -X '' -X
Ah, yes, I see that your build uses the flag `--without-included-regex`.
That should probably take care of the build failure I'm seeing. Thanks
for the tip, Ryan.
The header of regex.c says it's part of glibc, though, so it's no
surprise that it leads to build failures on macOS. wget probably
On 1/25/21 1:25 PM, Peter Dyballa wrote:
The configure script of wget 1.21.1 seems to have a bug, which becomes visible
at least on old Mac OS X versions which use old GCC 4.2, see this
report:https://trac.macports.org/ticket/62134. It's my assumption that the
tests for C99 and C11
On 25.01.21 06:40, Carlo Cabrera wrote:
> wget 1.21.1 fails to build on macOS 10.14, 10.15, and 11.1. The build
> fails with a series of errors starting with
>
> In file included from regex.c:74:
> In file included from ./regexec.c:1362:
> ./malloc/dynarray-skeleton.c:195:13:
On Jan 24, 2021, at 23:40, Carlo Cabrera wrote:
> wget 1.21.1 fails to build on macOS 10.14, 10.15, and 11.1. The build
> fails with a series of errors starting with
>
>In file included from regex.c:74:
>In file included from ./regexec.c:1362:
>./malloc/dynarray-skeleton.c:195:13:
> >>> conftest.c:491:23: error: implicit declaration of function 'utime' is
> >>> invalid in C99 [-Werror,-Wimplicit-function-declaration]
> >>> if (!utime ("conftest.tmp/", NULL))
> >>>^
> >>> 1 error generated.
Thanks for the report. Fixed through the
Hi Jeff,
On 17.01.21 10:05, Jeffrey Walton wrote:
Hi Tim/Darshit,
I'm testing Wget2 on Ubuntu 20.04 x86_64 fully patched. I'm catching
this compile error:
make[2]: Entering directory '/home/jwalton/Build-Scripts/wget2/po'
make wget2.pot-update
make[3]: Entering directory
Hi Jeff,
that behavior is not reproducible here.
Could you run that command with '-o out.log' added and check with
echo $?
what the return status is (please report that value) ?
Then attach out.log and the output from 'wget --version'.
Possibly something with cacert.pem (missing or outdated
Hi Ryan,
On 21.01.21 01:46, Ryan Schmidt wrote:
Hi, I'm the maintainer of wget in MacPorts.
Bruno already mentioned last week that during configure, wget 1.21.1 prints
this:
./configure: line 51273: AX_CODE_COVERAGE: command not found
I just wanted to add that this appears to be a result of
On 23.01.21 07:09, Ryan Schmidt wrote:
On Jan 22, 2021, at 16:47, Tim Rühsen wrote:
On 21.01.21 01:34, Ryan Schmidt wrote:
Hi, I'm the maintainer of wget in MacPorts.
In the version of clang included with Xcode 12 and later, implicit declaration
of functions is an error.
During configure,
Hi Bruno,
On 23.01.21 02:44, Bruno Haible wrote:
Hi Tim,
You can use m4_pattern_forbid([AX_]) to guard against such mistakes.
Well, I might be too stubborn for this. Adding it results in
configure:20848: error: possibly undefined macro: INTMAX_MAX
If this token and others are
On Jan 22, 2021, at 16:47, Tim Rühsen wrote:
> On 21.01.21 01:34, Ryan Schmidt wrote:
>> Hi, I'm the maintainer of wget in MacPorts.
>> In the version of clang included with Xcode 12 and later, implicit
>> declaration of functions is an error.
>> During configure, wget 1.12.1 prints this:
>>
Hi Tim,
> > You can use m4_pattern_forbid([AX_]) to guard against such mistakes.
>
> Well, I might be too stubborn for this. Adding it results in
>
> configure:20848: error: possibly undefined macro: INTMAX_MAX
>If this token and others are legitimate, please use m4_pattern_allow.
>
Hi Ryan,
./configure scripts are not made for using -Werror in CFLAGS.
This is documented somewhere but (sorry), I am just too tired to search
for the URL right now.
Regards, Tim
On 21.01.21 01:34, Ryan Schmidt wrote:
Hi, I'm the maintainer of wget in MacPorts.
In the version of clang
Hi Bruno,
On 15.01.21 01:38, Bruno Haible wrote:
The configure script apparently references an undefined macro:
$ ./configure
...
checking for stdint.h... (cached) yes
./configure: line 51273: AX_CODE_COVERAGE: command not found
checking for working mmap... yes
...
You can use
ten by Hrvoje Nikšić .
Currently maintained by Micah Cowan .
Please send bug reports and questions to .
-Original Message-
From: Tim Rühsen
Sent: Saturday, January 16, 2021 1:11 PM
To: Godavarty, Uday (Contractor) ;
bug-wget@gnu.org
Subject: Re: Issue with wget command while down
Hi,
yeah, we are now moving to C11 as our portability (source code) library
'gnulib' did this step. There is plenty of cleanups needed in the code
base. You stepped over a regression introduced during that work.
Could you retry with latest code from the git repo ?
Regards, Tim
On 15.01.21
On Wed, 13 Jan 2021, Peng Yu wrote:
I know the environment variables of http_proxy and https_proxy. But I don't
know whether they can be used for SOCKS proxy or not because the manpage
does not mention any keywords of SOCKS.
To the best of my knowledge, wget doesn't support SOCKS natively
On Thu, Jan 14, 2021 at 12:57 PM Jeffrey Walton wrote:
>
> Hi Tim/Darshit,
>
> Alpine Linx 3.12 has a BusyBox implementation of Wget. It is very
> crippled, and it needs a real Wget installed.
>
> I'm trying to build Wget 1.21/OpenSSL 1.0.2. Wget configure is failing at:
>
> checking for MD5
I know the environment variables of http_proxy and https_proxy. But I
don't know whether they can be used for SOCKS proxy or not because the
manpage does not mention any keywords of SOCKS.
On 1/13/21, Jeffrey Walton wrote:
> On Wed, Jan 13, 2021 at 5:05 PM Peng Yu wrote:
>>
>> Hi,
>>
>> I don't
On Wed, Jan 13, 2021 at 5:05 PM Peng Yu wrote:
>
> Hi,
>
> I don't see where wget support socks proxy or not in the manpage. Does
> wget support SOCKS proxy? If it supports SOCKS, could anybody let me
> know how to use it the command (not by .wgetrc)? Thanks.
Check the Wget manual at gnu.org:
On Tue, Jan 12, 2021 at 10:04 PM Jeffrey Walton wrote:
>
> ...
> I'm catching a autoconf failure during the bootstrap build:
>
> checking for libssl... no
> configure: error: --with-ssl=openssl was given, but SSL is not available.
It looks like autoconf should add:
-lresolv -lsocket
On 09.01.21 12:49, Jeffrey Walton wrote:
On Sat, Jan 9, 2021 at 6:44 AM Tim Rühsen wrote:
On 09.01.21 12:24, Jeffrey Walton wrote:
Hi Tim/Darshit,
I think I would like to enable the fuzz tests. They appear to be
disabled at the moment:
Making all in fuzz
make[2]: Entering
On Sat, Jan 9, 2021 at 6:44 AM Tim Rühsen wrote:
>
> On 09.01.21 12:24, Jeffrey Walton wrote:
> > Hi Tim/Darshit,
> >
> > I think I would like to enable the fuzz tests. They appear to be
> > disabled at the moment:
> >
> > Making all in fuzz
> > make[2]: Entering directory
> >
On 09.01.21 12:24, Jeffrey Walton wrote:
Hi Tim/Darshit,
I think I would like to enable the fuzz tests. They appear to be
disabled at the moment:
Making all in fuzz
make[2]: Entering directory '/home/jwalton/Build-Scripts/wget-1.21.1/fuzz'
make[2]: Nothing to be done for 'all'.
Gnutls has been a little buggy off late with lots of serios bugs that have gone
unfixed for a while.
This could be just one of those bugs. To verify, please try connecting with
gnutls-cli and openssl s_client on the terminal to see if the respective TLS
libraries can handle the connection
Hi Jeffrey,
Thanks! This happened due to some last minute cleanups we did on
portability code in Wget. I've pushed a patch that should fix these
warnings.
In the future, there are more such cleanups I intend to perform to
simplify the codebase now that Wget expects parts of C99 support
> Why not simply link with 'libbcrypt.a'?
It worked, thanks!
Reiji
G-Ey3dr wrote:
Wget1.21 fails to build on MinGW(Windows).
Is it okay to not use getrandom() roughly?
C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
../lib/libgnu.a(getrandom.o): in function `getrandom':
Hi,
Thanks for the report.
This has already been fixed in master and will be available with the next point
release.
On January 4, 2021 1:29:29 PM GMT+01:00, Thomas Klausner
wrote:
>Hi!
>
>The configure script for wget-1.21 contains an unportable test(1)
>comparison operator -- it uses "=="
Hi,
Thanks for the heads up. The expression is indeed more complex than it
should be. I've made some more elaborate changes than you suggested to
fix and simplify these expressions
On 03.01.21 09:21, David Binderman wrote:
> Hello there,
>
> wget-1.21/src/retr.c:1445:10: style: Suspicious
Merged.
Thanks for the fix :)
On 02.01.21 20:34, Lars Wendler wrote:
> From: Matt Whitlock
>
> Gentoo-bug: https://bugs.gentoo.org/762946
> ---
> configure.ac | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 96adf13b..f6268fd5
On Fri, Jan 1, 2021 at 5:08 PM Jeffrey Walton wrote:
>
> On Fri, Jan 1, 2021 at 5:04 PM Darshit Shah wrote:
> >
> > The Python tests look like they fail because the system does not have a
> > Python3 binary.
> >
> > From past experience, it is possible that you have python3 installed,
> > but
On Fri, Jan 1, 2021 at 5:04 PM Darshit Shah wrote:
>
> The Python tests look like they fail because the system does not have a
> Python3 binary.
>
> From past experience, it is possible that you have python3 installed,
> but the system does not have a python3 binary. Just Python. I don't have
> a
Hi,
The Python tests look like they fail because the system does not have a
Python3 binary.
>From past experience, it is possible that you have python3 installed,
but the system does not have a python3 binary. Just Python. I don't have
a clean way to work around this problem.
On 01.01.21 21:59,
On Fri, Jan 1, 2021 at 4:32 PM Tim Rühsen wrote:
>
> The failure is the same for all perl tests:
>
> Can't locate HTTP/Daemon.pm in @INC (you may need to install the
> HTTP::Daemon module) (@INC contains: .
> /opt/local/lib/perl5/site_perl/5.26/darwin-thread-multi-2level
>
The failure is the same for all perl tests:
Can't locate HTTP/Daemon.pm in @INC (you may need to install the
HTTP::Daemon module) (@INC contains: .
/opt/local/lib/perl5/site_perl/5.26/darwin-thread-multi-2level
/opt/local/lib/perl5/site_perl/5.26
On Fri, Jan 1, 2021 at 1:53 PM Tim Rühsen wrote:
>
> On 01.01.21 19:50, Jeffrey Walton wrote:
> > On Fri, Jan 1, 2021 at 1:42 PM Tim Rühsen wrote:
> >>
> >> Hi Jeff,
> >>
> >> we recently updated gnulib for wget 1.21.
> >>
> >> Gnulib is C99 and at least in L288 it looks like your compiler
On 1/1/21 10:40 AM, Jeffrey Walton wrote:
tempname.c: In function 'random_bits':
tempname.c:90: warning: integer constant is too large for 'long' type
tempname.c:90: warning: this decimal constant is unsigned only in ISO C90
tempname.c: In function 'try_tempname_len':
tempname.c:288: error:
On 01.01.21 19:50, Jeffrey Walton wrote:
On Fri, Jan 1, 2021 at 1:42 PM Tim Rühsen wrote:
Hi Jeff,
we recently updated gnulib for wget 1.21.
Gnulib is C99 and at least in L288 it looks like your compiler doesn't
like a C99 construct. Possibly you need to explicitly switch on C99 mode !?
I
On Fri, Jan 1, 2021 at 1:42 PM Tim Rühsen wrote:
>
> Hi Jeff,
>
> we recently updated gnulib for wget 1.21.
>
> Gnulib is C99 and at least in L288 it looks like your compiler doesn't
> like a C99 construct. Possibly you need to explicitly switch on C99 mode !?
I _think_ the only thing available
FYI, with CFLAGS="-std=c89" I run into this:
tempname.c: In function 'try_tempname_len':
tempname.c:288:7: error: 'for' loop initial declarations are only
allowed in C99 or C11 mode
288 | for (size_t i = 0; i < x_suffix_len; i++)
| ^~~
Regards, Tim
On 01.01.21 19:42, Tim
Hi Jeff,
we recently updated gnulib for wget 1.21.
Gnulib is C99 and at least in L288 it looks like your compiler doesn't
like a C99 construct. Possibly you need to explicitly switch on C99 mode !?
Regards, Tim
On 01.01.21 19:38, Jeffrey Walton wrote:
Hi Everyone,
Here are the results of
Hi Jeff,
thank you for the feedback !
Regards, Tim
On 01.01.21 19:30, Jeffrey Walton wrote:
Hi Everyone,
Wget 1.21 is OK on Ubuntu 18.05 LTS, x86_64 sans the Perl problems.
Jeff
OpenPGP_signature
Description: OpenPGP digital signature
Hi,
Thanks for the heads up. Luckily it has already been fixed in Gnulib
(just one hour after I updated gnulib to make the release).
I'll update our submodule right away and make a new point release in the
next week after accumulating any other complaints that might arise.
On 01.01.21 11:32,
From: Darshit Shah
> [...] I've gone through it and applied it to the current
> Wget repository.
Thanks.
> I've taken the liberty to make some changes to your patches: [...]
That all sounds reasonable to me.
> Regarding your troubles with the print functions, [...]
I'll try to
Hi Steven,
Thanks for the patch. I've gone through it and applied it to the current
Wget repository.
I've taken the liberty to make some changes to your patches:
1. I reverted the changes to the help output. They weren't VMS specific.
I'd love to get some uniformity here, but this isn't the
occurrences in each URL) and
copies over the intervening part from the wrong place in the original file.
My "fix" is, in tag_handle_image(), to set the link->size based on a
re-escaped version of the URL extracted from the srcset. (We also have to
fiddle with the base_ind to make sure
I wrote a fix (https://gitlab.com/gnuwget/wget/-/merge_requests/14) that
you can review and/or test. It will likely be included in wget 1.21 soon.
Regards, Tim
On 26.12.20 21:18, Frans de Boer wrote:
Ok, top-posting it is.
The explanation in the manual speaks about filtering "on the complete
Ok, top-posting it is.
The explanation in the manual speaks about filtering "on the complete
URL". It speaks of the URL, so it must be a complete URL and
"(artworks)" is just the last part of the URL. But your right, for FTP
it is only working if enclosed in (). Since this does not
Hey,
more info on this... the regex (and other filters) are only applied to
the (file or directory) names as they are read from the FTP listing.
E.g. when using --reject-regex="(artworks)", you'll see in the logs
(with -d):
artworks is excluded/not-included through regex.
I this is not
Hi Frans,
my apologies, maybe I stopped the download too fast.
The command line with the artworks regex indeed has no effect.
In fact, after looking into the code, I can confirm that I hardly see
any of the filtering applied to FTP URLs that we apply to HTTP.
I am currently not sure if that
On 25-12-2020 18:42, Tim Rühsen wrote:
Hello Franz,
tried with wget 1.20.3 and these both command work:
#1 Do not download smc/artworks/ directory:
wget -d -4 --mirror -nH -np --retr-symlinks=no --passive-ftp
--no-verbose --cut-dirs=1 ftp://mirror.netcologne.de/savannah/smc/
Hello Franz,
tried with wget 1.20.3 and these both command work:
#1 Do not download smc/artworks/ directory:
wget -d -4 --mirror -nH -np --retr-symlinks=no --passive-ftp
--no-verbose --cut-dirs=1 ftp://mirror.netcologne.de/savannah/smc/
--reject-regex=".*(/artworks/.*)"
#2 Do not download
, si_code=SI_KERNEL} ---
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGALRM, {sa_handler=SIG_DFL, sa_mask=[ALRM],
sa_flags=SA_RESTART}, {sa_handler=0x454ba0, sa_mask=[ALRM],
sa_flags=SA_RESTART}, 8) = 0
ioctl(0, TIOCGPGRP, [10869]) = 0
getpgrp()
On Mon, Dec 7, 2020 at 9:29 PM Tom Crane wrote:
>
> On Mon, 7 Dec 2020, Petr Pisar wrote:
>
> > V??Mon, Dec 07, 2020 at 03:44:32AM +,??Tom Crane napsal(a):
> ...
> >
> > I suspect you use OpenSSL for TLS and wget is missing the fcntl() call from
> > src/openssl.c.
>
> That was it. Checking
On Mon, 7 Dec 2020, Petr Pisar wrote:
V??Mon, Dec 07, 2020 at 03:44:32AM +,??Tom Crane napsal(a):
[analysis cut]
Many thanks for your analysis.
I suspect you use OpenSSL for TLS and wget is missing the fcntl() call from
src/openssl.c.
That was it. Checking the Slackware distro's
07.12.2020 9:44, Tom Crane пишет:
On Sun, 6 Dec 2020, Petr Pisar wrote:
V Sun, Dec 06, 2020 at 06:48:13PM +, Tom Crane napsal(a):
tmp$ strace -s999 -f -e trace=network wget -S -v
--no-check-certificate --waitretry=1 --tries=1 --timeout=1
--read-timeout=1 --wait=1 -O /tmp/280200433.tmp
On Sun, 6 Dec 2020, Petr Pisar wrote:
V Sun, Dec 06, 2020 at 06:48:13PM +, Tom Crane napsal(a):
tmp$ strace -s999 -f -e trace=network wget -S -v --no-check-certificate
--waitretry=1 --tries=1 --timeout=1 --read-timeout=1 --wait=1 -O
/tmp/280200433.tmp
On Sun, Dec 6, 2020 at 9:01 PM Kulagin wrote:
>
> I'm on Windows. I would like to download http://www.tekkenzaibatsu.com/ which
> has different subdirectories like http://www.tekkenzaibatsu.com/wiki/ and
> http://www.tekkenzaibatsu.com/forums/. The website will be closed later
> this month, as
V Sun, Dec 06, 2020 at 06:48:13PM +, Tom Crane napsal(a):
> tmp$ strace -s999 -f -e trace=network wget -S -v --no-check-certificate
> --waitretry=1 --tries=1 --timeout=1 --read-timeout=1 --wait=1 -O
> /tmp/280200433.tmp https://www.tesco.com/groceries/en-GB/products/280200433
[...]
>
Thank you,
applied obvious fixes but only tested them on 64bit.
Regards, Tim
On 04.12.20 08:41, Jeffrey Walton wrote:
Hi Everyone/Tim,
I'm testing on 32-bit hardware. It's an old VIA Padlock machine
running Peppermint, which is based on Ubuntu. There are a few type
related warnings that
V Sun, Nov 29, 2020 at 05:36:50PM +0100, Tim Rühsen napsal(a):
> Ya, this bug is fixed upstream since a while:
> https://github.com/libwww-perl/HTTP-Daemon/issues/21.
>
> Just for the record:
> - the patch just touches a single line of perl code.
> - it took since 2011 to fix it (report is from
Ya, this bug is fixed upstream since a while:
https://github.com/libwww-perl/HTTP-Daemon/issues/21.
Just for the record:
- the patch just touches a single line of perl code.
- it took since 2011 to fix it (report is from 2011-10-01).
Some "stable" OSes still won't upgrade... ¯\_(ツ)_/¯
Hello,
I was checking out the various formats that the manual for wget is available in
and was trying to decide which I liked better the single page html or the one
page per node..Then I noticed something.. The page per node html is actually
the version 1.18 manual, or at least that is what it
On 06.11.20 04:06, Makoto Wada wrote:
Follow-up Comment #2, bug #59363 (project wget):
Dear Tim Ruehsen, you have suspected correctly.
[comment #1 comment #1:]
You say that you expect --wait=N to wait N seconds *before* a retrieval !?
So the word *between* is not a mistake in documentation
Hi Ilgaz,
sorry for the late reply.
I can reproduce your issue with
LC_ALL=tr_TR.utf8 wget https://dl.google.com/linux/linux_signing_key.pub
First work-around would be to use
LC_ALL=C wget ...
The bug is not reproducible with wget from the latest master branch.
So you either you build your own
he percent sign ;-)GerdSent from
my Samsung Galaxy smartphone.
Original message From: BAHRI INCELER Date:
2020/10/14 03:32 (GMT+02:00) To: Taylor Cc:
bug-wget@gnu.org Subject: Re: Love you wget :) help please! I know to use -O
of course.but the fact is, when you use this c
there is space..
[cid:0860bb3f-a840-40aa-8fe7-2f4c35a60ab9]
but it must save like orginal file name.
From: Taylor
Sent: Wednesday, 14 October 2020 3:14 AM
To: BAHRI INCELER
Cc: bug-wget@gnu.org
Subject: Re: Love you wget :) help please!
> but it decoding it
> but it decoding it
Who decodes what?
> I did try, everything like --restrict-file-names but nothing worked
try
> output_document = file
> Set the output filename—the same as ‘-O file’
El 2020-09-15 19:05, Witold Baryluk escribió:
Hi,
I love wget, but I can't find if it supports PSK or SRP protocols?
Underlying openssl supports them, and it would be nice to use it with
wget when, especially when using TLS v1.2 and TLS v1.3.
I am mostly interested in PSK, but SRP support
Hm,
as written in the README.md:
# Downloading and building from tarball
wget https://gnuwget.gitlab.io/wget2/wget2-latest.tar.gz
tar xf wget2-latest.tar.gz
cd wget2-*
./configure
make
make check
El 2020-08-10 19:01, Darshit Shah escribió:
Interesting.. Thanks for the report.
However, it may make sense to keep this behavior since I don't think
that the script is compatible with Python 2.
I recently run the entire test suite in Alpine with python 3.8.0
(actually a 'python' symlink
[Redirected from bug-gnulib]
Jeffrey Walton wrote:
> > Yeah, I wish Tim would build a release tarball so we don't have to do
> > the git submodule thing.
Darshit Shah replied:
> We can work on that soon. Wget2 _is_ technically still alpha software.
> And with both Tim and me busy with real
On 8/14/20, Tim Rühsen wrote:
> The rest of the time is the overall operation of wget.
>
> DNS timeout only applies to DNS lookups - each one must not take longer
> than --dns-timeout.
>
> Connect timeout is the max time a connection phase to a server may take.
> When connected, the
The rest of the time is the overall operation of wget.
DNS timeout only applies to DNS lookups - each one must not take longer
than --dns-timeout.
Connect timeout is the max time a connection phase to a server may take.
When connected, the request/response workload begins, consisting of an
Thanks. The bootstrap script is maintained by upstream gnulib. So I'll
have to discuss this case with them in order to change the script. But
this patch will definitely be helpful
On 8/10/20 9:49 PM, Jeffrey Walton wrote:
On Mon, Aug 10, 2020 at 1:02 PM Darshit Shah wrote:
Interesting..
On Mon, Aug 10, 2020 at 1:02 PM Darshit Shah wrote:
>
> Interesting.. Thanks for the report.
>
> However, it may make sense to keep this behavior since I don't think
> that the script is compatible with Python 2. I'll have to check it
> again. I will likely change the behaviour to explicitly
Interesting.. Thanks for the report.
However, it may make sense to keep this behavior since I don't think
that the script is compatible with Python 2. I'll have to check it
again. I will likely change the behaviour to explicitly check for Python
3 and fall back to the bourne shell script
Hi,
We cannot help you without more information. Please provide outputs from
from the working and non working instances preferably using the --debug
switch so we can see what was happening.
Also, please share the output of wget --version.
On 8/10/20 4:48 PM, Matti Kamarainen wrote:
Hi,
On Mon, Aug 10, 2020 at 11:13 AM Matti Kamarainen wrote:
>
> not sure if this email address is right for asking this kind of questions,
> but I hope so.
>
> I'm trying to download data inside an Ubuntu 18.04 docker container using
> wget. Mostly it works fine, but one specific file can't be
Hi,
Please use bug-wget@gnu.org in the future for questions and help. It has
a wider audience who will answer your questions.
About your problem, we are aware of it. It happens because upstream
gnulib project wants defaults to Wget for downloading the translation
files. It is however
I saw that in the man. What are the rest of the time besides dns-time,
connect-time, read-time? Thanks.
On Sun, Aug 9, 2020 at 5:50 AM Tim Rühsen wrote:
> Hi,
>
> --timeout is explained in `man wget`.
>
> In short: it doesn't stop wget after N seconds - it's a shortcut for
> setting
301 - 400 of 5537 matches
Mail list logo
