e.g. if the url was along the lines of
http://example.com/dl/f3ct4t3c4c3/
The path in a URL is defined as the following (https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) :
A path, which contains data, usually organized in hierarchical form,
that appears as a sequence of segments separated by slashes. Such a
sequence may resemble or map exactly to a file system path, but does not
always imply a relation to one.[9] The path must begin with a single slash
(/) if an authority part was present, and may also if one was not, but must
not begin with a double slash.
Wget has many options which define how file names are created, mainly to better serve in mirroring large complex websites. But in general, whatever the "path" was, the final part of the path will be the file name, or a default one is provided. There are options for enforcing suffixes, creating directory structures recursively, changing accepted character sets for file names, and hundreds more options.
If we go with defined behavior, then wget using the server-provided name just like a web browser does (resolving the redirects, and then explicitly noting that the file is being saved with that new file name), is completely expected, no?
Wget downloads to the current directory by default, which is always the home directory by default unless you change directories first, and Wget almost never prompts the user for where or how to save the file. (I think i've seen Wget give a prompt once under a particularly strange set of circumstances, but that was while mirroring a huge complex site)
As an example of how this changes based on interpretation, a while back there was a "bug" introduced by systemd. It was mounting a logical filesystem read-write, which caused [in some circumstances] whole systems to be bricked due to a bug in some firmware drivers. Systemd's policy was "our software is working fine!" and refused to fix or prevent the behavior, even though the fix would not have negatively affected systemd's operation at all. In the current case, Wget sees the behavior as potentially dangerous and has thus fixed it to prevent people getting fucked over by unexpected behavior.
Another way to look at it: if this was expected, no user would ever download a file without the "-O" option, because to do so would potentially put them at risk.
This is rather misleading. The efivarfs filesystem was mounted by the boot scripts of every Linux distro that supports booting from EFI firmware, because it is the only supported interface to install an EFI bootloader.
> refused to fix or prevent the behavior,
Neither have any of the Linux distros that don't use systemd.
> even though the fix would not have negatively affected systemd's operation at all.
But it would have broken various other tools that system administrators might want to run, as detailed by the author of efivarfs in these comments:
https://news.ycombinator.com/item?id=11154041 https://news.ycombinator.com/item?id=11153826