2 ms·

You are taking my comment a bit too literally (especially since the only thing I was trying to convey was: url files != filesystem files). I don't mean defined

You are taking my comment a bit too literally (especially since the only thing I was trying to convey was: url files != filesystem files). I don't mean defined behavior, I mean what is expected, since that is what you were talking about. 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?

peterwwillis 10y ago
Web browsers have [generally] two settings for saving files: prompt the user, or save automatically. In either case they [generally] save to a "Downloads" folder rather than the home directory. So we can expect whatever happens to happen in the Downloads folder. 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.
- the_why_of_y 10y ago
  > a while back there was a "bug" introduced by systemd. It was mounting a logical filesystem read-write 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=11154041 https://news.ycombinator.com/item?id=11153826 https://news.ycombinator.com/item?id=11153826

peterwwillis 10y ago

Web browsers have [generally] two settings for saving files: prompt the user, or save automatically. In either case they [generally] save to a "Downloads" folder rather than the home directory. So we can expect whatever happens to happen in the Downloads folder. 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.

the_why_of_y 10y ago
> a while back there was a "bug" introduced by systemd. It was mounting a logical filesystem read-write 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=11154041 https://news.ycombinator.com/item?id=11153826 https://news.ycombinator.com/item?id=11153826