3 ms·

What? That's been in for a few releases! To trigger it, enter a single-quote, then paste the URL, then close the quote once you're done. We don't attempt to d

by faho 8y ago

What? That's been in for a few releases! To trigger it, enter a single-quote, then paste the URL, then close the quote once you're done. We don't attempt to detect URLs because that can go wrong, and because we don't know your intention. So we use the fact that you're inside single-quotes as the signifier that we should escape things - which also allows this to be used for e.g. pasting shellscript as a literal argument.

ElijahLynn 8y ago
I think the post is wanting it to be handled automatically, without having to quote it, that was the intent I got from it. But yeah, I have had a ton of issues where commands fail because I didn't quote URLs, and in the beginning it wasn't as obvious as it is now. I don't have a solution, just saying that this does add friction for newcomers.
darkpuma 8y ago
There must be a disconnect here, manually entering a single quote, then pasting my URL, then adding the closing quote is precisely what I wish to avoid. Here is a demonstration about what I'm talking about: https://i.imgur.com/d64lwaB.mp4 https://i.imgur.com/d64lwaB.mp4 > "We don't attempt to detect URLs because that can go wrong, and because we don't know your intention." That much I've gathered from seeing this issue raised with fish people in the past, and in my humble opinion it's the wrong approach. In this mentality fish is forgetting it's stated goal of being user friendly which should in some cases, mean making sane educated guesses about the user's intent. How often do users of the fish shell paste a string that starts with 'http' and contains a '?' that is meant to be a wildcard? Not very often at all, if ever; fish is now evidently planning on deprecating that ? wildcard so I think the fish devs agree! The way I see it traditional shells aren't user friendly because they take a conservative approach, doing crap like not enabling fancy autocompletion features out of the box because "what if the user is running on a timesharing PDP-11 and can't spare the CPU cycles?" Breaking from that mental trap is bold and should be commended, but in the case of not escaping pastes I think fish has fallen into that conservative mindset again. zsh/OMZ does it by default and I've never heard of anybody getting screwed over because of it. Fish could and should do it by default too.
- faho 8y ago
  > How often do users of the fish shell paste a string that starts with 'http' and contains a '?' that is meant to be a wildcard? Okay. Now you can do it for http. What about ftp? Or "file://"? Do we detect _all_ kinds of URLs? And even if we do, and we don't miss some or see something as a URL that isn't, what about _other_ kinds of things? What about shellscript? E.g. if I want to just execute a bash one-liner from the internet, I can do `bash -c '` and paste it and it'll work out. That won't be detected as a URL, because it isn't one. And I've seen a case of a URL with variables just yesterday (though I admit that's a coincidence): https://docs.travis-ci.com/user/deployment/custom/ https://docs.travis-ci.com/user/deployment/custom/ has "sftp://${SFTP_USER}:${SFTP_PASSWORD}@example.com/directory/filename". How do I paste that with the zsh thing? Do I need to go back and edit all of that? So, instead, we have one rule: If you paste it insde single-quotes, it'll be escaped. If you paste it outside, it'll be inserted as-is (but still not executed). No matter what the contents, no matter where.
  - darkpuma 8y ago
    > Okay. Now you can do it for http. What about ftp? Or "file://"? Do we detect _all_ kinds of URLs? Some is better than none, that's the lesson learned from OMZ's implementation of this feature. It doesn't cover every single scenario, but it covers enough to make people's lives easier in the common cases. That is the sort of bold decision making that the fish developers should be doing. `bash -c '` sftp://${SFTP_USER}:${SFTP_PASSWORD}@example.com/directory/filename Both of these get pasted unchanged in zsh. I suggest you try it out. But more to your point, this would get improperly escaped: http://${SFTP_USER}:${SFTP_PASSWORD}@example.com/directory/filename And you know what? That's fine. Because whether you choose to auto-escape or not, something will break. The question you and the fish developers should be asking is which is more likely? Auto-escaping works the vast majority of the time and only fails some of the time. And when it fail in the rare case, the UX is no worse than when it fails in the common case. >"If you paste it insde single-quotes, it'll be escaped." First of all, that's not what I see. Maybe you're talking about bracketed paste mode or something that's invisible to the user, but when I paste a URL containing wildcards into single quotes in fish, I don't see any escaping taking place. I assume single quotes are the "verbatim quotes", e.g. `ls '*.txt'` doesn't show you all txt files because that wildcard isn't expanded inside those single quotes. With that in mind, it's not clear to me why a string pasted into single quotes should be escaped, it doesn't need escaping and I don't see any escaping being done when I try it out myself. There's nothing magic about making `mpv 'https://www.youtube.com/watch?v=LBoF1e5YDdQ'` https://www.youtube.com/watch?v=LBoF1e5YDdQ'` work. Dumb old bash accepts that too.
h1d 8y ago
How can detecting URL go wrong? It starts with an obvious prefix and ends at a line end or a space. If the URL contained a space that is not URL encoded, that would be user's fault.
- em-bee 8y ago
  it's not as obvious as it looks. maybe someone wants to construct urls like this: wget http://example.com/files/(basename -s .jpg *.jpg).png but ( is a legal character in urls, so fish can't possibly predict which use is desired.

by faho 8y ago

ElijahLynn 8y ago

I think the post is wanting it to be handled automatically, without having to quote it, that was the intent I got from it. But yeah, I have had a ton of issues where commands fail because I didn't quote URLs, and in the beginning it wasn't as obvious as it is now. I don't have a solution, just saying that this does add friction for newcomers.

darkpuma 8y ago

There must be a disconnect here, manually entering a single quote, then pasting my URL, then adding the closing quote is precisely what I wish to avoid. Here is a demonstration about what I'm talking about: https://i.imgur.com/d64lwaB.mp4 https://i.imgur.com/d64lwaB.mp4 > "We don't attempt to detect URLs because that can go wrong, and because we don't know your intention." That much I've gathered from seeing this issue raised with fish people in the past, and in my humble opinion it's the wrong approach. In this mentality fish is forgetting it's stated goal of being user friendly which should in some cases, mean making sane educated guesses about the user's intent. How often do users of the fish shell paste a string that starts with 'http' and contains a '?' that is meant to be a wildcard? Not very often at all, if ever; fish is now evidently planning on deprecating that ? wildcard so I think the fish devs agree! The way I see it traditional shells aren't user friendly because they take a conservative approach, doing crap like not enabling fancy autocompletion features out of the box because "what if the user is running on a timesharing PDP-11 and can't spare the CPU cycles?" Breaking from that mental trap is bold and should be commended, but in the case of not escaping pastes I think fish has fallen into that conservative mindset again. zsh/OMZ does it by default and I've never heard of anybody getting screwed over because of it. Fish could and should do it by default too.

faho 8y ago
> How often do users of the fish shell paste a string that starts with 'http' and contains a '?' that is meant to be a wildcard? Okay. Now you can do it for http. What about ftp? Or "file://"? Do we detect _all_ kinds of URLs? And even if we do, and we don't miss some or see something as a URL that isn't, what about _other_ kinds of things? What about shellscript? E.g. if I want to just execute a bash one-liner from the internet, I can do `bash -c '` and paste it and it'll work out. That won't be detected as a URL, because it isn't one. And I've seen a case of a URL with variables just yesterday (though I admit that's a coincidence): https://docs.travis-ci.com/user/deployment/custom/ https://docs.travis-ci.com/user/deployment/custom/ has "sftp://${SFTP_USER}:${SFTP_PASSWORD}@example.com/directory/filename". How do I paste that with the zsh thing? Do I need to go back and edit all of that? So, instead, we have one rule: If you paste it insde single-quotes, it'll be escaped. If you paste it outside, it'll be inserted as-is (but still not executed). No matter what the contents, no matter where.
- darkpuma 8y ago
  > Okay. Now you can do it for http. What about ftp? Or "file://"? Do we detect _all_ kinds of URLs? Some is better than none, that's the lesson learned from OMZ's implementation of this feature. It doesn't cover every single scenario, but it covers enough to make people's lives easier in the common cases. That is the sort of bold decision making that the fish developers should be doing. `bash -c '` sftp://${SFTP_USER}:${SFTP_PASSWORD}@example.com/directory/filename Both of these get pasted unchanged in zsh. I suggest you try it out. But more to your point, this would get improperly escaped: http://${SFTP_USER}:${SFTP_PASSWORD}@example.com/directory/filename And you know what? That's fine. Because whether you choose to auto-escape or not, something will break. The question you and the fish developers should be asking is which is more likely? Auto-escaping works the vast majority of the time and only fails some of the time. And when it fail in the rare case, the UX is no worse than when it fails in the common case. >"If you paste it insde single-quotes, it'll be escaped." First of all, that's not what I see. Maybe you're talking about bracketed paste mode or something that's invisible to the user, but when I paste a URL containing wildcards into single quotes in fish, I don't see any escaping taking place. I assume single quotes are the "verbatim quotes", e.g. `ls '*.txt'` doesn't show you all txt files because that wildcard isn't expanded inside those single quotes. With that in mind, it's not clear to me why a string pasted into single quotes should be escaped, it doesn't need escaping and I don't see any escaping being done when I try it out myself. There's nothing magic about making `mpv 'https://www.youtube.com/watch?v=LBoF1e5YDdQ'` https://www.youtube.com/watch?v=LBoF1e5YDdQ'` work. Dumb old bash accepts that too.

h1d 8y ago

How can detecting URL go wrong? It starts with an obvious prefix and ends at a line end or a space. If the URL contained a space that is not URL encoded, that would be user's fault.

em-bee 8y ago
it's not as obvious as it looks. maybe someone wants to construct urls like this: wget http://example.com/files/(basename -s .jpg *.jpg).png but ( is a legal character in urls, so fish can't possibly predict which use is desired.