Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

lsix: ls for images

github.com

Post reply on HN
Print view View original

91–100 of 111 posts

Re: lsix: ls for images

#91

Post by boomlinde »

laumars wrote: post #77
fouc wrote: post #33

Earlier 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?

It’s worse than that, there’s other shells that support their own ANSI escape sequence for transferring base64 encoded images: kitty (not to be confused with KiTTY - the PuTTY fork) and Terminology (of enlightenment DE) each have their own “standard” and they differ from iTerm2’s. They all have their own CLI tools too. Then there is sixel - which solved a problem back when TTYs were VDUs but aren’t really suitable fo…

Pedantry: Those are terminal emulators, not shells.

Re: lsix: ls for images

#92

Post by bmn__ »

jchw wrote: post #85
bmn__ wrote: post #76

Earlier quoted context omitted.

Still does. Dolphin → Settings → Configure Dolphin… → General → Previews

I see; I mostly used KDE in the 3.x days, back when Konqueror was the file manager and Webkit was still a fairly young KHTML fork.

Konqueror and Dolphin use the same kpart under the hood for directory display.

Konqueror → Settings → Configure Konqueror… → File Management → General → Previews leads to the same configuration dialog.

Re: lsix: ls for images

#93

Post by boomlinde »

theoh wrote: post #5
merlincorey wrote: post #2

It's pretty incredible that this is a bash script that outputs sixel graphics, and it in no way makes use of libsixel[0]. [0] https://github.com/saitoha/libsixel

It uses various Imagemagick tools (Imagemagick supports sixel). Nobody manipulates binary files/pixel data in bash, do they?

Pixel data doesn't necessarily imply binary data, though. In the Plain PPM format, pixels are encoded as plain text RGB tuples separated by white space. It's not inconceivable for such a simple format that one could write a simple image processor in a few lines of shell + coreutils.

Re: lsix: ls for images

#94

Post by boomlinde »

jopsen wrote: post #21
amasad wrote: post #17

Earlier quoted context omitted.

As far as I know it's just xterm on desktop. It's fascinating that we have this standard that allows us to build programming environments like notebooks -- without resorting to layering hacks on hacks to make it work on web -- practically crossplatform yet we don't make use of it. At repl.it we've been toying around with adding sixel support for xterm.js and we have a prototype up and people in our community are alre…

It's also facinating that programs that generate text output do so in a format that's well over 40 years old. What if our CLI programs could output HTML or JSON depending on whether they are piped or printed. Both standards are not good for this, but is VT100 really that great?

> What if our CLI programs could output HTML or JSON depending on whether they are piped or printed.

Well, they can, and there are tools that read HTML data from their standard input and render it in a browser.

I don't understand the preoccupation with rendering things like this within terminal emulators. We have graphics displays, X11, and can mount anything locally. If I quickly want to view some thumbnails, I'll use feh, or maybe just a graphical file browser. If I want to view an HTML document I'll open that in my web browser. If I want to plot some data I can use gnuplot. None of this is particularly distracting to my workflow.

On the contrary, I think there is some value to having command line applications output data that is easy to parse and WYSIWYG, because its strength to me lies in the ease with which you can automate workflows using a shell operating on text data. That's sort of lost when all the data you see is filled with invisible markup. This is already the case to some lesser extent with colors and e.g. ls formatting.

Re: lsix: ls for images

#96

Post by goliatone »

ObsoleteNerd wrote: post #34
userbinator wrote: post #7

You 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…

Are PDFs really expected to preview in an image viewer though? I don't really think of them as images, so I see the flag to preview them as more of an "extra feature", which is exactly what flags are for. If it didn't preview GIFs without a flag, or PNGs, then your point would absolutely stand.

You can use PDFs in Xcode. Instead of using a single image for all the different resolutions and polluting your fs is actually really nice to have a single file with preview

Re: lsix: ls for images

#97

Post by vthriller »

jake_the_third wrote: post #45
scarejunba wrote: post #29

Earlier 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.

Predictability is a tad subjective (I'll put consistency part aside for a moment here); e.g. you can think of pdf handling this way: lsix is about images first and foremost, so it makes sense to hide everything else, including pdfs, which are mostly books and papers and other things that thumbnails would hardly even help with. (This reasoning, however, becomes more brittle once we include videos into equation. Should it be images-only tool, or should it be about anything thumbnailable?)

Re: lsix: ls for images

#98

Post by alanbernstein »

laumars wrote: post #86
alanbernstein wrote: post #58

Earlier quoted context omitted.

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.

You can’t really argue that ls not showing hidden files by default is a quirk. Next you’ll be complaining that rm doesn’t delete root owned files when run as a regular user so you created an alias to sudo rm for every operation. I’ll grant you that hidden files being defined by a prefix on the file name is a weird quirk - but at least that’s something which is consistent across all of Linux and UNIX (including OS X)…

You're focusing on the wrong point in my comment. See the other replies by pyg in this thread. ls is not a good example of consistency to contrast with here.

Re: lsix: ls for images

#99

Post by makecheck »

pmarreck wrote: post #62
EGreg wrote: post #26

Does this work in MacOS terminal and SSH?

https://www.macterm.net/ seems to support sixels EDIT: And despite the option in there being on, I can't seem to get it to output graphics instead of binary garbage when I use the "lsix" bash script.

I will try to help if I can. It does work for me.

The script seems to depend on ImageMagick "convert" for most of its work; when I run "convert -version" I see "ImageMagick 7.0.6-0 Q16 x86_64 2017-06-12", is this newer than the version you are using?

Re: lsix: ls for images

#100

Post by jandrese »

fake-name wrote: post #44

Works in cygwin/MiniTTY. Awesome! OTOH, when using screen, it completely poops itself. Sadface. Also, wow, it's slow.

Despite being old as the hills and seemingly unchanged over the years ImageMagick still manages to be slow. It is a mystery how the developers managed this feat.

It's a shame that netpbm seems to be mostly dead, it always worked much better for the kind of tasks that most people use ImageMagick for, at least for me.

Post reply on HN