Provided by: wget_1.20.3-1ubuntu1_amd64
Wget - The non-interactive network downloader.
wget [option]... [URL]...
GNU Wget is a free utility for non-interactive download of files from the Web. It supports HTTP, HTTPS, and FTP protocols, as well as retrieval through HTTP proxies. Wget is non-interactive, meaning that it can work in the background, while the user is not logged on. This allows you to start a retrieval and disconnect from the system, letting Wget finish the work. By contrast, most of the Web browsers require constant user's presence, which can be a great hindrance when transferring a lot of data. Wget can follow links in HTML, XHTML, and CSS pages, to create local versions of remote web sites, fully recreating the directory structure of the original site. This is sometimes referred to as "recursive downloading." While doing that, Wget respects the Robot Exclusion Standard (/robots.txt). Wget can be instructed to convert the links in downloaded files to point at the local files, for offline viewing. Wget has been designed for robustness over slow or unstable network connections; if a download fails due to a network problem, it will keep retrying until the whole file has been retrieved. If the server supports regetting, it will instruct the server to continue the download from where it left off.
Wget supports proxies for both HTTP and FTP retrievals. The standard way to specify proxy location, which Wget recognizes, is using the following environment variables: http_proxy https_proxy If set, the http_proxy and https_proxy variables should contain the URLs of the proxies for HTTP and HTTPS connections respectively. ftp_proxy This variable should contain the URL of the proxy for FTP connections. It is quite common that http_proxy and ftp_proxy are set to the same URL. no_proxy This variable should contain a comma-separated list of domain extensions proxy should not be used for. For instance, if the value of no_proxy is .mit.edu, proxy will not be used to retrieve documents from MIT.
Wget may return one of several error codes if it encounters problems. 0 No problems occurred. 1 Generic error code. 2 Parse error---for instance, when parsing command-line options, the .wgetrc or .netrc... 3 File I/O error. 4 Network failure. 5 SSL verification failure. 6 Username/password authentication failure. 7 Protocol errors. 8 Server issued an error response. With the exceptions of 0 and 1, the lower-numbered exit codes take precedence over higher- numbered ones, when multiple types of errors are encountered. In versions of Wget prior to 1.12, Wget's exit status tended to be unhelpful and inconsistent. Recursive downloads would virtually always return 0 (success), regardless of any issues encountered, and non-recursive fetches only returned the status corresponding to the most recently-attempted download.
/etc/wgetrc Default location of the global startup file. .wgetrc User startup file.
You are welcome to submit bug reports via the GNU Wget bug tracker (see <https://savannah.gnu.org/bugs/?func=additem&group=wget>) or to our mailing list <email@example.com>. Visit <https://lists.gnu.org/mailman/listinfo/bug-wget> to get more info (how to subscribe, list archives, ...). Before actually submitting a bug report, please try to follow a few simple guidelines. 1. Please try to ascertain that the behavior you see really is a bug. If Wget crashes, it's a bug. If Wget does not behave as documented, it's a bug. If things work strange, but you are not sure about the way they are supposed to work, it might well be a bug, but you might want to double-check the documentation and the mailing lists. 2. Try to repeat the bug in as simple circumstances as possible. E.g. if Wget crashes while downloading wget -rl0 -kKE -t5 --no-proxy http://example.com -o /tmp/log, you should try to see if the crash is repeatable, and if will occur with a simpler set of options. You might even try to start the download at the page where the crash occurred to see if that page somehow triggered the crash. Also, while I will probably be interested to know the contents of your .wgetrc file, just dumping it into the debug message is probably a bad idea. Instead, you should first try to see if the bug repeats with .wgetrc moved out of the way. Only if it turns out that .wgetrc settings affect the bug, mail me the relevant parts of the file. 3. Please start Wget with -d option and send us the resulting output (or relevant parts thereof). If Wget was compiled without debug support, recompile it---it is much easier to trace bugs with debug support on. Note: please make sure to remove any potentially sensitive information from the debug log before sending it to the bug address. The "-d" won't go out of its way to collect sensitive information, but the log will contain a fairly complete transcript of Wget's communication with the server, which may include passwords and pieces of downloaded data. Since the bug address is publicly archived, you may assume that all bug reports are visible to the public. 4. If Wget has crashed, try to run it in a debugger, e.g. "gdb `which wget` core" and type "where" to get the backtrace. This may not work if the system administrator has disabled core files, but it is safe to try.
This is not the complete manual for GNU Wget. For more complete information, including more detailed explanations of some of the options, and a number of commands available for use with .wgetrc files and the -e option, see the GNU Info entry for wget.
Originally written by Hrvoje Nikšić <firstname.lastname@example.org>.
Copyright (c) 1996-2011, 2015, 2018-2019 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".