Hacker News new | past | comments | ask | show | jobs | submit login

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.




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

> "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.


> 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/ 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.


> 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'` work. Dumb old bash accepts that too.


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


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'?)


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


[flagged]


> Your dismissive attitude towards this is antithetical to the design of user friendly software

And your dismissive attitude of the project's own design goals is antithetical to the notion that not everybody has the same priorities as you, nor do they think your personal ideas equate to "the design of user friendly software".

The principle of "no surprises" is probably the greatest aspect of "user friendly software" when it comes to power tools such as shells, scripting languages, programming languages, etc. and that seems to be what GP is stating as preferable to edge-case scenario surprises.

You may disagree all you like with that as a priority, but please don't go to the extreme of stating that someone is being dismissive simply because they don't hold your idea up on a golden plinth above their own.


>The principle of "no surprises"

Is violated by this:

    > mpv https://www.youtube.com/watch?v=LBoF1e5YDdQ
    fish: No matches for wildcard 'https://www.youtube.com/watch?v=LBoF1e5YDdQ'. See `help expand`.
    mpv https://www.youtube.com/watch?v=LBoF1e5YDdQ
        ^
Particularly for software that sells itself as user friendly. The carrot doesn't even point at the wildcard!

I am very far from the first person to raise this issue with the fish devs, you can find numerous people bringing this up going years back. I'm generally pretty cognizant of when I have unusual requests or opinions about how software should work, and this is not one of those times.


Your proposed remedy is for the shell to insert something different than what the user inputs. That is much more surprising. No program works that way.


No program other than a shell requires that a URL copied out of your browser's address bar be escaped. Users may not be accustomed to a program escaping or quoting text they paste, but they're also definitely not accustomed to escaping or quoting strings manually.


How do you propose that people use a shell without learning about escaping.

How many people actually using fish are liable to be confused.

Its a strange world you seem to be describing where people simultaneously prefer to use mpv in the terminal instead of clicking on a link but can't figure out how to quote the url.

You can actually set it up for example in Firefox so you can open a link in mpv instead and skip a step.

You could trivially make a quoted paste function and bind it in fish.

This fixes the problem for you it would seem.


That is not surprising in any way. It is very clear and defined that a question mark is a wildcard, and will be expanded. If you want a literal string, define it as such with a single quote.


>"It is very clear and defined that a question mark is a wildcard"

To experienced command line jockeys like you or I, sure. To the inexperienced user, knowledge of the ? wildcard is far from given. ? is esoteric enough that fish has apparently decided to deprecate it completely. fish's error message does not indicated that the wildcard in question was ?, nor does it point to wildcard, it only points to the token that contained the wildcard with no indication of which character it was.

That's not the user friendly experience fish advertises.


? Soon won't be a special character most urls don't include [] () >|$ seems like the majority of urls will actually work without escaping.


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: