Re: wget: unable to resolve host address

[Seymour J Metz]

Given that RFCs 3490-3492 came out in 2003 and 5890-5895  came out in 2010, I 
would have expected IDNA support by now. Does anybody know for sure?


From: Bug-wget  on behalf of 
pythonomor...@gmail.com 
Sent: Tuesday, February 8, 2022 1:26 PM
To: bug-wget@gnu.org
Subject: wget: unable to resolve host address

Hello,

I am trying to download from a list of files (jpeg images). The website
utilizes Cyrillic in its URL. I get the following error message: wget:
unable to resolve host address 'xn--h-xubc'

I've checked the links manually and the do work.

I am enclosing a shortened version of the file list.

I've tried different commands to no avail:

wget.exe -i C:\dl_files\url-list.txt --secure-protocol=auto
--remote-encoding=Windows-1251 -nc -c -P C:\dl_files\

I've used Windows-1251 as I did not see a list of encoding names in the
manual 
https://secure-web.cisco.com/1ooTZPy8h-fBRcp0Zjk_hT6tQbv4w0wsk879mz0uB6aG15KQwcB5um7xiytswPhvpEx2CdU9QntWH_SPxAnAAG2ARAaxmvTXfptU_z__MN1SAGF4Sez144I6e5o6wRDx_cSKPXoTDNyplauirv54vbnDS5kLuXXsirRhFl1o3guYaHHwaf3LYbyLEOP1sfTL44_bLjOocvGciGnBwA68K2ME4JREkRcBuegw_-t6YfWN3v9vCCIziBr8G5DQ-u2wZVCytrHEb423jdgKX3xtQJQrfCnNBUT243xpqVx57lS8cbrgaBTxvUOBIKj0Se4FctlqI9ZanNX4VKAbM5laWTi54FjwlpdEqS5p2a-_mHFAGnfVznDud3Ng47NLEw8LBwKlZSNA26ms9KzvmbbG0zDq3PF5CE_nwWxjc01-0kGa2qeRISiPFM58HpVsAG3Pt/https%3A%2F%2Fwww.gnu.org%2Fsoftware%2Fwget%2Fmanual%2Fwget.html%23Wgetrc-Commands

wget.exe -i C:\dl_files\url-list.txt --secure-protocol=auto -nc -c -P
C:\dl_files\



Apparently the problem is caused by Cyrillic characters. I have inkling that
I am not using the correct options for the program.

I would appreciate if you gave me a hint on how to solve the problem.



Regards,

Max

[bug #58877] Unexpected "Redirecting output to 'wget-log'." v1.20.3 regression

[J]

URL:
  

 Summary: Unexpected "Redirecting output to 'wget-log'." 
v1.20.3 regression
 Project: GNU Wget
Submitted by: now3d
Submitted on: Sun 02 Aug 2020 02:24:42 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: 1.20
 Discussion Lock: Any
Operating System: GNU/Linux
 Reproducibility: None
   Fixed Release: None
 Planned Release: None
  Regression: Yes
   Work Required: None
  Patch Included: None

___

Details:

 wget --version
GNU Wget 1.20.3 built on linux-gnu.

Looks like this issue has returned

Unexpected "Redirecting output to 'wget-log'."
https://savannah.gnu.org/bugs/?51181


$ timeout 10s wget --tries=1 --timeout=5 -O pr.txt http://www.google.de >>
pr.log 2>&1


oddly my file pr.log contains

Redirecting output to ‘wget-log.1’.


The wget-log.1 contains all the regular wget output about redirects and
downloaded bytes etc




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

RE: [bug #58354] Wget doesn't parse URIs starting with http:/

[Seymour J Metz]

I've got code for parsing broken URLs at 
http://mason.gmu.edu/~smetz3/source/unobfuscate.zip if that's of any use to 
you. 


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: Bug-wget [bug-wget-bounces+smetz3=gmu@gnu.org] on behalf of Luca 
Bernardi [invalid.nore...@gnu.org]
Sent: Tuesday, May 12, 2020 6:57 AM
To: Luca Bernardi; gscriv...@gnu.org; tim.rueh...@gmx.de; bug-wget@gnu.org; 
dar...@gnu.org
Subject: [bug #58354] Wget doesn't parse URIs starting with http:/

Follow-up Comment #1, bug #58354 (project wget):

PS This bug has happened when trying to crawl a website with default Wordpress
template.

___

Reply to this item at:

  
<https://secure-web.cisco.com/1q_9r4L4Y69ONAuRRi0ugNjuqo2Tj_fFoBQbF5ioU-bnyA1vRNKC2qjgGrGzNsMeAi9WBFuCZq5ZbRgGNcUnwFXhwPut6uzco1g0e7u7DGjIlIzN1O2Kb8A7lcd1hGFvVO2RlJOXPPbaPfPz1vWjpt1lp_MSi15q_ApZl5XAVjS7RRw_8hl0LW1Vlav9F86E8xj6U0j7w1Rb17wjLXaH3YDyCxaR2rYYNb5aMPjo-HUQgiErPIGkmU5OTyscR3nnY5AZZ-gRcgT7fDYF-9BIsYRmM1WK1zcfH5YaUF08mWkkbcQcl4uZEgkb53ewOM5Hc2ze5rHP40EGGXdoHzHZCnFQ-tEzuTrjgYf4u8kaLWS_mLhOUPdnuK0TVTYUcKWVhJJLvOlsmp7YPRnhtDQNzNqDbDLbFFtg7nplUPJo8CIC74qShVvDvMPALoH0UviH4/https%3A%2F%2Fsavannah.gnu.org%2Fbugs%2F%3F58354>

___
  Message sent via Savannah
  
https://secure-web.cisco.com/1t7bdydvsCxBYK2hviWUK34edpVCbTtcc7hvoEjsGxp7TF7YcwxQ4wHZDEeqhx7ckLh33IjhN6G3CTT6UK6Nhhq-1MBzaLtKN3ycAbQu9cLQX_Is4dFUdOLYzPUdtaX4csfyBmvz-h5-D-HjK5ZoEEYyJLkpqwjCVh8FrDCzMX3GPuG7Gc47pGRmt4cAoaa64gi3TWmRF9Rlac3d-3JLYmkzxyBl6DMT_eeYR9YQIZLnWPYhJhdG4367UOEV6eEJPSzbApw6N0xoxr7bE9EhRLs509MOh6MRMnCQPJk6JpDttjn_xSjlybWQzZRlYmm87zlzgsopx_leVwUGOHKtEcCDJqMajmWHC4NDH2M3DPfHGQ5uSYTbaoVmgMMZBuHksYzhBaW8pWLkIYDTAe288H6u12Rr1qbRMeJA6v5UeUTNSgb5ebn2ld1j9hvKPDnN-/https%3A%2F%2Fsavannah.gnu.org%2F

RE: [bug #57884] wget reveals my operating system to the server

[Seymour J Metz]

Which raises far more serious security concerns than reporting browser 
capabilities.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: Bug-wget [bug-wget-bounces+smetz3=gmu@gnu.org] on behalf of Bruno 
Haible [br...@clisp.org]
Sent: Monday, February 24, 2020 6:42 AM
To: ge...@mweb.co.za; Tim Ruehsen
Cc: bug-wget
Subject: Re: [bug #57884] wget reveals my operating system to the server

ge...@mweb.co.za wrote:
> I wonder about the reason given: "To avoid compatibility issues."
> That was - if I recall correctly - the reason for having the string
> to start with: So that servers can format pages to suit the capabilities
> of the browser and version used.

That was how web applications were written 15-20 years ago. 10 years ago, the
browser capabilities are queried by the JavaScript toolkit [1][2]. Nowadays,
they prefer feature detection in JavaScript.

Bruno

[1] 
https://secure-web.cisco.com/1yxilmEYA0e_5D6kvA8W5Cqm4kLz7h7_Ye2VnfxQYqkm9N5qlYZSFt6ngcSYQysbe7ePDJeVOpzlAGq44PHRXdWMlXd6AozIn2B-QQ00LfnnlSynWCurXgcAyVxpnW-4s70vww8NvO8jBboJnb0vcvOoY4Rx_k9ak4zmgPbkDkmRc5OF5X7GXC5Sllh9M_A89zAoTeJ4Q5aHOU5M7io_xkP2-SV1t67Emos6BKN0Eixj9mejKPe27JFKXBVpgIzeXquux9HMR3XLEHe67qd5ojjG8LDkYJmPldP9JAz31DHH-WIJBk3RKoX6JyvOjzZjYCCw8itfdbd_0tS5m157ff-kv08SLGrOIQgjexjO7_zyer_-ihCJubx7krfmWMXGk8wwusXzNU3LtVCyYfDWC5cDJcGIpEP5GQ79aB23QXwkcLkZUEu03lkFPOXOPVWpY/https%3A%2F%2Fdojotoolkit.org%2Freference-guide%2F1.7%2Fquickstart%2Fbrowser-sniffing.html
[2] 
https://secure-web.cisco.com/1cdYJDVpsOUXTFN9ygkgkR4_DBO4vlgE2j2QphPYaQgLlsortmJpgrLdRCbCoQgTsynxSE5GISz85Qp1ck_jjAz0M4hrOQ5CHKVoXqtu11b50PX3AoxjXLI2VeCC_8_G5GHMYQxp32nRo5PYUX3yHcmHZYRjut_xzl7nWNWc4Eb0adTaI1r3raH9dBt1y_yn14Uk5U1Z27FhC_0DLCHG0Hx-mTj4tawa4dcVTUYfG8kXPHWqbvCzOQnITtFd7SCeJhHqcaM88nnVPn6MgmzAYnFkRQYgnj02brU4ODRHpIxCKd9oXc6J9gDoAB7dXs8SDxiLCrd3cyd_fbDRf8BlAlMg8xWvED1-4LV3Juv0xMN-4NIh6W3uBRoAdr6fI0iPO_WoaitaKdbrc852h-5hTjf6bXX7foXMoI8-iGl5IravBl05HyOXrugDaZ8rQ1VlD/https%3A%2F%2Fapi.jquery.com%2FjQuery.browser%2F

Re: [bug #57356] Don't use smart quotes in output messages

[Seymour J Metz]

If the code tailors the delimiters to the local then I see nothing wrong with 
“text” or ‘text’. OTOH, if its hardwired then I agree that only ASCII 
characters should be used.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: Bug-wget  on behalf of anonymous 

Sent: Wednesday, December 4, 2019 10:03 AM
To: gscriv...@gnu.org; tim.rueh...@gmx.de; bug-wget@gnu.org; dar...@gnu.org
Subject: [bug #57356] Don't use smart quotes in output messages

URL:
  
<https://secure-web.cisco.com/1utMRam1wCgY4KgzqUK76rk89f7jO9i0WaMYNWk8gG3F3KjTFkPuSeZvYkNqNfFVfoOIRic-nBDbgMlmKMNtY5IduxnyVzTGVrIrBJ5CyFEUcN_XU6zx899dJxnK7ErFWTymk092zn_lvlNhg-nrFzZI8bV7WKJA1ruhBt6THiyrgx7rB3sVk4qamwzUwL9e_XQo1efeYrp9gtr3ZLlZQdRP8rQgvW-Qa-020Q2nUSOI0CwOySC135xwtHIFX77sjW4ueKsXGYmfbVNLcKodyLIqoXlfPJGjekZPVMQKl-YB5ud90b1r5f_dclGdSrZru9mlcb-FzqTfpLn0A7vltE_uydVkJvUFeWA-bupp6COBHEeURJDT74KB0ymedr58A85GwNIT1VF3MjzYxSWH8aw2ZTk0Rvlb2Req02BoWolu0R8-m06prkbkazI1EVE5H/https%3A%2F%2Fsavannah.gnu.org%2Fbugs%2F%3F57356>

 Summary: Don't use smart quotes in output messages
 Project: GNU Wget
Submitted by: None
Submitted on: Wed 04 Dec 2019 03:03:56 PM UTC
Category: User Interface
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name:
Originator Email:
 Open/Closed: Open
 Discussion Lock: Any
 Release: trunk
Operating System: None
 Reproducibility: Every Time
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: None

___

Details:

The redirect message _Redirecting output to ‘wget-log’_ uses unicode smart
quotes

Expected: use normal typed ' ' quote characters.

programs used by programmers / technical users should NEVER display smart
quotes

1.20.3 homebrew
macOS 10.14.6





___

Reply to this item at:

  
<https://secure-web.cisco.com/1utMRam1wCgY4KgzqUK76rk89f7jO9i0WaMYNWk8gG3F3KjTFkPuSeZvYkNqNfFVfoOIRic-nBDbgMlmKMNtY5IduxnyVzTGVrIrBJ5CyFEUcN_XU6zx899dJxnK7ErFWTymk092zn_lvlNhg-nrFzZI8bV7WKJA1ruhBt6THiyrgx7rB3sVk4qamwzUwL9e_XQo1efeYrp9gtr3ZLlZQdRP8rQgvW-Qa-020Q2nUSOI0CwOySC135xwtHIFX77sjW4ueKsXGYmfbVNLcKodyLIqoXlfPJGjekZPVMQKl-YB5ud90b1r5f_dclGdSrZru9mlcb-FzqTfpLn0A7vltE_uydVkJvUFeWA-bupp6COBHEeURJDT74KB0ymedr58A85GwNIT1VF3MjzYxSWH8aw2ZTk0Rvlb2Req02BoWolu0R8-m06prkbkazI1EVE5H/https%3A%2F%2Fsavannah.gnu.org%2Fbugs%2F%3F57356>

___
  Message sent via Savannah
  
https://secure-web.cisco.com/10dPS8Hx_IFek6cDkUZA2_4xuV-Xwb879Qj9bsZbcB8FdquqsJBXzgKoOM9noUMaEQJOqyLROdefVIohduJnmDWu4hbR82PnnAkCUwb4HMPhtAoxUM_hSUoCpyrqW5eSoYfJbRFk5J1oX2kBbAplwHfk1t6amtyMUky62oLfT3MOSLt2hkAFXfeqp3ZxSsJeVizuYQgH-LzfI17RV2X0ycVNjMerLhpsFSbekX4TIMF2oDNis8xBTF0N0XiME9rZVHZ5F2dF-Y_mspqJCgEPze3iV8590KIZSns-9YE6PpoED7y6M8Dvle5VsS9PoScAf97EUQ0v01jeGODY7syGzC89F0SXRprCCWWUyxlZE2kQO4qkWYHTl7OPhGugJoqcEsJEevFJlu1v4YXA034K7osq0ztGs4CmbAdLaWgPohc2PKADCit89E9JLs808SsTX/https%3A%2F%2Fsavannah.gnu.org%2F

Re: [Bug-wget] Standard cookie file extension

[Seymour J Metz]

RFC 6265 does not define cookie files; the way that a browser stores cookies is 
up to the browser.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: Bug-wget  on behalf of Peng Yu 

Sent: Wednesday, October 23, 2019 9:49 AM
To: bug-wget
Subject: [Bug-wget] Standard cookie file extension

Hi, I am wondering if there is a standard cookie file extension for
cookie files written by wget. So far, I only see filenames like
cookie.txt cookies.txt. So the extension is just .txt. But .txt is not
a specific extension for cookie files. I'd like an extension dedicated
to cookie files for disambignuity purposes. Thanks.

--
Regards,
Peng

[Bug-wget] [bug #54826] too much output on wget --version

[J]

Follow-up Comment #6, bug #54826 (project wget):

Good link, thank you.

at least wget2 --version doesn't have this. Let's hope no one adds it to
wget2! ;-)

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54825] unexpected wget appends .1 after the file extension

[J]

Follow-up Comment #7, bug #54825 (project wget):

Fair enough.

I would probably use the opportunity for wget2 to be more evolutionary, and
adopt some new defaults. Old users could of course use old behavours.

This is a bit like when G++ changes the default C++ language spec to compile
against. Can't hang on with old things for ever..

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54826] too much output on wget --version

[J]

Follow-up Comment #4, bug #54826 (project wget):

There is no reason to cling to old output, just because it was put that way
~10 years ago.

Evolution, and rationalisation are vital for software. Unfortunately in
software engineering there are engineers unwilling to change, that really
holds back a lot of packages. 


Look what happened when GCC wouldn't open up, that came back together as
2.95.

Again, look what happen when GCC again wouldn't open up. LLVM was born.

I've said my piece - I'm always positive about improving software :)

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54825] unexpected wget appends .1 after the file extension

[J]

Follow-up Comment #5, bug #54825 (project wget):

That is good. 
As wget2 is new, maybe it can be revolutionary and adopt that as default?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54825] unexpected wget appends .1 after the file extension

[J]

Follow-up Comment #2, bug #54825 (project wget):

Thank you for your reply. Will check out wget2

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54826] too much output on wget --version

[J]

Follow-up Comment #2, bug #54826 (project wget):

wget is a user application. No other GNU package clutters the --version output
in such a manner. What's the rationale for dumping the build config into the
--version output? I can't see any valid reason to keep build config output
there.

jonny@asus:~$ gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

jonny@asus:~$ bash --version
GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
Copyright © 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
jonny@asus:~$ ls --version
ls (GNU coreutils) 8.28
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard M. Stallman and David MacKenzie.
jonny@asus:~$ cp --version
cp (GNU coreutils) 8.28
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjorn Granlund, David MacKenzie and Jim Meyering.
jonny@asus:~$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.30
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public Licence version 3 or (at your option) a later version.
This program has absolutely no warranty.
jonny@asus:~$ 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54828] wget stalled download shows wrong speed per second

[J]

URL:
  

 Summary: wget stalled download shows wrong speed per second
 Project: GNU Wget
Submitted by: now3d
Submitted on: Fri 12 Oct 2018 11:17:23 AM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.19.4
Operating System: None
 Reproducibility: None
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: None

___

Details:

wget, where download stalls, display is stuck on "1.32MB/s" you can see below.
It should probably say "0MB/s (stalled)" ?

it could probably also have a second counter, as it is ambiguous it is
stalled, which lasts several minutes until it retries.

Also I am surprised it says "(Success)" after a read error, can that be
removed or replaced with "(Partial)"

I've obscured the URL, but you can use your own test case to reproduce.



$ wget https://www.mydomain123.com/tmp/mydomain123.zip
--2018-10-12 10:49:39--  https://www.mydomain123.com/tmp/mydomain123.zip
Resolving www.mydomain123.com (www.mydomain123.com)... 12.34.56.78
Connecting to www.mydomain123.com (www.mydomain123.com)|12.34.56.78|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 4954873 (4.7M) [application/zip]
Saving to: ‘mydomain123.zip’

mydomain123  57%[==> ]   2.72M  1.40MB/sin 1.9s

2018-10-12 11:04:41 (1.40 MB/s) - Read error at byte 2850816/4954873
(Success). Retrying.

--2018-10-12 11:04:42--  (try: 2) 
https://www.mydomain123.com/tmp/mydomain123.zip
Connecting to www.mydomain123.com (www.mydomain123.com)|12.34.56.78|:443...
connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 4954873 (4.7M), 2104057 (2.0M) remaining [application/zip]
Saving to: ‘mydomain123.zip’

mydomain123 100%[+++>]   4.72M  1.37MB/sin 1.5s

2018-10-12 11:04:44 (1.37 MB/s) - ‘mydomain123.zip’ saved
[4954873/4954873]

$ 




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54826] too much output on wget --version

[J]

URL:
  

 Summary: too much output on wget --version
 Project: GNU Wget
Submitted by: now3d
Submitted on: Fri 12 Oct 2018 09:55:35 AM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.19.4
Operating System: None
 Reproducibility: None
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: None

___

Details:

Hello

I noticed contary to other GNU tools, wget --version has a lot of extra output
about the compiler build. Can that be removed?

If needed, wget --build-info could be added?

Thanks, Jonny


$ wget --version
GNU Wget 1.19.4 built on linux-gnu.

-cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls 
+ntlm +opie +psl +ssl/openssl 

Wgetrc: 
/etc/wgetrc (system)
Locale: 
/usr/share/locale 
Compile: 
gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc" 
-DLOCALEDIR="/usr/share/locale" -I. -I../../src -I../lib 
-I../../lib -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_LIBSSL -DNDEBUG 
-g -O2 -fdebug-prefix-map=/build/wget-LB8XFP/wget-1.19.4=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall 
Link: 
gcc -DHAVE_LIBSSL -DNDEBUG -g -O2 
-fdebug-prefix-map=/build/wget-LB8XFP/wget-1.19.4=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall -Wl,-Bsymbolic-functions 
-Wl,-z,relro -Wl,-z,now -lpcre -luuid -lidn2 -lssl -lcrypto -lpsl 
ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a 

Copyright (C) 2015 Free Software Foundation, Inc.
Licence GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic .
Please send bug reports and questions to .





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54825] unexpected wget appends .1 after the file extension

[J]

URL:
  

 Summary: unexpected wget appends .1 after the file extension
 Project: GNU Wget
Submitted by: now3d
Submitted on: Fri 12 Oct 2018 09:54:13 AM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.19.4
Operating System: GNU/Linux
 Reproducibility: None
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: None

___

Details:

Hello

Can wget not append the .1 after the file extension? It means manual changes
are needed by the user. If Firefox or Chrome downloads the same file twice, it
does not do this.

GNU Wget 1.19.4 built on linux-gnu.
ubuntu


2018-10-12 10:49:24 (582 KB/s) - ‘e.zip.1’ saved [491905/491905]





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54178] wget sometimes returns 1024

[J]

Follow-up Comment #8, bug #54178 (project wget):

Thank you for your reply

ok, let's close this ticket. Not sure how to do that though.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54178] wget sometimes returns 1024

[J]

Follow-up Comment #6, bug #54178 (project wget):

Hi David

Thank you for you message, I will use WEXITSTATUS(result) as you describe.

BTW, I noticed my Ubuntu LTS machine man page for system(3) looks quite
different from yours. I wonder if you are not running GNU/Linux?


RETURN VALUE
   The return value of system() is one of the following:

   *  If command is NULL, then a nonzero value if a shell is available,
or
  0 if no shell is available.

   *  If a child process could not be created, or its status could not 
be
  retrieved, the return value is -1.

   *  If  a  shell  could  not  be executed in the child process, then
the
  return value is as though the  child  shell  terminated  by 
calling
  _exit(2) with the status 127.

   *  If  all  system calls succeed, then the return value is the
termina‐
  tion status of the child shell used to execute command.  (The
termi‐
  nation  status of a shell is the termination status of the last
com‐
  mand it executes.)

   In the last two cases, the return value is a "wait status" that can 
be
   examined using the macros described in waitpid(2).  (i.e.,
WIFEXITED(),
   WEXITSTATUS(), and so on).

   system() does not affect the wait status of any other children.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54178] wget sometimes returns 1024

[J]

Follow-up Comment #4, bug #54178 (project wget):

Hi
I've attached C code example which invokes "wget". I think you are right, the
system() syscall invokes a shell, which invokes wget.. that seems to fork()
which is probably why the result is shifted 8bits

(file #44468)
___

Additional Item Attachment:

File name: wget2.cSize:0 KB


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54178] wget sometimes returns 1024

[J]

Follow-up Comment #1, bug #54178 (project wget):

$ wget --version
GNU Wget 1.19.4 built on linux-gnu.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #54178] wget sometimes returns 1024

[J]

URL:
  

 Summary: wget sometimes returns 1024
 Project: GNU Wget
Submitted by: now3d
Submitted on: Sun 24 Jun 2018 06:48:09 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
Operating System: None
 Reproducibility: None
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: None

___

Details:

When wget can't connect to a server, it would appear it is returning 1024 to
bash. Note the site exists, but has no web server, shouldn't wget retur (0)
for success and (1) for an error?

--2018-06-24 15:29:32--  http://beflirty.com/
Resolving beflirty.com (beflirty.com)... failed: Name or service not known.
wget: unable to resolve host address ‘beflirty.com’





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #51181] Unexpected "Redirecting output to 'wget-log'."

[J]

Follow-up Comment #15, bug #51181 (project wget):

Hi Tim
I could not get your code to compile.


My simpler C version of my test case below

What I woudl suggest is, could this be added to wget testsuite? some
additional tests

//gcc -O2 -Wall -Wextra -Wpedantic -o main wget_main.c
#include  
int main (void) 
{ 
const char * str = "timeout -k 26s 25s wget http://bbc.com/;; 
int result = system(str);
 
return result; 
}




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #51181] Unexpected "Redirecting output to 'wget-log'."

[J]

Follow-up Comment #10, bug #51181 (project wget):

Hi Peter

Ok, sorry my example was bad. This is my actual example below.

This program reproduces the issue

jonny@asus:~/code$ g++ -O2 -Wall -Wextra -Wpedantic -o main main3.cpp
jonny@asus:~/code$ ./main

Redirecting output to ‘wget-log.2’.
jonny@asus:~/code$ 





//g++ -O2 -Wall -Wextra -Wpedantic -o main main.c

#include 
#include 
#include 

int main (void)
{
std::string str = "timeout -k 26s 25s wget --output-document dump.html
http://TajInternational.com/;;

int result = system(str.c_str());

return result;
}

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #51181] Unexpected "Redirecting output to 'wget-log'."

[J]

Follow-up Comment #8, bug #51181 (project wget):

Hi Peter Wu

I'm using Latest ubuntu LTS, which shows version 1.19.4. Logs below. Is it
something to do with '&' ampersand in a URL?



$ dpkg -l |grep wget
ii  wget  1.19.4-1ubuntu2.1 

$ wget --version
GNU Wget 1.19.4 built on linux-gnu.


$ wget https://uk.godaddy.com/dpp
[1] 5080

Redirecting output to ‘wget-log.3’.

Command 'key' not found, but can be installed with:

sudo apt install donkey

jonny@asus:~/test$ 




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #51181] Unexpected "Redirecting output to 'wget-log'."

[J]

Follow-up Comment #6, bug #51181 (project wget):

Issue reproduced 1.19.4 on Ubuntu

Any news when fix will be released please?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Bug-wget] [bug #52503] fails to try all available IP addresses

[Brian J. Murrell]

Follow-up Comment #3, bug #52503 (project wget):

My apologies.  This is on the LEDE embedded router platform and indeed, the
wget on it is actually libuclient.

I should have looked more closely.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [Bug-wget] VBScript and Task Manager

[D'Amato, Paul J.]

Thank you Alex for your response.

I modified the run WshShell.Run command as suggested. Thank you!
I confirmed that the CurrentDirectory is what I expect. It is the location of 
the script and the wget executable.

I was able to get wget to run from the task scheduler outside of the vbscript.
I was able to do this utilizing the Start In option.
I applied this to the vbscript task and the task completed!


Thanks to everyone on the wget bug team for your assistance.

Paul

-Original Message-
From: gnfa...@rambler.ru [mailto:gnfa...@rambler.ru] 
Sent: Wednesday, April 16, 2014 12:02 PM
To: D'Amato, Paul J.
Cc: bug-wget@gnu.org
Subject: Re: Re: [Bug-wget] VBScript and Task Manager

Greetings, D'Amato, Paul J
1st You didn't need loop for waiting download. It can cause error because wget 
create file immediately. WshShell.Run has WaitOnReturn parametr. So You can try 
something like WshShell.Run runWget , 0, True
2nd Possible variant - please check value of WshShell.CurrentDirectory 
property. When You lauch script manually, it start from it directory. Sheduler 
lauch script from some system directory. You can or assign value to 
WshShell.CurrentDirectory (WshShell.CurrentDirectory = currentDirectory) or 
(may be better) use -P wget option.
Best regards, Alex



The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Bug-wget] VBScript and Task Manager

[D'Amato, Paul J.]

I have a vbscript that downloads two files using wget.
When I run the vbscript the files download and wget performs as expected.
I need this to happen daily, so I created a Task in the Task Scheduler.
When the vbscript runs from the task scheduler, the script stops on the first 
wget run command.

Do you have any advice to for WGET to work in this scenario?

Thank you,

Paul D'Amato
Partners Healthcare IS
Software Engineer
781-416-8614



The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Bug-wget] Source synchronization

[J. Maxwell]

Hello,

The PC world.

I have used 'wget' over several days to download a multi-gigabyte 
database. Now the administrators of the DB would update files, which 
wget can track, by modification dates I presume. However when they 
delete files, 'orphaned' files are left on the destination system. Is 
there some method for continuously synchronizing the destination 
directories with the source directories as the reference normal source?


Something like rsync in the UNIX world!

Thanks

[Bug-wget] Prob: w/ Invalid Argument message

[J. Maxwell]

Hello,

I am setting up wGet on an XP Windows platform for downloading a 
database, once established I'll attempt to mirror it.

The command line I have supplied is as follows:

C:\Documents and Settings\user C:\Program Files\GnuWin32\bin\wget.exe 
-N -c -S -r -l 0 -k -p -w 1 -x -t 0 -np -A * --preserve-permissions 
--user=anonymous --password=u...@mydomain.com -P I:\host_stuff\ -o 
I:\Logs\wGet\ ftp://ftp.host.domain.com/dir1/db/;


Stdout =
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files\GnuWin32/etc/wgetrc
--2011-06-05 19:47:57--  http://.texlive2010/
Resolving .texlive2010... failed: Host not found.
C:\Program Files\GnuWin32\bin\wget: unable to resolve host address 
`.texlive2010

'
--2011-06-05 19:48:00--  http://.virtualbox/
Resolving .virtualbox... failed: Host not found.



/Process attempts to resolve a long list of all folders and 
files in my C:\Documents and Settings\user folder

   Then it eventually gets to the host's URL
/
--2011-06-05 19:53:50--  ftp://ftp.host.domain.com/dir1/db/
   = `I:/host_stuff -o 
I:/Logs/wGet/ftp.host.domain.com/dir1/db/.listing'

Resolving ftp.host.domain.com... xxx.xxx.xxx.xxx
Connecting to ftp.host.domain.com|xxx.xxx.xxx.xxx|:21... connected.
Logging in as anonymous ...
220-
 Warning Notice!



230 Anonymous access granted, restrictions apply.
-- SYST

215 UNIX Type: L8
-- PWD

257 / is current directory.
-- TYPE I

200 Type set to I
-- CWD /dir1/db

250 CWD command successful
-- PASV

227 Entering Passive Mode (xxx,xxx,xxx,xxx,196,77)
-- LIST -a

150 Opening ASCII mode data connection for file list
I:/host_stuff -o I:/Logs/wGet/ftp.host.domain.com/dir1/db: Invalid 
argumentI:/host_stuff -o 
I:/Logs/wGet/ftp.host.domain.com/dir1/db/.listing: Invalid argument

unlink: Invalid argument

Then process dies and returns the shell prompt.
One thing that I have noticed is that I entered the directory format for 
the C:\, and I:\ directories in Microsoft's format with \ but Stdout 
spit them back out in UNIX syntax when it complains of Invalid arguments.
I also changed the wgetrc file in both the bin and the etc directories 
to .wgetrc and added default parameters to them, returned them to 
original MT state also.


Hopefully, someone can tell me where I am messing up.

Thanks!