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

81–90 of 111 posts

Re: lsix: ls for images

#81

Post by laumars »

kijin wrote: post #50
ObsoleteNerd wrote: post #34

Earlier quoted context omitted.

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.

Exactly. PDFs are documents, not images. Just because ImageMagick can convert PDFs into images doesn't make them images. Every image viewer on Earth excludes DOCs and PPTs by default, but nobody complains about that.

I think the reason for that is more to do with history than anything. The original intended purpose of PDFs were to be a print quality final layout.

That’s not so much the case these days and Word documents / PowerPoint presentations have supported embedding fonts too so they’ve drifted a little into PDFs territory. But from a generalised and historic standpoint: Word documents were for editing and PDFs were for printing.

Re: lsix: ls for images

#82

Post by dotancohen »

_9jgl wrote: post #42
euske wrote: post #20

Cooool! Is there any way to get this work with tmux? Currently it seems it's filtering Sixel escape sequences. On a raw xterm it's fine.

Probably not, see https://github.com/tmux/tmux/issues/44 (tldr: maintainer says no). There's a fork that purports to add support, but it's not been updated for a while: https://github.com/yatli/tmux-sixel

Note that it is the tmux maintainer, not the libsixel maintainer, who is saying no. He won't even add support if someone else provides the patch, unless the patch is small. Why? Because:

> "I am not interested in graphics in the terminal and there are few practical uses for them anyway."

Really? I wonder how the *nix environment would look like today if the tools (gnu, et al) only worked with the workflows that their original creators envisioned. In fact, just recently I had to SSH into a remote server and find a particular image. The filenames are random strings, and the timestamps were useless as the files were recently copied from an archive drive without the `-a` flag. Having image support in the terminal would have saved me enough time to pick up my little one from kindergarten myself instead of having to send someone else to pick him up for me.

Re: lsix: ls for images

#83

Post by laumars »

a1369209993 wrote: post #66
TeMPOraL wrote: post #63

Earlier quoted context omitted.

I recall at least one vector drawing program offering PDF as target, and this being expected in some print shops, so yes, in some cases, PDFs can be images. PDF is a weird format with a bunch of disjoint use cases.

GIMP offers ASCII art as a target, and that's expected by line printers/teletypewriters; does that mean TXTs can be images?

That’s a weird edge case. It’s images to us nerds and hackers but it’s certainly not images to anyone in print. Where as PDFs were used to send final magazine pages (for example) which were ready for print.

(Source: I worked for a publishing company in the 90s)

Re: lsix: ls for images

#84

Post by laumars »

aasasd wrote: post #47
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…

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.

The moment you pipe ‘ls’ it will fallback to using just one column.

In fact a great deal of CLI tools (and particularly coreutils like GNU) will have nice usability features this will auto-disable the moment the output file is not a TTY.

For example, run the following commands and compare the output:

    ls ~
    ls ~ | cat

    grep --color=auto ${hostname} /etc/hosts
    grep --color=auto ${hostname} /etc/hosts | cat
You might be surprised at just how different and predictable the terminal utilities behave when they detect they’re being piped.

Re: lsix: ls for images

#85

Post by jchw »

bmn__ wrote: post #76
jchw wrote: post #67

Earlier quoted context omitted.

Yeah, you just described how too. KDE used to thumbnail txt files with a portion of their actual text.

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.

Re: lsix: ls for images

#86

Post by laumars »

alanbernstein wrote: post #58
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…

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) and something that all tools for those respective platforms behave the same around. And to be fair, it’s a massively old convention that made sense back before metadata was a thing so it’s not even without some rationale.

Ultimately though, the issue here is you don’t want any files hidden by default. Which is the opposite of the point of a hidden file. So you’d have the same complaint if the “hidden flag” was file system metadata (eg on NTFS) as you would want if it were a file name prefix.

Re: lsix: ls for images

#88

Post by tempay »

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.

In my experience of academia, using PDFs as an image format is extremely common for sharing plotted data. The only common alternatives are (E)PS and PNG which are much worse.

Re: lsix: ls for images

#89

Post by wazoox »

Doesn't seem to work neither on Ubuntu nor Slackware Linux for me... It only outputs some error messages about "missing delegates for this format" and other errors (ImageMagick 6.9.7.4 and bash 4.4.18 in one case, and IM 6.9.4 and bash 4.3.48 in the other; same kind of errors).

Re: lsix: ls for images

#90

Post by jopsen »

lainga wrote: post #46
jopsen wrote: post #21

Earlier quoted context omitted.

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?

You're describing Powershell's object-passing.

I know... But didn't want to think about that.

I agree shells are great and PowerShell is confusing.

It's merely amazing text is still king.

Post reply on HN