[HN Gopher] lsix: Like "ls", but for images
___________________________________________________________________
lsix: Like "ls", but for images
Author : gaws
Score : 159 points
Date : 2024-06-06 15:29 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| forgotpwd16 wrote:
| As long as terminal used supports sixel graphics.
| kps wrote:
| xterm supports sixel, so surely anything that sets
| TERM=xterm256-color or similar will be compatible... right?
| *cough* gnome-terminal *cough*
| spudlyo wrote:
| xterm supports sixel, so surely if your TERM is xterm-kitty,
| it's supported right?
| kps wrote:
| I would say so, yes (not a fan of kitty's general NIH), but
| it could be argued that `xterm-kitty` is at least not
| identical to a $TERM used for xterm.
| spudlyo wrote:
| Indeed. I was trying to humorously reference the author's
| staunch refusal to remove `xterm` from the TERM
| identifier, knowing full well that many programs simply
| look for `^xterm` when determining if the terminal is
| compatible. As you eluded to with 'NIH', the same author
| refused to implement Sixel in Kitty because it is
| "inferior" to Kitty's image implementation.
| SushiHippie wrote:
| What does "NIH" mean in this context?
| throwaway290 wrote:
| Kitty developer decided to go with a custom image display
| protocol instead of going with sixel.
| sn0wf1re wrote:
| Not Invented Here
| 20after4 wrote:
| https://en.wikipedia.org/wiki/Not_invented_here - When
| someone or some group prefers to re-invent something
| rather than using an existing, perfectly serviceable
| solution.
| alexvitkov wrote:
| Why do we now have User-Agent in the terminal ;-;
| boomboomsubban wrote:
| Isn't the TERM variable ancient? I know one of the "common"
| exported variables is the VT100, sold in 1978.
| hollerith wrote:
| Yes, it is very old.
| dheera wrote:
| I wrote a graphics library for non-sixel terminals
|
| https://github.com/dheera/python-termgraphics
|
| Might be interesting to mod this library to support this as a
| fallback.
| wonger_ wrote:
| Looks good! I've seen a few such libraries. My favorite is
| chafa: https://hpjansson.org/chafa/
| spudlyo wrote:
| In case you're like me, and you wouldn't think of using a
| terminal without Tmux, the experimental sixel branch was finally
| merged[0] as of about 10 months ago. This means you can finally
| build mainstream Tmux with --enable-sixel and use tools like lsix
| in Tmux!
|
| If you're curious if your favorite terminal or multiplexer
| supports sixel, you can check out the "Are We Sixel Yet"[1] site.
|
| [0]:
| https://github.com/tmux/tmux/commit/dfbc6b1888c110cf0ade66f2...
|
| [1]: https://www.arewesixelyet.com
| emptysongglass wrote:
| I'm not sure I understand the use of tmux. Can someone explain
| why it's essential to their workflow and why it might end up
| being essential to mine?
| spudlyo wrote:
| Tmux provides a means multiplexing a single terminal window
| into multiple terminals, either full screen, or like a tiling
| window manager. It lets you organize and label these
| terminals and provides a very flexible keyboard interface to
| terminal management, including history scrollback, search,
| etc. I started using GNU Screen in the early 90s, and over
| the years I have developed a keyboard muscle memory for
| managing multiple terminals in this fashion that is
| completely independent from whatever terminal program I'm
| using. This allows me to utilize this keyboard muscle memory
| if I'm using iTerm2 on macOS, Windows Terminal, or Alacrity
| on Linux.
|
| Many fancy terminal programs offer some subset of these
| multiplexing features (like tabs) and such, but in my
| experience none of them are as configurable or as feature
| rich as Tmux.
| lynndotpy wrote:
| It's also very good if you're SSHing over an unreliable
| connection. The tmux terminal doesn't break when your
| connection does.
| michaelmior wrote:
| I use tmux, but as far as unreliable connections, I've
| found mosh[0] to be the best solution to the problem
| (when you have the ability to install it). It basically
| runs a background process on connection not tied to the
| session that your client will automatically reconnect to
| if the connection fails. I regularly close my laptop,
| travel between home and work, open it back up and the
| connection is available almost instantly.
|
| [0] https://mosh.org/
| adamomada wrote:
| This is exactly the same reason I had in the 90s using
| tmux's precursor, GNU screen. With dialup or crappy isdn,
| screen -R was always the first input after login
|
| Have we gone from shitty connectivity to stable and then
| back to shitty?
| jprete wrote:
| I don't think so! But tmux is really useful for laptop
| scenarios, like when the laptop goes to sleep, or if
| you're working on a train and it goes through a tunnel
| with no network reception.
| elcomet wrote:
| I still use screen, is tmux better?
| technofiend wrote:
| It's handy even if you just need to go from work to home
| to Starbucks or whatever. Doesn't have to be a poor
| connection as much as one that changes occasionally.
| chrisamiller wrote:
| At any given time, I'm working on like 10 different projects.
| tmux lets me set up sessions for each of these projects, so
| that when I leave one and come back in a week, all the
| context is there (multiple windows, bash history, working
| directories I was in, etc)
|
| Since I work with big biological data, most of my work takes
| place on our university cluster, which means my laptop is
| just a dumb terminal and all of the action takes place on the
| server. IME, tmux is especially powerful with coupled with
| mosh, which gives a persistent SSH connection. That means I
| can be in the middle of a project, close my laptop lid, go
| home, then later that evening, open my lid and everything is
| reconnected and just right there. Same if I reboot my laptop
| - one command to reconnect my terminal with mosh, and I'm
| back in the middle of my complicated multi-window project.
| trentnelson wrote:
| What happens when you press page up or down in tmux? Have
| you configured it to scroll page up & down? Or do you do
| that via Ctrl-B ] or whatever the magic incantation was?
| necrotic_comp wrote:
| That's right. You have a prefix that lets you use page up
| page down in any pane you've got currently selected.
| donio wrote:
| Not parent but keybindings are fully configurable. For
| example to scroll up with Shift-Pgup:
| bind -n S-PPage copy-mode -u bind -T copy-mode
| S-PPage send -X page-up bind -T copy-mode S-NPage
| send -X page-down
|
| The first line is a top-level binding to enter copy-mode
| and immediately scroll up one page. The other two add
| bindings within copy-mode so you can continue to scroll
| up or down with those keys.
|
| I also have a small hack in my .zshrc to start scrolling
| up with `M-v` (like in Emacs) while at a shell prompt:
| tmuxup(){tmux copy-mode -u} zle -N tmuxup
| bindkey '^[v' tmuxup
| elteto wrote:
| When I used tmux I used to set Ctrl-PgUp/Down bindings to
| scroll the buffer.
| kabr wrote:
| Saved terminal state. Multiple tabs. Can log off and come
| back and everything's there. tmux and mosh are game changers,
| especially while tethering/roaming and switching networks.
| Groxx wrote:
| Maybe one of the missing pieces here for anyone not
| terminal-fluent:
|
| Normally, when you lose your ssh connection to another
| machine, it'll kill your scripts, drop all the output into
| /dev/null, and you can't get any of it back. Because that's
| how a remote terminal normally works.
|
| So even brief connection issues are a major headache, much
| less known stuff like "close your laptop and resume after
| lunch".
|
| Tmux gets you what you would expect instead from a "remote
| tab" thing. Stable, reconnectable, still exists when you're
| not connected, etc. There are other options of course
| (there always are), but tmux does it all and it's an
| industry standard.
| cxr wrote:
| That should be table stakes at this point; these features
| should be built into all conventional desktop terminal
| emulators. I shouldn't have to run a second, inferior text
| mode terminal emulator inside the terminal emulator app
| that ships with my preferred desktop environment (and deal
| with the conflicts/impedance mismatch that falls out of
| this pairing).
|
| Pretty nuts that so many desktops and independent modern
| terminal emulators lag so far behind GNU Screen, which was
| first released in 1987.
| michaelmior wrote:
| Personally I'd much rather run that server-side. I use
| iTerm which has a lot of great features for session
| management, but I like being able to connect from any
| machine and keep the exact state I was in rather than
| having it tied to my local client.
| freedomben wrote:
| I prefer tmux because I can run it on servers/remote
| machines too. It doesn't require X so runs perfectly and
| happily on headless machines. Can also be nested.
|
| I'm all for adding those features to the terminal
| emulators, but it will never meet and certainly not
| exceed tmux in flexibility, power, portability, and
| compatiblity.
| baobun wrote:
| Hard disagree. I very much like my terminals thin and
| "stupid" (sixels, clickable links, speed, and workable
| CJK font/IME support are about the non-standard features
| I really want), leaving all the navigation to something
| like tmux/zellij/screen.
|
| There are other features a desktop terminal emulator can
| not give you. And being able to maintain all the
| shortcuts and muscle memory across devices, servers,
| X11/Wayland, different DEs, and inside nested VNC or SSH
| sessions, more than compensates for "impedance mismatch"
| (curious what you're actually referring to here... Just
| putting a line in my shellrc to start a new tmux session
| unless the TMUX env var is already set makes it mostly
| seamless and you could do the same in terminal emulator
| conf if you dislike putting such things in your shell or
| profile).
|
| Unix philosophy: I want my graphical terminal emulator to
| render my sessions on my display. The stuff happening
| inside should mostly not be its concern.
|
| > I shouldn't have to
|
| Good thing you don't have to, then. For casual users,
| emulators like Kitty, xfce-terminal and Konsole exist and
| are quite popular. Yeah, a batteries-included terminal
| emulator sounds more appropriate for you and probably the
| majority. For "niche" users like sysadmins and many power
| users, tmux is the table-stakes. There's no one-size-
| fits-all and not everything has to be for everyone.
|
| > GNU Screen
|
| Well, there's the topic of the thread...
| kps wrote:
| As for me, I like the "do _one_ thing well" philosophy --
| I don 't want my terminal to manage multiple
| sub-'windows', because I already have a window manager
| that I like just fine thank you.
|
| `tmux` is actually more than I want, because it
| interposes itself as a terminal emulator in its own right
| (hence, per the thread parent, requiring its _own_ sixel
| support on top of the display terminal 's) and use
| `dtach` instead: it's just a pass-through session holder.
| Something like `tmux` is necessary when you want to
| connect to a session from significantly different
| terminals (say, iTerm on a Mac and Konsole on *nix) but I
| don't do that.
| foresto wrote:
| > these features should be built into all conventional
| desktop terminal emulators.
|
| Lennart, is that you? ;)
| PhilipRoman wrote:
| Aside from tabs/panes/persistence already mentioned, it
| serves as a portable, programmable layer that will work
| anywhere, whether on the client or server side. I set up my
| key bindings once and now they work over SSH from Windows,
| local terminal emulator, on a Linux framebuffer console or
| even through a serial port. While I do use a tiling/tabbing
| window manager, tmux is just really good at what it does so I
| still keep using it for my terminals.
| bee_rider wrote:
| It provides all of the useful functionality of a window
| manager (hosting multiple terminals) but you can run it in a
| terminal.
| freedomben wrote:
| lots of good answers already. my tldr: it's a terminal-
| agnostic tool to split a window vertically or horizontally so
| you have multiple shell sessions on the same screen (and can
| move between them). Lots of other great reasons too but
| that's the major one IMHO.
| michaelmior wrote:
| Personally I find the small shell function below really helps
| my tmux workflow. Run it with no arguments and you'll get a
| list of available sessions. Run it with a session name and it
| will start the session if it doesn't exist or reattach if it
| does. If you're already in one tmux session, it will just
| switch over your client to that session.
|
| The function below will also automatically detach other
| clients, but for me it's what I want since other clients are
| always just me on another machine, often with a different
| screen size. tm () { if [ -z $1
| ] then tmux list-sessions
| return fi tmux detach -s $1 2>
| /dev/null if [ -n "${TMUX+1}" ] then
| tmux switch-client -t $1 2> /dev/null || tmux new-session -s
| $1 else tmux attach-session -t $1
| 2> /dev/null || tmux new-session -s $1 fi
| }
| arlort wrote:
| Plenty of great use cases have already been pointed out, but
| what I also love is that sometimes I get carried away and use
| the close window keybind on the wrong terminal, with tmux set
| to create a new session when the terminal is launched (which
| isn't closed unless all shells in the sessions have excited)
| I just use a keybind to spawn a terminal attached to any
| unattached sessions and never again have to recreate 10
| different panes in different working directories on different
| windows
|
| Also let's my colleagues monitor my builds on our shared
| server pretty easily and it's better than screen sharing
| mostlysimilar wrote:
| I like tmux for keeping a remote session open but I don't use
| it for my local machine. On my local machine the only thing
| it would really buy me are tabs/split panes, and iTerm does
| those things natively and far better than tmux does.
| TheAdamist wrote:
| I find the split screen capability very useful for terminal
| use, but i'm only a more basic user
| jeppester wrote:
| A use case I haven't seen mentioned - from skimming the
| comments, is that multiple users can connect to the same tmux
| session.
|
| It does a good job at scaling the session to fit the size of
| each client's terminal window and has multiple scaling
| options available.
|
| In my experience it works way better than for instance
| terminal sharing in VS Code.
| freedomben wrote:
| I'm a long time tmux user (and screen before that), but I don't
| understand why sixel makes a difference.
|
| Is this as big as bring a stacking window manager to tmux
| (compared to the current which is tiling)? Or is just better
| graphics in the terminal? or am I way off here?
|
| If it's just the better graphics, then I'm not sure I
| understand why tmux needs to support it. I would think the
| terminal emulator (such as Gnome terminal) is what would
| matter. I suppose maybe both but I would think tmux would just
| pass through.
| aidenn0 wrote:
| You can't just pass through things; what happens when you
| resize, (re)attach, switch tabs &c.
|
| Tmux needs to know that there are graphics on the screen and
| redraw in any of those situations.
| rkangel wrote:
| Terminals and shells aren't like window managers where you
| can just subdivide your drawing space and pass a block pixels
| to something else to draw on.
|
| What the terminal processes processing is a stream of bytes
| from the shell and needs to be able to interpret them in
| order to lay things out correctly.
| adregan wrote:
| Do you happen to know if sixel is enabled when tmux is
| installed with brew?
| avhception wrote:
| The example screenshots feature a terminal with a "foo@kremvax"
| prompt, nice touch :D
| sebnukem2 wrote:
| Quite the list of deps (from brew install): dependencies for
| lsix: bash, libpng, freetype, fontconfig, jbig2dec, jpeg-turbo,
| libidn, libtiff, little-cms2, openjpeg, ghostscript, brotli,
| giflib, highway, imath, openexr, webp, jpeg-xl, libvmaf, aom,
| libde265, glib, shared-mime-info, x265, libheif, liblqr, jasper,
| libomp, libraw, m4, libtool and imagemagick
| bee_rider wrote:
| A lot of them seem pretty reasonable, I wonder though if it
| would benefit from some optional dependency based scheme
| dylan604 wrote:
| if you want to look at media, you gotta have the proper codecs
| --and there's a lot of them. that's what the majority of them
| are.
|
| have you seen some of the dependency trees for npm packages?
| not really sure your point here
| p_l wrote:
| Majority are simply to support opening different types of
| graphics (still and moving) files. Some are necessary just for
| the build process.
|
| All in, I'd say it has remarkably little in dependencies that
| aren't directly connected to fulfilling the job it's supposed
| to do (bash, libtool, m4 - looks like build time does; libomp,
| highway, imath - useful optimization libraries; glib - living
| in C land is a PITA; shared-mime-info - useful for file type
| recognition and handling) and I would be totally unsurprised if
| some of them weren't transitive deps anyway (esp. libomp and
| highway).
|
| So I'd say it's very light on dependencies.
| arp242 wrote:
| Pretty much all of these are dependencies of imagemagick,
| because that supports tons of image formats, often via things
| like lib$format. The script itself just depends on bash,
| imagemagick, and a few standard shell tools like sed.
| aidenn0 wrote:
| The only direct dependency is imagemagick; the rest are pulled
| in by that; here's a breakdown:
|
| Common build-time requirements:
|
| - bash
|
| - m4
|
| - libtool
|
| Image decoding libraries:
|
| - libpng
|
| - jbig2decjpeg-turbo
|
| - libtiff
|
| - openjpeg
|
| - ghostscript
|
| - giflib
|
| - openexr
|
| - webp
|
| - jpeg-xl
|
| - aom
|
| - libde265
|
| - x265
|
| - libheif
|
| - libraw
|
| Image manipulation:
|
| - imagemagick
|
| - liblqr
|
| - little-cms2
|
| Font-rendering (needed to display vector formats):
|
| - freetype
|
| - fontconfig
|
| General purpose and/or math libraries:
|
| - glib
|
| - libomp
|
| - imath
|
| - highway
|
| This leaves the following:
|
| - brotli : a compression library; I suspect some image format
| uses it.
|
| - libidn : probably a deep dependency, command line tools ought
| not be doing domain-name lookups
|
| - libvmaf : A video related library; probably a dependency of
| one of the video-codec based image libraries?
|
| - shared-mime-info : figure out what file type a file is
|
| - jasper : found a few possibilities for what this is; I don't
| use homebrew so don't know how to resolve a brew name to an OSS
| project
| mb5 wrote:
| Nice breakdown.
|
| I think jasper is this, a library for JPEG-2000 images:
| https://www.ece.uvic.ca/~frodo/jasper/
|
| Linked to from here: https://formulae.brew.sh/formula/jasper
| Aldipower wrote:
| The HN font is very misleading here. I am waiting for the next
| headline: 'Isis, like "ls", but for terrorists.'
| neilv wrote:
| Do the filenames work with text selection?
|
| (Looks like they might only be in the pixmaps, not accessible as
| text to the terminal.)
| vidoc wrote:
| See, _that_ is pure genius!
| thecosmicfrog wrote:
| I think my favourite feature of this repo is the `README.md.d`
| directory. That's actually a nice idea. Could maybe drop the
| `.md` I guess.
| smarm52 wrote:
| Something interesting might be to mix in object detection in
| images, for something like:
|
| `lsix --search cat`
|
| And find all the images that contain cats.
| Zhyl wrote:
| https://xkcd.com/1425/
| Guillaume86 wrote:
| That comic lost some meaning in recent years, you could put
| out some decently accurate bird detection model by following
| a 30 mins YouTube video, it was even one of the first
| exercice in some ML youtube courses (can't remember the
| channel).
| Zhyl wrote:
| But it still retains some meaning. Using a glob pattern to
| wildcard files with the same name vs. running an image
| entity classifier across 1 to n images in potentially
| recursive directories. In a command line utility for
| displaying files.
| sva_ wrote:
| Maybe more in the sense of the Unix philosophy: The
| detection should happen in a separate tool of which the
| output filenames can then be piped into lsix.
| foresto wrote:
| To be fair, that comic was published around ten years ago.
| I'd say the example it used to make its point was
| reasonably accurate.
| sva_ wrote:
| Jeremy Howard references this xkcd in the very beginning of
| his stable diffusion course[0], and builds such a detector in
| about 10 minutes.
|
| 0. https://course.fast.ai/Lessons/lesson9.html
| omoikane wrote:
| Uses "\e[c" to automatically detect sixel support:
|
| https://github.com/hackerb9/lsix/blob/3a431793a747df3f934051...
|
| "\e[c" is "send device attributes":
|
| https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-F...
| aftbit wrote:
| Be careful running this on an untrusted directory, especially
| with e.g. pdfs, just like anything else that parses images,
| especially using ImageMagick.
| aniviacat wrote:
| Is parsing untrusted images inherently problematic?
|
| If I open my (untrusted) downloads folder using Gnome Files and
| it displays (and therefore parses) the contained images, is
| that a security issue I should be concerned about?
|
| (I would have assumed that (e.g.) Javascript in PDFs could be
| problematic, but not a simple preview.)
| J_tt wrote:
| Unfortunately, it can be a vector[0], especially on less
| security focused software that has less sandboxing.
|
| 0: https://www.cvedetails.com/vulnerability-
| list/vendor_id-7294...
| metadat wrote:
| Awesome idea, but doesn't work under PuTTY/KiTTY:
| $ lsix Error: Your terminal does not report having sixel
| graphics support. Please use a sixel capable
| terminal, such as xterm -ti vt340, or ask your terminal
| manufacturer to add sixel support. You may test your
| terminal by viewing a single image, like so: convert
| foo.jpg -geometry 800x480 sixel:- If your terminal
| actually does support sixel, please file a bug report at
| http://github.com/hackerb9/lsix/issues Please
| mention device attribute codes: ^[[?6c
|
| Too bad! That would be pretty spiffy.
|
| Is there an open-source windows terminal which supports Sixel?
| Mostly seems only Cygwin or WSL stuff out there, nothing pure?
| ThrowawayTestr wrote:
| The lengths people will go to avoid leaving the terminal
| oalders wrote:
| fzf has "(Experimental) Sixel image support in preview window
| (not available on Windows)" since version 0.44.0
|
| https://github.com/junegunn/fzf/releases/tag/0.44.0
|
| fzf --preview='fzf-preview.sh {}'
___________________________________________________________________
(page generated 2024-06-06 23:00 UTC)