Re: Feature request: ls --hyperlink

[Egmont Koblinger]

Hi,

Something I've been wondering for a while, and I'm not sure what to do, so
your input is welcome:

What to do on symlinks?

In your version (and I my one too as far as I remember) the hyperlink
points to the target of the symlink. In my draft patch this was by no means
the intent, it just happened this way :)

With the simplest ls (no colors or file type), this means that turning on
the hyperlink option results in all the files getting lstat()ed. Since this
option will probably mostly be used by interactive ls commands, maybe this
price is okay to pay (and probably are enabled anyways in these cases, so
this price is already being paid). With dired and emacs integration (if
implemented one day), I'm afraid there might be a few people out there with
weird setups for whom this would be a noticeable performance regression.

It's also a weird user experience that (let's say I have an AA -> BB
symlink) executing "ls --hyperlink" prints AA, but as I mouse over,
gnome-terminal's tooltip says file://blah/blah/BB.

I'm wondering if it would make sense for the entry to URLize the symlink
itself instead. This would probably mean some more refactoring to the code,
but would probably make it more effective. Instead of lstat()ing or
realpath()ing every file of a directory, it could be done once for the
containing directory only, and each filename just appended to this path.
(Maybe even URI-escaping the directory path only once, but this might be
too much micro-optimization.)

"." and ".." need to be special cased though, plus if a filename is
explicitly present in the command line then that's another story again.

In the output of "ls -l", after the "->" sign, though, it could be the
target that's realpath()ed. This approach would make it more consistent
with coloring, since on the left of the "->" sign it's a generic symlink
color that's used, on the right it's according to the target. The two URLs
would similarly refer to the source and the target, too. (Or maybe I
wouldn't mind not hyperlinking the target.)

This is probably also the behavior that would be most robustly just doing
what's expected if the directory contents change after you've executed ls
(e.g. you modified a symlink's target), but you scroll back in your
terminal and click on an older hyperlink. You could of course say it's an
absolutely non-goal and I couldn't really argue with that. Also, since the
target of a symlink may always contain ".." components which should be
eliminated from the generated hyperlinks, and dangling symlinks even
further complicate the game, you can never guarantee for sure that you
create a URI that remains valid after the files and symlinks are modified.

As for the source of the symlink to be hyperlinked to the source entry, and
the target to the target... your call if you think it's worth it; it might
be just too much work to get all such details "right" (in a definitely
questionable definition of what's right). Or maybe just postpone it for a
while, release the current version now and improve later based on feedback.

I'd love to hear what you think about this story :)


cheers,
e.


On Fri, Aug 25, 2017 at 9:12 AM, Pádraig Brady <address@hidden> wrote:

> On 21/08/17 04:28, Pádraig Brady wrote:
> > 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.
> >
>
> Version 2 attached which fixes a small mem leak,
> ensures that URLs are aligned in padded output,
> and disables --dired with --hyperlink since it didn't work in testing
> and precluded the URL alignment method used (which excludes quotes from
> the URL).
> It might be useful to support //DIRED-OPTIONS// --hyperlink to identify
> the URI portion to emacs, but we can do that separately if useful.
>
> cheers,
> Pádraig.
>
>