3 ms·

> 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 ht

by 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.
- faho 8y ago
  >Some is better than none, that's the lesson learned from OMZ's implementation of this feature. I disagree. I'd rather have predictability here. >when I paste a URL containing wildcards into single quotes in fish, I don't see any escaping taking place. That's because you've not pasted anything that needs escaping. In single-quotes, only single-quotes and backslashes are special, and they are escaped. Even if you paste script that itself contains single-quotes, it'll work.
  - darkpuma 8y ago
    The truly unpredictable UX is when a noob tries to paste a youtube url into their shell and gets a bewildering error message about a wildcard (and the error message carrot doesn't even point at the guilty wildcard!) That is very far from the behavior the user was predicting, unless they've been around the shell block a few times already (in which case they could probably make due in a shittier shell anyway. Is fish optimizing for 'user friendly' or 'user friendly for experiences users'?)
    - faho 8y ago
      >The truly unpredictable UX is when a noob tries to paste Yes, and you've not solved that. You've only solved that one special edge-case where they're pasting "a youtube url". This only pushes the confusing bit further along, and adds some more cruft on top! Quoting is a fact in shells. The way these languages work is through loads of string interpolation, so you kinda need to learn that. And I'd prefer to make the rules there simple than add special cases for URLs.
      - darkpuma 8y ago
        That "one special edge-case" is easily the most common case by far. Your dismissive attitude towards this is antithetical to the design of user friendly software. Even when the noob manages to learn that ? is a deprecated but still present wildcard in fish, they'll still be left with the unfortunate reality of being forced to manually quote their urls each and every time, until either fish fixes this or until they switch to zsh (where complaints about url escaping inconsistency don't seem to come up very often at all despite your reasoning.) Here is an idea to improve the UX that zsh currently offers: use bracketed paste mode and prompt the user whenever they paste something that looks like a URL, asking if they'd like it to be escaped/quoted. y[enter] or n[enter] after the paste is much nicer than remembering to press ' before you paste and then pressing it again after you paste.

by faho 8y ago

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.

faho 8y ago
>Some is better than none, that's the lesson learned from OMZ's implementation of this feature. I disagree. I'd rather have predictability here. >when I paste a URL containing wildcards into single quotes in fish, I don't see any escaping taking place. That's because you've not pasted anything that needs escaping. In single-quotes, only single-quotes and backslashes are special, and they are escaped. Even if you paste script that itself contains single-quotes, it'll work.
- darkpuma 8y ago
  The truly unpredictable UX is when a noob tries to paste a youtube url into their shell and gets a bewildering error message about a wildcard (and the error message carrot doesn't even point at the guilty wildcard!) That is very far from the behavior the user was predicting, unless they've been around the shell block a few times already (in which case they could probably make due in a shittier shell anyway. Is fish optimizing for 'user friendly' or 'user friendly for experiences users'?)
  - faho 8y ago
    >The truly unpredictable UX is when a noob tries to paste Yes, and you've not solved that. You've only solved that one special edge-case where they're pasting "a youtube url". This only pushes the confusing bit further along, and adds some more cruft on top! Quoting is a fact in shells. The way these languages work is through loads of string interpolation, so you kinda need to learn that. And I'd prefer to make the rules there simple than add special cases for URLs.
    - darkpuma 8y ago
      That "one special edge-case" is easily the most common case by far. Your dismissive attitude towards this is antithetical to the design of user friendly software. Even when the noob manages to learn that ? is a deprecated but still present wildcard in fish, they'll still be left with the unfortunate reality of being forced to manually quote their urls each and every time, until either fish fixes this or until they switch to zsh (where complaints about url escaping inconsistency don't seem to come up very often at all despite your reasoning.) Here is an idea to improve the UX that zsh currently offers: use bracketed paste mode and prompt the user whenever they paste something that looks like a URL, asking if they'd like it to be escaped/quoted. y[enter] or n[enter] after the paste is much nicer than remembering to press ' before you paste and then pressing it again after you paste.