Re: Feature request: ls --hyperlink

[Pádraig Brady]

On 05/05/17 14:05, Pádraig Brady wrote:
> On 04/05/17 13:14, Egmont Koblinger wrote:
>> Hi,
>>
>> Recently two popular terminal emulators, GNOME Terminal and iTerm2
>> have implemented a brand new feature: explicit hyperlinks.
>>
>> Unlike the existing functionality of most terminal emulators of
>> automatically detecting URLs that appear on the screen, this time it's
>> like hyperlinks on web pages: the link target is specified by the OSC
>> 8 escape sequence and the visible text can be an arbitrary piece of
>> text.
>>
>> As I've played with this feature, I found a really compelling use
>> case: listing files in a way that all of them are hyperlinks to
>> "file://...". It makes it as easy and convenient as a Ctrl+click to
>> open them in their preferred graphical application.
>>
>> (For even more fun, there's a pending demo patch to GNOME Terminal to
>> display a preview of certain local files on mouseover. We're uncertain
>> yet if we'll finalize and ship it or not.)
>>
>> I've created a quick proof of concept patch for a new cmdline option
>> "ls --hyperlink=always/auto/never", have set it up in my "ls" alias,
>> and been using that happily for a few weeks now. Please find it at
>> https://bugzilla.gnome.org/show_bug.cgi?id=779734#c126. Note that it
>> contains a couple of issues, e.g. I forgot to free some data, and it
>> does stupid things around symlinks. As said, it's a demo, not a fully
>> polished patch.
>>
>> I'd be curious to hear if you like this idea, and would be happy to
>> see this option appearing in mainstream coreutils.
>>
>> Please see https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
>> for details about the feature.
>>
>> Let me know if you have any questions, concerns etc. (cc me, I'm not
>> subscribed).
> 
> Interesting.
> This could apply to any util really that displays file names,
> though ls would be the most useful.
> Generally it also seems useful to the case where a file has a non 
> representable name
> (well not cleanly at least without $'shell quoting').

I've attached an implementation for ls --hyperlink.

Some notes:

I used canonicalize_filename_mode for consistency with other tools,
and to relax the canonicalization with CAN_MISSING.
I did this because access may be possible outside current shell context,
and also we don't want to diagnose perm issues that would
either not otherwise need diagnosing, or would be diagnosed
independently by stat() etc.

--dired is handled appropriately, since the terminal codes
are similar to non displayed color codes and can be skipped similarly.

I used more stringent escaping as per rfc3986
because I think there are security issues with the more lax
encoding described at 
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
and I don't see any advantage of using that more lax encoding.
If terminals provided a copy link functionality, or
the links otherwise got outside the terminal context
then there could be problematic handling of non encoded items.
For example if you didn't encode '?' and the link was passed
to a browser, then anything after that would be ignored.
Also '%' needs to be encoded for the same reasons where
files other than intended could be resolved.

This should work on windows where c: is separated from the
hostname appropriately and '\' are converted to '/',
though I haven't tested there.

I've tested with valgrind with multiple specified dirs
and there are no leaks.

I was tempted to add --hyperlink to realpath, though I'm not sure it's needed.

I was tempted to add a --hyperlink=raw option to output just the file://...
portion without the terminal codes, as older terminals highlight/process
those fine and they might be otherwise usefule.  Though again I wasn't sure.

cheers,
Pádraig.

ls--hyperlink.patch
Description: Text Data