I thought I might bluntly need just a new w3m, but even 0.5.3+git20230121-2 (git version as there was no release) in noble behaves the same.
Again I'm not a perl magician, but I see in there: s@(http|ftp)://[\w.\-/~]+[\w/]@<a href="$&">$&</a>@g;
So that is trivial isn't it: This gets it working for my testcase
root@n:~# diff -Naur /usr/lib/w3m/cgi-bin/w3mman2html.cgi.orig /usr/lib/w3m/cgi-bin/w3mman2html.cgi --- /usr/lib/w3m/cgi-bin/w3mman2html.cgi.orig 2024-01-30 08:08:50.278360949 +0000 +++ /usr/lib/w3m/cgi-bin/w3mman2html.cgi 2024-01-30 08:09:10.542507674 +0000 @@ -162,7 +162,7 @@ next; }
- s@(http|ftp)://[\w.\-/~]+[\w/]@<a href="$&">$&</a>@g; + s@(https|http|ftp)://[\w.\-/~]+[\w/]@<a href="$&">$&</a>@g; s@\b(mailto:|)(\w[\w.\-]*\@\w[\w.\-]*\.[\w.\-]*\w)@<a href="mailto:$2">$1$2</a>@g; s@(\W)(\~?/[\w.][\w.\-/~]*)@$1 . &file_ref($2)@ge; s@(include(<\/?[bu]\>|\s)*\<)([\w.\-/]+)@$1 . &include_ref($3)@ge;
This seems too easy, there must be another trap I'm missing ... Looking through Ubuntu and Debian bugs against w3m ... I feel it is suspicious (in me overlooking something) that it isn't filed against https://bugs.launchpad.net/ubuntu/+source/w3m or https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yes&src=w3m nor in https://github.com/tats/w3m/issues which you'd assume as https is quite common.
I thought I might bluntly need just a new w3m, but even 0.5.3+git20230121-2 (git version as there was no release) in noble behaves the same.
Again I'm not a perl magician, but I see in there: ftp):// [\w.\-/ ~]+[\w/ ]@<a href="$&">$&</a>@g;
s@(http|
So that is trivial isn't it:
This gets it working for my testcase
root@n:~# diff -Naur /usr/lib/ w3m/cgi- bin/w3mman2html .cgi.orig /usr/lib/ w3m/cgi- bin/w3mman2html .cgi w3m/cgi- bin/w3mman2html .cgi.orig 2024-01-30 08:08:50.278360949 +0000 w3m/cgi- bin/w3mman2html .cgi 2024-01-30 08:09:10.542507674 +0000
--- /usr/lib/
+++ /usr/lib/
@@ -162,7 +162,7 @@
next;
}
- s@(http| ftp):// [\w.\-/ ~]+[\w/ ]@<a href="$&">$&</a>@g; http|ftp) ://[\w. \-/~]+[ \w/]@<a href="$&">$&</a>@g; mailto: |)(\w[\ w.\-]*\ @\w[\w. \-]*\.[ \w.\-]* \w)@<a href="mailto: $2">$1$2</a>@g; W)(\~?/ [\w.][\ w.\-/~] *)@$1 . &file_ref($2)@ge; <\/?[bu] \>|\s)* \<)( [\w.\-/ ]+)@$1 . &include_ ref($3) @ge;
+ s@(https|
s@\b(
s@(\
s@(include(
This seems too easy, there must be another trap I'm missing ... /bugs.launchpad .net/ubuntu/ +source/ w3m or https:/ /bugs.debian. org/cgi- bin/pkgreport. cgi?repeatmerge d=yes&src= w3m nor in https:/ /github. com/tats/ w3m/issues which you'd assume as https is quite common.
Looking through Ubuntu and Debian bugs against w3m ...
I feel it is suspicious (in me overlooking something) that it isn't filed against https:/