3 ms·

eh, the path the url contains isn't a file system path, its a string of characters that a server can treat in a million different ways, so its not exactly pract

eh, the path the url contains isn't a file system path, its a string of characters that a server can treat in a million different ways, so its not exactly practical to rely on that e.g. if the url was along the lines of http://example.com/dl/f3ct4t3c4c3/ what do you expect the file name to be?

peterwwillis 10y ago
"index.html", as Wget creates a default name (defined by the "default-page" option) when you download a directory path using HTTP. The path in a URL is defined as the following (https://en.wikipedia.org/wiki/Uniform_Resource_Identifier 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. You can rely on the path to be made up of parts that will not begin with a double slash, and will be separated by slashes, and be defined by a specific character set. URLs also contain a query and a fragment after the path, and the client can choose whether to keep those in the file name or not. 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.
- RubyPinch 10y ago
  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

"index.html", as Wget creates a default name (defined by the "default-page" option) when you download a directory path using HTTP. The path in a URL is defined as the following (https://en.wikipedia.org/wiki/Uniform_Resource_Identifier 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. You can rely on the path to be made up of parts that will not begin with a double slash, and will be separated by slashes, and be defined by a specific character set. URLs also contain a query and a fragment after the path, and the client can choose whether to keep those in the file name or not. 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.

RubyPinch 10y ago
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