Another way to specify username and password is in the url itself
(see URL Format). Either method reveals your password to anyone who
bothers to run ps
. To prevent the passwords from being seen,
store them in .wgetrc or .netrc, and make sure to protect
those files from other users with chmod
. If the passwords are
really important, do not leave them lying in those files either—edit
the files and delete them after Wget has started the download.
Note that even though Wget writes to a known filename for this file,
this is not a security hole in the scenario of a user making
.listing a symbolic link to /etc/passwd or something and
asking root
to run Wget in his or her directory. Depending on
the options used, either Wget will refuse to write to .listing,
making the globbing/recursion/time-stamping operation fail, or the
symbolic link will be deleted and replaced with the actual
.listing file, or the listing will be written to a
.listing.number file.
Even though this situation isn't a problem, though, root
should
never run Wget in a non-trusted user's directory. A user could do
something as simple as linking index.html to /etc/passwd
and asking root
to run Wget with -N or -r so the file
will be overwritten.
wget ftp://gnjilux.srk.fer.hr/*.msg
By default, globbing will be turned on if the url contains a globbing character. This option may be used to turn globbing on or off permanently.
You may have to quote the url to protect it from being expanded by
your shell. Globbing makes Wget look for a directory listing, which is
system-specific. This is why it currently works only with Unix ftp
servers (and the ones emulating Unix ls
output).
If the machine is connected to the Internet directly, both passive and
active FTP should work equally well. Behind most firewall and NAT
configurations passive FTP has a better chance of working. However,
in some rare firewall configurations, active FTP actually works when
passive FTP doesn't. If you suspect this to be the case, use this
option, or set passive_ftp=off
in your init file.
When --retr-symlinks is specified, however, symbolic links are traversed and the pointed-to files are retrieved. At this time, this option does not cause Wget to traverse symlinks to directories and recurse through them, but in the future it should be enhanced to do this.
Note that when retrieving a file (not a directory) because it was specified on the command-line, rather than because it was recursed to, this option has no effect. Symbolic links are always traversed in this case.
This option is useful when, for some reason, persistent (keep-alive) connections don't work for you, for example due to a server bug or due to the inability of server-side scripts to cope with the connections.