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

101–110 of 111 posts

Re: lsix: ls for images

#101

Post by leppr »

petepete wrote: post #65
jopsen wrote: post #9

How many terminal emulators can handle sixel? (vt340) Does anyone have a list?

Not an exhaustive list I imagine, but here's the list from pysixel's readme. RLogin (Japanese terminal emulator) http://nanno.dip.jp/softlib/man/rlogin/ tanasinn (Works with firefox) http://github.com/saitoha/tanasinn/ mlterm Works on each of X, win32/cygwin, framebuffer version. http://mlterm.sourceforge.net/ XTerm (compiled with --enable-sixel option) You should launch xterm with "-ti 340" option. the SIXEL palette…

Seems in this list only XTerm and MLTerm[1] are actively maintained.

[1]: https://sourceforge.net/projects/mlterm/

Re: lsix: ls for images

#102

Post by laumars »

boomlinde wrote: post #91
laumars wrote: post #77

Earlier quoted context omitted.

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.

Yeah I did say “terminal emulators” else where in that comment. Not really sure why I said “shells” in the first line. Must have been having a senior moment....

Re: lsix: ls for images

#103

Post by laumars »

alanbernstein wrote: post #98
laumars wrote: post #86

Earlier quoted context omitted.

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.

pyg doesn’t say anything you hadn’t and he had the replies saying the same comments that I made. So I’m not really sure what you’re trying to argue about ls being inconsistent aside it hiding files that are widely recognised as hidden by other tools systemwide anyway.

Perhaps the GUI file managers are also inconsistent because they hide hidden files by default too?

Re: lsix: ls for images

#105

Post by floatingatoll »

theoh wrote: post #80
floatingatoll wrote: post #55

Earlier quoted context omitted.

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.

There are problems with the manipulation of binary data in bash, as discussed here: https://unix.stackexchange.com/questions/278639/how-can-i-wo... In particular, the value 0 can't be stored in a bash variable, which almost completely rules out the possibility of byte-by-byte processing of general binary data. It's probably possible with absurd hacks. Quite apart from that, error handling in bash is an awkward chore…

If you read a byte without EOF and have a variable length of 0 afterwards, you read a NUL.

Re: lsix: ls for images

#106

Post by [deleted] »

laumars wrote: post #103
alanbernstein wrote: post #98

Earlier quoted context omitted.

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.

pyg doesn’t say anything you hadn’t and he had the replies saying the same comments that I made. So I’m not really sure what you’re trying to argue about ls being inconsistent aside it hiding files that are widely recognised as hidden by other tools systemwide anyway. Perhaps the GUI file managers are also inconsistent because they hide hidden files by default too?

[deleted]

Re: lsix: ls for images

#107

Post by alanbernstein »

laumars wrote: post #103
alanbernstein wrote: post #98

Earlier quoted context omitted.

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.

pyg doesn’t say anything you hadn’t and he had the replies saying the same comments that I made. So I’m not really sure what you’re trying to argue about ls being inconsistent aside it hiding files that are widely recognised as hidden by other tools systemwide anyway. Perhaps the GUI file managers are also inconsistent because they hide hidden files by default too?

I dunno. It seems to me this tool does the right thing, which is to avoid adding minutes to the task of printing a directory listing, which we expect to be instantaneous for local use. But the point I was trying to make is that if, for whatever reason, you prefer waiting two minutes for image previews of PDFs, you can always just `alias lsix="lsix -whatever"`.

Now that I think about it, pdf isn't an image type, so I'm not sure if I would expect a tool like this to handle that anyway.

Re: lsix: ls for images

#108

Post by laumars »

alanbernstein wrote: post #107
laumars wrote: post #103

Earlier quoted context omitted.

pyg doesn’t say anything you hadn’t and he had the replies saying the same comments that I made. So I’m not really sure what you’re trying to argue about ls being inconsistent aside it hiding files that are widely recognised as hidden by other tools systemwide anyway. Perhaps the GUI file managers are also inconsistent because they hide hidden files by default too?

I dunno. It seems to me this tool does the right thing, which is to avoid adding minutes to the task of printing a directory listing, which we expect to be instantaneous for local use. But the point I was trying to make is that if, for whatever reason, you prefer waiting two minutes for image previews of PDFs, you can always just `alias lsix="lsix -whatever"`. Now that I think about it, pdf isn't an image type, so I'…

PDFs have historically been used for print so I can see the rational behind handling them as images; however I can’t see many publishers using this tool.

Re: lsix: ls for images

#109

Post by Aissen »

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…

Sidenote: terminology does not transfer base64 images, but gives an URL (usually a local file, but it could work with http), so that does not work over ssh; but it's faster (no copy/encode/decode).

Re: lsix: ls for images

#110

Post by aquabeagle »

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?

That is how libxo works on FreeBSD:

http://juniper.github.io/libxo/libxo-manual.html

Post reply on HN