Size would be a nice option
lsix: ls for images
51–60 of 111 posts
Re: lsix: ls for images
#52I verified that "lsix" works with MacTerm (my project), which implements Sixels and incidentally also implements the iTerm2 sequences used by "imgls". Rendered areas can be selected and saved or dragged as whole pictures, which may be useful for remote images.
Re: lsix: ls for images
#53Does this work in MacOS terminal and SSH?
something similar exists for iTerm2
Re: lsix: ls for images
#54Beautiful! (-:
Re: lsix: ls for images
#55Earlier quoted context omitted.
It uses various Imagemagick tools (Imagemagick supports sixel). Nobody manipulates binary files/pixel data in bash, do they?
> nobody That's a strong word you have there.
They have a point - I can’t find any traces of a shell library implementing image parsing without calling out to a third-party tool written in not-shell.
You also have a point - I’m seriously debating if I can write one in an evening solely to say that one now exists. (I lost the debate with myself, sadly.)
EDIT: I mean “source language bash”, not “target language bash”, my emscripten friends.
Re: lsix: ls for images
#56You can also specify filenames and, of course, use shell wild cards However, some may be slow to render (like PDF), so lsix doesn't show them unless you ask specifically. Regardless of the justification, I don't think creating such extra exception/edge-case behaviours are ever a good idea in a commandline tool like this. The equivalent in regular ls would be something like not showing more than X files "unless you as…
Regular `ls` lists files in a variable number of columns depending on the terminal width. Many utils enable or disable color output depending on the destination of that output, and on terminal's capabilities. CLI utils are full of special behaviors for convenience of use by people. To enable strict consistence that is mostly necessary for usage by other programs, there are flags.
Many CLI tools will detect if they are running in an interactive shell and change their output accordingly.
Git for example will colourise terminal output if it can tell a person is interacting with it, but if a script is calling then the colour markers won't be added (and there are many many other examples of similar behaviour).
Re: lsix: ls for images
#57Earlier quoted context omitted.
It doesn't matter. These are smart defaults. Just like ripgrep uses gitignore files by default. It makes my normal use useful.
> It doesn't matter. Why? I, like gp, prefer consistency and predictability over unique tool-specific defaults. If every command line tool had it's own special quirks, I would need to consult man pages every single time I issue something more complex that a `cd`. Perhaps lsix should be separated into two tools like find and locate; one that uses cached rendered previews and the other generates them on the fly.
[deleted]
Re: lsix: ls for images
#58You can also specify filenames and, of course, use shell wild cards However, some may be slow to render (like PDF), so lsix doesn't show them unless you ask specifically. Regardless of the justification, I don't think creating such extra exception/edge-case behaviours are ever a good idea in a commandline tool like this. The equivalent in regular ls would be something like not showing more than X files "unless you as…
ls doesn't show the majority of files in my home directory "unless I ask specifically", because of an accident of history that makes files starting with a period "hidden". And yes, this would infuriate me, if I hadn't discovered shell aliases within one day of becoming a linux user. It would also infuriate me if ls took five minutes to render output, and I would also solve that with a shell alias.
Re: lsix: ls for images
#59Aside: Although iTerm2 (on macOS) doesn't appear to work with this, iTerm2 actually supports full-color inline images, and has an "imgls" script which does something similar. (There's also "imgcat".) https://www.iterm2.com/documentation-images.html
I've been meaning to add sixel support since forever, but I like my way of doing it so much more because it supports the file formats people use, which are generally a much better encoding than sixel. That being said, this is nicer than iTerm2's equivalent (called imgls) because it re-encodes the image to make it smaller over the wire. That being said, I'd rather use a lot of bandwidth than have to install imagemagick everywhere. That's probably just my bias against dependencies showing :)
Re: lsix: ls for images
#60Earlier quoted context omitted.
>iTerm2 extends the xterm protocol with a set of proprietary escape sequences. I wonder if any other terminal uses the same escape sequences. If not, why not?
hterm, the terminal emulator portion of the Chrome (OS) Secure Shell app, supports them. (Aside: I dislike the vagueness of the term "proprietary." I rarely hear anyone call the non-ANSI VT-100 or xterm sequences "proprietary," even though they got started in exactly the same way as iTerm2's.)
Some day they'll be standards and I'll change the documentation to say "perfectly normal" instead of "proprietary" :)