date:20160930

Re: [Bug-wget] [PATCH 21/27] New option --metalink-index to process Metalink application/metalink4+xml

2016-09-30 Thread Matthew White

Hi,

On Thu, 29 Sep 2016 06:03:01 +0200
Matthew White  wrote:

> +  while ((n = FILE_SYSTEM_PREFIX_LEN (p)))
> +p += n;

Fix attached to silence Coverity's false positive.

Thanks to Tim Ruehsen and Darshit Shah:
http://lists.gnu.org/archive/html/bug-wget/2016-09/msg00170.html
http://lists.gnu.org/archive/html/bug-wget/2016-09/msg00171.html
http://lists.gnu.org/archive/html/bug-wget/2016-09/msg00172.html

Regards,
Matthew

-- 
Matthew White 
>From 0538e791fb5ded49775e3ffb67001108d4e27b0e Mon Sep 17 00:00:00 2001
From: Matthew White 
Date: Fri, 26 Aug 2016 11:19:24 +0200
Subject: [PATCH 21/27] New option --metalink-index to process Metalink
 application/metalink4+xml

* NEWS: Mention the effect of --metalink-index over Metalink
* src/init.c: Add new option metalinkindex (opt.metalink_index),
  initialize to -1
* src/main.c: Add new option metalink-index (--metalink-index=NUMBER)
* src/options.h: Add new option metalink_index (int)
* src/metalink.h: Add declaration of functions fetch_metalink_file(),
  replace_metalink_basename()
* src/metalink.c: Add functions fetch_metalink_file() simple file
  fetch, replace_metalink_basename() replace file basename
* src/metalink.c (retrieve_from_metalink): New. Process Metalink
  application/metalink4+xml of opt.metalink_index ordinal number
* doc/wget.texi: Add new option metalink-index (--metalink-index)
  documentation
* doc/metalink-standard.txt: Updated doc. Add documentation about
  Metalink application/metalink4+xml metaurls download naming system
* doc/metalink-standard.txt: Update Metalink/XML and HTTP examples
* testenv/Makefile.am: Add new files
* testenv/Test-metalink-http-xml.py: New file. Metalink/HTTP automated
  Metalink/XML "application/metalink4+xml" --metalink-index tests
* testenv/Test-metalink-http-xml-trust.py: New file. Metalink/HTTP
  automated Metalink/XML "application/metalink4+xml" --metalink-index
  retrieval with --trust-server-names tests

WARNING: Do not use lib/dirname.c (dir_name) to get the directory
name, it may append a dot '.' character to the directory name.
---
 NEWS|   3 +
 doc/metalink-standard.txt   |  36 +++-
 doc/wget.texi   |   9 +
 src/init.c  |   5 +
 src/main.c  |   3 +
 src/metalink.c  | 348 
 src/metalink.h  |   4 +
 src/options.h   |   1 +
 testenv/Makefile.am |   2 +
 testenv/Test-metalink-http-xml-trust.py | 272 +
 testenv/Test-metalink-http-xml.py   | 272 +
 11 files changed, 947 insertions(+), 8 deletions(-)
 create mode 100755 testenv/Test-metalink-http-xml-trust.py
 create mode 100755 testenv/Test-metalink-http-xml.py

diff --git a/NEWS b/NEWS
index 2153d9a..ca7eaba 100644
--- a/NEWS
+++ b/NEWS
@@ -9,6 +9,9 @@ Please send GNU Wget bug reports to .
 
 * Changes in Wget X.Y.Z
 
+* When processing a Metalink header, --metalink-index= allows
+  to process the header's application/metalink4+xml files.
+
 * When processing a Metalink file, --trust-server-names enables the
   use of the destination file names specified in the Metalink file,
   otherwise a safe destination file name is computed.
diff --git a/doc/metalink-standard.txt b/doc/metalink-standard.txt
index 18acaaa..78709fb 100644
--- a/doc/metalink-standard.txt
+++ b/doc/metalink-standard.txt
@@ -65,10 +65,16 @@ ignored, see '1. Security features'.
 
 
 When --trust-server-names is off, the basename of the --input-metalink
-file, if available, or of the mother URL is trusted.
+file, if available, or of the mother URL is trusted. This trusted name
+is the radix of any subsequent file name.
+
+When a Metalink/HTTP in encountered, any fetched Metalink/XML file has
+its own ordinal number appended as suffix to the trusted name. In this
+case scenario, an unique Metalink/XML file is saved each time applying
+an additional suffix to the currently computed name when necessary.
 
 The files described by a Metalink/XML file will be named sequentially
-applying a suffix to the trusted name.
+applying an additional suffix to the currently trusted/computed name.
 
 3.1.1.2 With --trust-server-names
 =
@@ -91,6 +97,8 @@ found unsafe too, the file is not downloaded.
 4.1 Example files
 =
 
+See [1 #section-1.1].
+
 cat > bugus.meta4 << EOF
 
 
@@ -134,8 +142,9 @@ be informed to the caller of libmetalink's metalink_parse_file().
 Fetched metalink:file elements shall be wrote using the unique "name"
 field as file name [1 #section-4.1.2.1].
 
-A metalink:file url's file name shall not substitute the "name" field,
-see '3. Download file name'.
+A metalink:file url's file name shall not

Re: [Bug-wget] [PATCH 11/27] Enforce Metalink file name verification, strip directory if necessary

2016-09-30 Thread Matthew White

Hi,

On Thu, 29 Sep 2016 06:02:51 +0200
Matthew White  wrote:

> +  while ((n = FILE_SYSTEM_PREFIX_LEN (basename)))
> +basename += n;

Fix attached to silence Coverity's false positive.

Thanks to Tim Ruehsen and Darshit Shah:
http://lists.gnu.org/archive/html/bug-wget/2016-09/msg00170.html
http://lists.gnu.org/archive/html/bug-wget/2016-09/msg00171.html
http://lists.gnu.org/archive/html/bug-wget/2016-09/msg00172.html

Regards,
Matthew

-- 
Matthew White 
>From 43ec7008f21195dfc33daacbbb760fa456fd77f5 Mon Sep 17 00:00:00 2001
From: Matthew White 
Date: Wed, 17 Aug 2016 16:50:18 +0200
Subject: [PATCH 11/27] Enforce Metalink file name verification, strip
 directory if necessary

* NEWS: Mention the use of a safe Metalink destination path
* src/metalink.h: Add declaration of functions get_metalink_basename(),
  last_component(), metalink_check_safe_path()
* src/metalink.c: Add directive #include "dosname.h"
* src/metalink.c: Add function get_metalink_basename() to return the
  basename of a file name, strip w32's drive letter prefixes
* src/metalink.c (retrieve_from_metalink): Enforce Metalink file name
  verification, if the file name is unsafe try its basename
* doc/metalink.txt: Update document. Explain --directory-prefix

The function get_metalink_basename() uses FILE_SYSTEM_PREFIX_LEN to
catch any 'C:D:file' (w32 environment), then it removes each drive
letter prefix, i.e. 'C:' and 'D:'.

Unsafe file names contain an absolute, relative, or home path.  Safe
paths can be verified by libmetalink's metalink_check_safe_path().
---
 NEWS |  7 +++
 doc/metalink.txt |  4 
 src/metalink.c   | 62 
 src/metalink.h   |  4 
 4 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index bfb3bef..72f8728 100644
--- a/NEWS
+++ b/NEWS
@@ -9,6 +9,13 @@ Please send GNU Wget bug reports to .
 
 * Changes in Wget X.Y.Z
 
+* When processing a Metalink file, enforce a safe destination path.
+  Remove any drive letter prefix under w32, i.e. 'C:D:file'.  Call
+  libmetalink's metalink_check_safe_path() to prevent absolute,
+  relative, or home paths:
+  https://tools.ietf.org/html/rfc5854#section-4.1.2.1
+  https://tools.ietf.org/html/rfc5854#section-4.2.8.3
+
 * When processing a Metalink file, --directory-prefix= sets
   the top of the retrieval tree to prefix for Metalink downloads.
 
diff --git a/doc/metalink.txt b/doc/metalink.txt
index 94a07ba..9d9dea2 100644
--- a/doc/metalink.txt
+++ b/doc/metalink.txt
@@ -159,3 +159,7 @@ References:
 
 Set the top of the retrieval tree to prefix for both Metalink/XML
 and Metalink/HTTP downloads, see wget(1).
+
+If combining the prefix with the file name results in an absolute,
+relative, or home path, the directory components are stripped and
+only the basename is used. See '4.1 Implemented safety features'.
diff --git a/src/metalink.c b/src/metalink.c
index 3e03aee..be723dc 100644
--- a/src/metalink.c
+++ b/src/metalink.c
@@ -40,6 +40,7 @@ as that of the covered work.  */
 #include "sha1.h"
 #include "sha256.h"
 #include "sha512.h"
+#include "dosname.h"
 #include "xstrndup.h"
 #include "c-strcase.h"
 #include 
@@ -87,6 +88,8 @@ retrieve_from_metalink (const metalink_t* metalink)
   metalink_file_t *mfile = *mfile_ptr;
   metalink_resource_t **mres_ptr;
   char *filename = NULL;
+  char *basename = NULL;
+  char *safename = NULL;
   char *destname = NULL;
   bool hash_ok = false;
 
@@ -110,6 +113,23 @@ retrieve_from_metalink (const metalink_t* metalink)
 
   DEBUGP (("Processing metalink file %s...\n", quote (mfile->name)));
 
+  /* Enforce libmetalink's metalink_check_safe_path().  */
+  basename = get_metalink_basename (filename);
+  safename = metalink_check_safe_path (filename) ? filename : basename;
+
+  if (filename != safename)
+logprintf (LOG_NOTQUIET,
+   _("Unsafe metalink file %s. Stripping directory...\n"),
+   quote (filename));
+
+  if (!basename)
+{
+  logprintf (LOG_NOTQUIET,
+ _("Rejecting metalink file. Invalid basename.\n"));
+  xfree (filename);
+  continue;
+}
+
   /* Resources are sorted by priority.  */
   for (mres_ptr = mfile->resources; *mres_ptr && !skip_mfile; mres_ptr++)
 {
@@ -170,6 +190,12 @@ retrieve_from_metalink (const metalink_t* metalink)
   /* Avoid recursive Metalink from HTTP headers.  */
   bool _metalink_http = opt.metalink_over_http;
 
+  /* FIXME: could be useless.  */
+  if (strcmp (url->file, basename))
+logprintf (LOG_VERBOSE,
+   _("URL file name %s and Metalink file name %s are different.\n"),
+   quote_n (0, url->file), quote_n (1, basename));
+

Re: [Bug-wget] wget for windows - current build?

2016-09-30 Thread Eli Zaretskii

> Date: Fri, 30 Sep 2016 16:52:55 +0200 (SAST)
> From: "ge...@mweb.co.za" 
> 
> So, is there a "secret" new place hosting a newer version for Windows? Or is 
> the 1.11 on sourceforge actually okay? And - while I am already asking all 
> these stupid questions - would that version actually handle larger file sizes 
> already? 

You can find a 32-bit Windows port of 1.16.1 here:

  https://sourceforge.net/projects/ezwinports/files/?source=navbar

[Bug-wget] wget for windows - current build?

2016-09-30 Thread ge...@mweb.co.za

Hi guys, 

I just checked, I believe the version of wget I am running is from 2003 (and I 
have been using it for much mich longer than that ...) At some point I even 
wrote scripts around wget batch jobs I used to run ... 

But I am kind of stuck in Windows. And things happen on a different time line 
there. 

Just the other day I noticed that I was getting no joy downloading certain 
files and only after that had happened a few times did I realize that the file 
size was shown as negative. That is something that I have seen when the number 
is too big as an unsigned integer to also be interpreted as a 2's complement 
integer in the available number of bits. And then it dawned on me that my old 
wget may not be up to files greater than, say, 2GB. 

Time for a new download. 

I am being pointed at sourceforge, even by the German c't magazine, which is 
usually pretty clued up. But I remember having heard bad things about 
sourceforge. And the version they offer is 1.11.4, whereas your version on 
gnu.org is 1.18 or so. 

So, is there a "secret" new place hosting a newer version for Windows? Or is 
the 1.11 on sourceforge actually okay? And - while I am already asking all 
these stupid questions - would that version actually handle larger file sizes 
already? 

Thanks, guys, 

Gerd 

(and I mustn't forget to send a note to c't as well ...)

Re: [Bug-wget] Digest Authentication Support in wget

2016-09-30 Thread Darshit Shah


Hi,

I'm not sure what exactly you're looking for. For HTTP authentication, 
Wget supports both Basic and Digest Authentication.


However, for proxy authentication, Wget currently supports only basic 
authentication. We would however be glad to accept a patch for digest 
authentication on proxies, should someone write one.


* Osmani Rosado Falcon  [160929 18:47]:

Hello,

I connect to internet through a digest proxy. According to wget manual 
the authentication is basic in wget. I need digest authentication 
support in wget because many applications use it as back end. I known 
that curl support digest authentication but curl not supply all my 
needs. Do you will add this feature in future releases.


Thanks,
Osmani

--
Osmani Rosado Falcón
Lic en Ciencia de la Computación




--
Thanking You,
Darshit Shah
PGP Fingerprint: 7845 120B 07CB D8D6 ECE5 FF2B 2A17 43ED A91A 35B6


signature.asc
Description: PGP signature

Re: [Bug-wget] Fwd: New Defects reported by Coverity Scan for GNU Wget

2016-09-30 Thread Tim Ruehsen

 while ((n = FILE_SYSTEM_PREFIX_LEN (p)) > 0)

in two places should silence them all four.

On Friday, September 30, 2016 11:56:41 AM CEST Darshit Shah wrote:
> -- Forwarded message --
> From: 
> Date: 30 September 2016 at 11:42
> Subject: New Defects reported by Coverity Scan for GNU Wget
> To: dar...@gmail.com
> 
> 
> 
> Hi,
> 
> Please find the latest report on new defect(s) introduced to GNU Wget found
> with Coverity Scan.
> 
> 4 new defect(s) introduced to GNU Wget found with Coverity Scan.
> 4 defect(s), reported by Coverity Scan earlier, were marked fixed in the
> recent build analyzed by Coverity Scan.
> 
> New defect(s) Reported-by: Coverity Scan
> Showing 4 of 4 defect(s)
> 
> 
> ** CID 1363354:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
> /src/metalink.c: 971 in ()
> 
> 
> 
> 
> *** CID 1363354:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
> /src/metalink.c: 971 in ()
> 965
> 966   /* Remove prefix drive letters if required, i.e. when in w32
> 967  environments.  */
> 968   p = new;
> 969   while (p[0] != '\0')
> 970 {
> 
> >>> CID 1363354:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
> >>> use of "=" where "==" may have been intended
> 
> 971   while ((n = FILE_SYSTEM_PREFIX_LEN (p)))
> 972 p += n;
> 973
> 974   if (p != new)
> 975 {
> 976   while (ISSLASH (p[0]))
> 
> ** CID 1363353:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
> /src/metalink.c: 1015 in ()
> 
> 
> 
> 
> *** CID 1363353:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
> /src/metalink.c: 1015 in ()
> 1009
> 1010   if (!name)
> 1011 return NULL;
> 1012
> 1013   basename = last_component (name);
> 1014
> 
> >>> CID 1363353:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
> >>> use of "=" where "==" may have been intended
> 
> 1015   while ((n = FILE_SYSTEM_PREFIX_LEN (basename)))
> 1016 basename += n;
> 1017
> 1018   return metalink_check_safe_path (basename) ? basename : NULL;
> 1019 }
> 1020
> 
> ** CID 1363352:  Control flow issues  (DEADCODE)
> /src/metalink.c: 972 in replace_metalink_basename()
> 
> 
> 
> 
> *** CID 1363352:  Control flow issues  (DEADCODE)
> /src/metalink.c: 972 in replace_metalink_basename()
> 966   /* Remove prefix drive letters if required, i.e. when in w32
> 967  environments.  */
> 968   p = new;
> 969   while (p[0] != '\0')
> 970 {
> 971   while ((n = FILE_SYSTEM_PREFIX_LEN (p)))
> 
> >>> CID 1363352:  Control flow issues  (DEADCODE)
> >>> Execution cannot reach this statement: "p += n;".
> 
> 972 p += n;
> 973
> 974   if (p != new)
> 975 {
> 976   while (ISSLASH (p[0]))
> 977 ++p;
> 
> ** CID 1363351:  Control flow issues  (DEADCODE)
> /src/metalink.c: 1016 in get_metalink_basename()
> 
> 
> 
> 
> *** CID 1363351:  Control flow issues  (DEADCODE)
> /src/metalink.c: 1016 in get_metalink_basename()
> 1010   if (!name)
> 1011 return NULL;
> 1012
> 1013   basename = last_component (name);
> 1014
> 1015   while ((n = FILE_SYSTEM_PREFIX_LEN (basename)))
> 
> >>> CID 1363351:  Control flow issues  (DEADCODE)
> >>> Execution cannot reach this statement: "basename += n;".
> 
> 1016 basename += n;
> 1017
> 1018   return metalink_check_safe_path (basename) ? basename : NULL;
> 1019 }
> 1020
> 1021 /*
> 
> 
> 
> 
> To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.
> net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-
> 2Bd2MGckcRZIqiw5BQEQ9vrzwIdaOu6EyzrI-2BoVm-2FEMS-
> 2BtEEzxnwMw-3D-3D_kmui4qaulLL-2B3aqI2t0AqcRL86AEPYbxN-
> 2BCgq0zmT00BmekYpSJJUGM33Yx8V8baKh7kRlNSwetdfieonCGGzJ4QYVxH
> vfMMGl76aCePsL34gbPPb7dxn4Id1d9deuC9Y7BAxKjjbp-
> 2FftNVBnHuXVkezFqLRfeG4lq81MODUy-2BMiZj7vctaLyII1IYmfMEzP0imR8H
> 154WxDDAYuyuuhvg-3D-3D
> 
> To manage Coverity Scan email notifications for "dar...@gmail.com", click
> https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-> 
> 2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-
> 2FA8y06Nq4TvwZ2eDmcOCUJLMeJKuafOsXG7DLig-2B-2FtTyxF8I6BdKjCNNNE0p1fBHEAYJw
> xxK4JPbFe1L0xnM-2BlTMyiOorikRvRyowLpuAxiVSoFemksE-3D_kmui4qaulLL-
> 2B3aqI2t0AqcRL86AEPYbxN-2BCgq0zmT00BmekYpSJJUGM33Yx8V8
> baVNeKutSl02CFyJ5s2Gh89FWKoJo430K-2FSUWJN5QbrFwqT6beqV9pm786up9rv-2B-
>

[Bug-wget] Fwd: New Defects reported by Coverity Scan for GNU Wget

2016-09-30 Thread Darshit Shah

-- Forwarded message --
From: 
Date: 30 September 2016 at 11:42
Subject: New Defects reported by Coverity Scan for GNU Wget
To: dar...@gmail.com



Hi,

Please find the latest report on new defect(s) introduced to GNU Wget found
with Coverity Scan.

4 new defect(s) introduced to GNU Wget found with Coverity Scan.
4 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 4 of 4 defect(s)


** CID 1363354:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
/src/metalink.c: 971 in ()




*** CID 1363354:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
/src/metalink.c: 971 in ()
965
966   /* Remove prefix drive letters if required, i.e. when in w32
967  environments.  */
968   p = new;
969   while (p[0] != '\0')
970 {
>>> CID 1363354:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
>>> use of "=" where "==" may have been intended
971   while ((n = FILE_SYSTEM_PREFIX_LEN (p)))
972 p += n;
973
974   if (p != new)
975 {
976   while (ISSLASH (p[0]))

** CID 1363353:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
/src/metalink.c: 1015 in ()




*** CID 1363353:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
/src/metalink.c: 1015 in ()
1009
1010   if (!name)
1011 return NULL;
1012
1013   basename = last_component (name);
1014
>>> CID 1363353:  Incorrect expression  (PW.ASSIGN_WHERE_COMPARE_MEANT)
>>> use of "=" where "==" may have been intended
1015   while ((n = FILE_SYSTEM_PREFIX_LEN (basename)))
1016 basename += n;
1017
1018   return metalink_check_safe_path (basename) ? basename : NULL;
1019 }
1020

** CID 1363352:  Control flow issues  (DEADCODE)
/src/metalink.c: 972 in replace_metalink_basename()




*** CID 1363352:  Control flow issues  (DEADCODE)
/src/metalink.c: 972 in replace_metalink_basename()
966   /* Remove prefix drive letters if required, i.e. when in w32
967  environments.  */
968   p = new;
969   while (p[0] != '\0')
970 {
971   while ((n = FILE_SYSTEM_PREFIX_LEN (p)))
>>> CID 1363352:  Control flow issues  (DEADCODE)
>>> Execution cannot reach this statement: "p += n;".
972 p += n;
973
974   if (p != new)
975 {
976   while (ISSLASH (p[0]))
977 ++p;

** CID 1363351:  Control flow issues  (DEADCODE)
/src/metalink.c: 1016 in get_metalink_basename()




*** CID 1363351:  Control flow issues  (DEADCODE)
/src/metalink.c: 1016 in get_metalink_basename()
1010   if (!name)
1011 return NULL;
1012
1013   basename = last_component (name);
1014
1015   while ((n = FILE_SYSTEM_PREFIX_LEN (basename)))
>>> CID 1363351:  Control flow issues  (DEADCODE)
>>> Execution cannot reach this statement: "basename += n;".
1016 basename += n;
1017
1018   return metalink_check_safe_path (basename) ? basename : NULL;
1019 }
1020
1021 /*




To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.
net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-
2Bd2MGckcRZIqiw5BQEQ9vrzwIdaOu6EyzrI-2BoVm-2FEMS-
2BtEEzxnwMw-3D-3D_kmui4qaulLL-2B3aqI2t0AqcRL86AEPYbxN-
2BCgq0zmT00BmekYpSJJUGM33Yx8V8baKh7kRlNSwetdfieonCGGzJ4QYVxH
vfMMGl76aCePsL34gbPPb7dxn4Id1d9deuC9Y7BAxKjjbp-
2FftNVBnHuXVkezFqLRfeG4lq81MODUy-2BMiZj7vctaLyII1IYmfMEzP0imR8H
154WxDDAYuyuuhvg-3D-3D

To manage Coverity Scan email notifications for "dar...@gmail.com", click
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-
2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-
2FA8y06Nq4TvwZ2eDmcOCUJLMeJKuafOsXG7DLig-2B-2FtTyxF8I6BdKjCNNNE0p1fBHEAYJw
xxK4JPbFe1L0xnM-2BlTMyiOorikRvRyowLpuAxiVSoFemksE-3D_kmui4qaulLL-
2B3aqI2t0AqcRL86AEPYbxN-2BCgq0zmT00BmekYpSJJUGM33Yx8V8
baVNeKutSl02CFyJ5s2Gh89FWKoJo430K-2FSUWJN5QbrFwqT6beqV9pm786up9rv-2B-
2B7WeH7unIGYBj8WjyGXB26xYIUWiQSTbtX9lGHKwrEuC3hAUzcretaon-
2FYWNWSKDrufoSireY9nW-2FYOgzJGnOdQA-3D-3D




-- 
Thanking You,
Darshit Shah

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

2016-09-30 Thread Eli Zaretskii

> From: Piotr Wajda 
> Date: Fri, 30 Sep 2016 09:51:37 +0200
> 
> Hi, Reworked recent patch to behave correctly on fg and bg. Now user can 
> switch from fg to bg and vice versa and wget will select fd accordingly.

Thanks.

> +  /* Initialize this values so we don't have to ask every time we print line 
> */
> +  shell_is_interactive = isatty (STDIN_FILENO);

The MS-Windows version of isatty returns non-zero when its argument
file descriptor is open on any character device.  Notably, this
includes the null device, which is definitely not what we want in this
case, I think.

So I think using this logic will need to import isatty from Gnulib, or
provide an alternative implementation in mswindows.c.

>  static void
>  check_redirect_output (void)
>  {
> -  if (redirect_request == RR_REQUESTED)
> +  /* If it was redirected already to log file by SIGHUP or SIGUSR1, it was 
> permanent */
> +  if(!redirect_request_signal_name && shell_is_interactive)
>  {
> -  redirect_request = RR_DONE;
> -  redirect_output ();
> +  if(tcgetpgrp(STDIN_FILENO) != getpgrp()) 

Neither tcgetpgrp nor getpgrp exist on MS-Windows.

AFAIU, this test is intended to check whether wget was backgrounded.
Since AFAIK that's not possible on MS-Windows, this test should always
return zero on Windows, so I suggest a separate predicate function
with 2 implementations: one on Windows, the other on Posix platforms.

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

2016-09-30 Thread Piotr Wajda

Hi, Reworked recent patch to behave correctly on fg and bg. Now user can switch 
from fg to bg and vice versa and wget will select fd accordingly.

Please review.

Thanks
Piotr

---
 src/log.c  | 116 +++--
 src/log.h  |   1 +
 src/main.c |   2 +-
 3 files changed, 76 insertions(+), 43 deletions(-)

diff --git a/src/log.c b/src/log.c
index a1338ca..f93b02c 100644
--- a/src/log.c
+++ b/src/log.c
@@ -80,6 +80,18 @@ as that of the covered work.  */
logging is inhibited, logfp is set back to NULL. */
 static FILE *logfp;
 
+/* Descriptor of the stdout|stderr */
+static FILE *stdlogfp;
+
+/* Descriptor of the wget.log* file (if created) */
+static FILE *filelogfp;
+
+/* Name of log file */
+static char *logfile;
+
+/* Is interactive shell ? */
+static int shell_is_interactive;
+
 /* A second file descriptor pointing to the temporary log file for the
WARC writer.  If WARC writing is disabled, this is NULL.  */
 static FILE *warclogfp;
@@ -611,16 +623,18 @@ log_init (const char *file, bool appendp)
 {
   if (HYPHENP (file))
 {
-  logfp = stdout;
+  stdlogfp = stdout;
+  logfp = stdlogfp;
 }
   else
 {
-  logfp = fopen (file, appendp ? "a" : "w");
+  filelogfp = fopen (file, appendp ? "a" : "w");
   if (!logfp)
 {
   fprintf (stderr, "%s: %s: %s\n", exec_name, file, strerror 
(errno));
   exit (WGET_EXIT_GENERIC_ERROR);
 }
+  logfp = filelogfp;
 }
 }
   else
@@ -631,7 +645,8 @@ log_init (const char *file, bool appendp)
  stderr only if the user actually specifies `-O -'.  He says
  this inconsistency is harder to document, but is overall
  easier on the user.  */
-  logfp = stderr;
+  stdlogfp = stderr;
+  logfp = stdlogfp;
 
   if (1
 #ifdef HAVE_ISATTY
@@ -646,6 +661,9 @@ log_init (const char *file, bool appendp)
   save_context_p = true;
 }
 }
+
+  /* Initialize this values so we don't have to ask every time we print line */
+  shell_is_interactive = isatty (STDIN_FILENO);
 }
 
 /* Close LOGFP (only if we opened it, not if it's stderr), inhibit
@@ -880,59 +898,73 @@ log_cleanup (void)
 
 /* When SIGHUP or SIGUSR1 are received, the output is redirected
elsewhere.  Such redirection is only allowed once. */
-static enum { RR_NONE, RR_REQUESTED, RR_DONE } redirect_request = RR_NONE;
 static const char *redirect_request_signal_name;
 
-/* Redirect output to `wget-log'.  */
+/* Redirect output to `wget-log' or back to stdout/stderr.  */
 
-static void
-redirect_output (void)
+void
+redirect_output (bool to_file, const char *signal_name)
 {
-  char *logfile;
-  logfp = unique_create (DEFAULT_LOGFILE, false, );
-  if (logfp)
+  if(to_file && logfp != filelogfp)
 {
-  fprintf (stderr, _("\n%s received, redirecting output to %s.\n"),
-   redirect_request_signal_name, quote (logfile));
-  xfree (logfile);
-  /* Dump the context output to the newly opened log.  */
-  log_dump_context ();
+  if (signal_name)
+{
+  fprintf(stderr, "\n%s received.", signal_name);
+}
+  if (!filelogfp) 
+{
+  filelogfp = unique_create (DEFAULT_LOGFILE, false, );
+  if (filelogfp)
+{
+  fprintf (stderr, _("\nRedirecting output to %s.\n"),
+  quote (logfile));
+  /* Store signal name to tell wget it's permanent redirect to log 
file */
+  redirect_request_signal_name = signal_name;
+  logfp = filelogfp;
+  /* Dump the context output to the newly opened log.  */
+  log_dump_context ();
+}
+  else
+{
+  /* Eek!  Opening the alternate log file has failed.  Nothing we
+can do but disable printing completely. */
+  fprintf (stderr, _("%s: %s; disabling logging.\n"),
+  (logfile) ? logfile : DEFAULT_LOGFILE, strerror (errno));
+  inhibit_logging = true;
+}
+}
+  else 
+{
+  fprintf (stderr, _("\nRedirecting output to %s.\n"),
+  quote (logfile));
+  logfp = filelogfp;
+  log_dump_context ();
+}
 }
-  else
+  else if (!to_file && logfp != stdlogfp)
 {
-  /* Eek!  Opening the alternate log file has failed.  Nothing we
- can do but disable printing completely. */
-  fprintf (stderr, _("\n%s received.\n"), redirect_request_signal_name);
-  fprintf (stderr, _("%s: %s; disabling logging.\n"),
-   (logfile) ? logfile : DEFAULT_LOGFILE, strerror (errno));
-  inhibit_logging = true;
+  logfp = stdlogfp;
+  log_dump_context ();
 }
-  save_context_p = false;
 }
 
-/* Check whether a signal handler requested the output to be
-   redirected. */
+/* Check whether there's a

Re: [Bug-wget] [PATCH 21/27] New option --metalink-index to process Metalink application/metalink4+xml

Re: [Bug-wget] [PATCH 11/27] Enforce Metalink file name verification, strip directory if necessary

Re: [Bug-wget] wget for windows - current build?

[Bug-wget] wget for windows - current build?

Re: [Bug-wget] Digest Authentication Support in wget

Re: [Bug-wget] Fwd: New Defects reported by Coverity Scan for GNU Wget

[Bug-wget] Fwd: New Defects reported by Coverity Scan for GNU Wget

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

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

9 matches

Site Navigation

Mail list logo

Footer information