GNOME Bugzilla – Bug 170364
open link doesn't include last /
Last modified: 2006-07-05 23:10:09 UTC
Distribution/Version: Debian Testing 1) find text in your gnome-terminal, like the following: http://www.cars.auto.ru/sale/SF59881/448506/ 2) right-click on the link 3) select Open Link form the menu Notice that gnome-terminal doesn't hilight nor include the trailing / in the opened URL, causing "page not found" or similar error (in case the server treats URLs with trailing /'s and without differently).
This bug is caused by the regexp used by gnome-terminal. The regexp should be changed to include the last slash. Regexp is defined in src/terminal-screen.c starting with line 242. Adding gnome-love. Note that maintainer is not really around.
The relevant line is this: "(/[-A-Za-z0-9_$.+!*(),;:@&=?/~#%]*[^]'.}>) \t\r\n,\\\"])?\\>", FLAVOR_AS_IS); This should represent the "path" part of the URL. Chopped down into simpler pieces this becomes... - Starts with a slash "(/ - Followed by 0-unlimited path characters, including slashes. [-A-Za-z0-9_$.+!*(),;:@&=?/~#%]* - Followed by exacly one character that does NOT match any brackets, newlines, whitespace, dots, commas, quotes and backslashes. Meaning, the "forward" slash *should* match. Definitely strange behavior. [^]'.}>) \t\r\n,\\\"] - The path is optional. )?\\>" In other words, I believe the regular expression is correct and the problem is elsewhere to be found. gnome-terminal uses vte's regexp support, I tracked it down into vte/vte.c, presumably that is closer to the source of the problem.
It is caused by the \\> (match empty string at end of word.. but / is not a word)
Created attachment 39662 [details] [review] Regular expressions updated Sorry for the mistake. I am not sure why "empty string at end of word" was added in the first place, since "...]*" is "greedy" anyway, so it should actually always grab the complete URL. (Maybe that is a regexp engine portability issue?) I removed that and also removed some redundancy. Compiled using gcc/glibc and tested on several hundred URLs (with and without trailing slashes both), all seems to work fine.
Doesn't apply any more it seems. And why is PATHCHARS introduced and not used?
Created attachment 48528 [details] [review] Do s/nttp/nntp/ on patch from Samuel Abels PATHCHARS is used within URLPATH (probably to simplify things). The nntp fix broke this patch, did a s/nttp/nntp/g, applies cleanly now.
Comment on attachment 48528 [details] [review] Do s/nttp/nntp/ on patch from Samuel Abels Comment 6: s/Toni Willberg/Samuel Abels/
Thanks. Commiting.
*** Bug 309476 has been marked as a duplicate of this bug. ***
*** Bug 323734 has been marked as a duplicate of this bug. ***
Patch was committed, update status.
Seems to be a regression, I can't get this to work in recent gnome-terminal. Won't recognise trailing "/", e.g. try pasting: http://www.tei-c.org.uk/Software/passivetex/ into the gnome-terminal window, then right click on "Open Link", only: http://www.tei-c.org.uk/Software/passivetex gets passed to the brower. This is with gnome-terminal-2.14.2-1 on Fedora Core 5. Re-opening bug.
That was filed and differently in bug 329003... seems it wasn't fixed in 2.14 branch but only in 2.15 one. Remarking fixed as this is the wrong bug.
This should be marked as a DUPLICATE, or INVALID in that case, shouldn't it? Otherwise it looks like the bug was fixed by the patch below, which it wasn't.
Why? It was fixed, but regressed some time after. For regressions you can either reopen the old bug, or open a new one. I opened a new one because it broke a few months after the previous patch fixed it. And yes it was fixed by below patch, I tested the change. Then regressed by another change. Perhaps I should better have mentioned the new bug here or reopened it...
OK, but what caused the regression, by the way?
I assumed (but did not test) that it was caused by bug 324246.