Re: [Bug-wget] [bug #50223] wget 1.19 will not build on MacOS 10.12.3

Charles wrote: > The `make` step fails with this: > > --8< > /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am > CC connect.o > CC convert.o > CC cookies.o > CC ftp.o > ftp.c:1466:19: error: no

Re: [Bug-wget] bug #45790: wget prints it's progress even when background

Piotr writes: > I would like to avoid forcing users to hack like this ;). > Wget should print to std* when in fg and print to wget.log when in bg, no > matter how user gets there. > I don't think getpgrp() == tcgetpgrp(STDOUT_FILENO) is heavy and should > probaby be ok to

Re: [Bug-wget] bug #45790: wget prints it's progress even when background

I would like to avoid forcing users to hack like this ;). Wget should print to std* when in fg and print to wget.log when in bg, no matter how user gets there. I don't think getpgrp() == tcgetpgrp(STDOUT_FILENO) is heavy and should probaby be ok to check it when printing lines. Piotr 28 wrz

Re: [Bug-wget] bug #45790: wget prints it's progress even when background

"Wajda, Piotr" writes: > The case with stopping wget is obvious. CTRL+Z and bg should make wget > write to file and I can catch bg with SIGCONT. > But I wonder what to do when after CTRL+Z and bg, user runs fg. In this > case there's no signal between bg anf fg, Though the

Re: [Bug-wget] bug #45790: wget prints it's progress even when background

Hi, The case with stopping wget is obvious. CTRL+Z and bg should make wget write to file and I can catch bg with SIGCONT. But I wonder what to do when after CTRL+Z and bg, user runs fg. In this case there's no signal between bg anf fg, and I can only check for getpgrp() ==

Re: [Bug-wget] bug #46584: wget --spider always returns zero exit status

Darshit Shah writes: > Apart from the patch format, the patch itself looks good. > > @Giuseppe: We will require Copyright assignments for Piotr right? This > patch may be small, but there are a couple others in the pipeline. yes, I think we will need that. The sum of all the

Re: [Bug-wget] bug #46584: wget --spider always returns zero exit status

It's correct. That is because `git format-patch` is often used together with `git send-email`. It formats the patch as an email that can be directly passed to your MUA. What you sent is a correct form of the patch that is easy for us to apply. However, notice that you sent the patch on the

Re: [Bug-wget] bug #45790: wget prints it's progress even when background

Hi Piotr, The patch looks fine. However, when Wget is foregrounded again, the progress bar remains invisible. When the process is foregrounded again, you should undo the effects of `redirect_output_signal()` * pwa...@gmail.net.pl [160919 18:01]: Hi Darshit, Sorry for

Re: [Bug-wget] bug #45790: wget prints it's progress even when background

Ok, I'll fix that. Thanks Piotr W dniu 19.09.2016 o 19:30, Darshit Shah pisze: Hi Piotr, The patch looks fine. However, when Wget is foregrounded again, the progress bar remains invisible. When the process is foregrounded again, you should undo the effects of `redirect_output_signal()` *

Re: [Bug-wget] bug #46584: wget --spider always returns zero exit status

Apart from the patch format, the patch itself looks good. @Giuseppe: We will require Copyright assignments for Piotr right? This patch may be small, but there are a couple others in the pipeline. * Wajda, Piotr [160916 22:48]: Hi, I'd like to start contributing to wget.

Re: [Bug-wget] bug #46584: wget --spider always returns zero exit status

I'm not yet fully familiar with git format-patch (weird for me that it's adding email-like headers. Is it suppose to be email creation tool for patches?), I believe it will work for you. Thanks Piotr W dniu 19.09.2016 o 18:56, Darshit Shah pisze: Hi Piotr, How did you create this patch?

Re: [Bug-wget] bug #46584: wget --spider always returns zero exit status

Hi Piotr, How did you create this patch? Because git refuses to accept it. Patch format detection fails. Please regenerate all your patches using `git format-patch` so that we can apply the patches locally. * Wajda, Piotr [160916 22:48]: Hi, I'd like to start

Re: [Bug-wget] bug #45790: wget prints it's progress even when background

Hi Darshit, Sorry for pasting patch into email incorrectly. I've send 2 other patches before, but as attachments, so they should be fine. Thanks Piotr W dniu 19.09.2016 o 17:28, Darshit Shah pisze: Hi Piotr, Thanks for your interest in Wget. I shall review your patch soon. However, for

Re: [Bug-wget] bug #45790: wget prints it's progress even when background

Hi Piotr, Thanks for your interest in Wget. I shall review your patch soon. However, for future reference please do not send patches that are pasted into the mail like this. It makes it extremely difficult for us to apply the patch. I was unable to apply the provided diff after simply saving

Re: [Bug-wget] [bug #47408] Wget sends malformed SNI host names

On Wed, 16 Mar 2016, Tim Ruehsen wrote: Here is a patch for both openssl and gnutls. Please comment, I'll push it tomorrow. The bug report says the SNI field should be different than the Host: header, but I question the sensibility in that. What would be the point? (pun not intended =B))

Re: [Bug-wget] [bug #47408] Wget sends malformed SNI host names

Great. Thanks ! Tim On Wednesday 16 March 2016 13:06:23 Daniel Stenberg wrote: > On Wed, 16 Mar 2016, Tim Ruehsen wrote: > > Should we follow the browsers or curl ? > > I brought this subject to the http-wg mailing list, possibly we can clear it > up on a wider scale: > >

Re: [Bug-wget] [bug #47408] Wget sends malformed SNI host names

On Wednesday 16 March 2016 11:59:04 Daniel Stenberg wrote: > On Wed, 16 Mar 2016, Tim Ruehsen wrote: > > Here is a patch for both openssl and gnutls. Please comment, I'll push it > > tomorrow. > > The bug report says the SNI field should be different than the Host: header, > but I question the

Re: [Bug-wget] [bug #47408] Wget sends malformed SNI host names

On Wed, 16 Mar 2016, Tim Ruehsen wrote: Should we follow the browsers or curl ? I brought this subject to the http-wg mailing list, possibly we can clear it up on a wider scale: https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0430.html -- / daniel.haxx.se

Re: [Bug-wget] [bug #47408] Wget sends malformed SNI host names

Here is a patch for both openssl and gnutls. Please comment, I'll push it tomorrow. BTW, when fixing the gnutls code I stumbled upon a bug in 3.4.x. I reported it as https://gitlab.com/gnutls/gnutls/issues/78 Tim On Monday 14 March 2016 17:21:15 Yst Dawson wrote: > URL: >

Re: [Bug-wget] [bug #47408] Wget sends malformed SNI host names

On Wed, 16 Mar 2016, Jay Satiro wrote: I tried this in Firefox, Chrome and IE and all send the trailing dot for SNI. curl doesn't though, it strips the trailing dot and also it won't appear in the host header. And the associated Firefox bug report:

Re: [Bug-wget] [bug #43799] wget should implement OCSP + OCSP stapling

On Wednesday 19 August 2015 18:19:16 Petr Pisar wrote: On Wed, Aug 19, 2015 at 03:37:06PM +, Tim Ruehsen wrote: Regarding MITM and other attacks... did you notice that OCSP responder URLs are HTTP (plain text) will all the insecurity ? I never saw a HTTPS URL, did you ? There is

Re: [Bug-wget] [bug #45790] wget prints it's progress even when background

Darshit Shah dar...@gmail.com writes: This affects an invokation using the shell's background operator () too. E.g.: wget http://cdimage.debian.org/debian-cd/current/multi-arch/iso-cd/debian-8.1.0-amd64-i386-netinst.iso will cause the logging output and progress bar to be displayed on the

Re: [Bug-wget] [bug #45790] wget prints it's progress even when background

This affects an invokation using the shell's background operator () too. E.g.: wget http://cdimage.debian.org/debian-cd/current/multi-arch/iso-cd/debian-8.1.0-amd64-i386-netinst.iso will cause the logging output and progress bar to be displayed on the terminal as explained in the bug report.

Re: [Bug-wget] [bug #45778] wget and unicode

There is a current patch in discussion. tim@blitz-lx:~/src/wget$ src/wget -nv http://zh.wikipedia.org/wiki/%E9%A6%96%E9%A1%B5 2015-08-17 14:47:52 URL:http://zh.wikipedia.org/wiki/%E9%A6%96%E9%A1%B5 [36245] - 首页 [1] Tim signature.asc Description: This is a digitally signed message part.

Re: [Bug-wget] [bug #45037] wget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README deletes README symlink

On 07/05/15 06:10, Darshit Shah wrote: Given that this is a clearly documented feature of Wget, that -O is supposed to work as shell redirection, I think it should not pose too many issues. Yes, there is the security risk where another file may be overwritten, but I think the user should be

Re: [Bug-wget] [bug #45037] wget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README deletes README symlink

Aah! It was a quick patch I wrote and had tested only one scenario. Which is why I wanted some reviews before pushing it. Seems like it'll take slightly more effort to fix this. I'll take a look again today evening. On Thu, May 7, 2015 at 1:04 PM, Tim Ruehsen tim.rueh...@gmx.de wrote: Hi

Re: [Bug-wget] [bug #45037] wget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README deletes README symlink

Hi Darshit, your patch doesn't work as expected. $ cat abc xxx $ ln -s xxx foo $ ln -s /etc/passwd README $ ../src/wget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README ... $ ls -la lrwxrwxrwx 1 oms users 11 May 7 09:28 README - /etc/passwd -rw-r--r-- 1 oms users 1495 May 7 09:30

Re: [Bug-wget] [bug #45037] wget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README deletes README symlink

On 05/06, Ángel wrote: Follow-up Comment #3, bug #45037 (project wget): It's clearly a bug. If we are downloading README to local file foo, there's no reason to remove the local symlink README. I agree. This is definitely a bug. When we want to save into a name where there's currently a

Re: [Bug-wget] [bug #45037] wget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README deletes README symlink

joey@darkstar:~/tmp/yln -s /etc/passwd README joey@darkstar:~/tmp/yls README@ joey@darkstar:~/tmp/ywget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README --2015-05-05 13:17:22-- ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README = ‘foo’ Resolving ftp.funet.fi (ftp.funet.fi)...

Re: [Bug-wget] [Bug-Wget] Wget closes connection despite Keep-Alive

On Wed, Nov 5, 2014 at 3:50 PM, Giuseppe Scrivano gscriv...@gnu.org wrote: Hi Darshit, Darshit Shah dar...@gmail.com writes: * Off-topic: Looking at the condition, there's one comparison that we can avoid: hs-restval 0 contlen = 0 hs-restval = contlen In this case, hs-restval 0 is

Re: [Bug-wget] [Bug-Wget] Wget closes connection despite Keep-Alive

On 11/04, Tim Rühsen wrote: Am Dienstag, 4. November 2014, 23:25:40 schrieb Darshit Shah: While looking at some debug output from Wget, I noticed that in case of a 416 Range Not Satisfiable response, Wget forces the connection close despite the fact that the server explicitly sent a

Re: [Bug-wget] [Bug-Wget] Wget closes connection despite Keep-Alive

On Wednesday 05 November 2014 13:49:56 Darshit Shah wrote: * Off-topic: Looking at the condition, there's one comparison that we can avoid: hs-restval 0 contlen = 0 hs-restval = contlen In this case, hs-restval 0 is redundant and un-needed. ACK. I'm waiting for Giuseppe's views on

Re: [Bug-wget] [Bug-Wget] Wget closes connection despite Keep-Alive

Am Dienstag, 4. November 2014, 23:25:40 schrieb Darshit Shah: While looking at some debug output from Wget, I noticed that in case of a 416 Range Not Satisfiable response, Wget forces the connection close despite the fact that the server explicitly sent a `Connection: Keep-Alive` header.

Re: [Bug-wget] Bug in WGET?

Patrick Steil patr...@churchbuzz.org writes: Also, if I use wget in spider mode, it will at the end of the log output tell me about all the broken links... but I also need to know what page those broken links are created on (if the broken link) is on the site I am getting... this will help me

Re: [Bug-wget] Bug in WGET?

Hello, Patrick Steil patr...@churchbuzz.org writes: If I run this command: wget www.domain.org/news?page=1 options= -r --no-clobber --html-extension --convert-links -np --include-directories=news Here is what it does today: 1. When --html-extension is turned on, the --noclobber is not