Hacker News Reader

Comment by userbinator | Hacker News Reader

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 ask specifically" --- which would just create more confusion than anything. As someone who has used the commandline for many years, one property which needs to be present for good usability is consistency. Having a bunch of edge-cases and special behaviours makes a tool hard to use for anything but the most extremely basic of operations.

View on HN

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

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.

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.

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)

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.

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.

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

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

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

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.

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.

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.

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.

You are right. I think the behavior should be:

    toolName /somepath  # process all files the tool chooses to
    toolName /sompath/* # process every single file, even files it does not support (with a warning)

This is far closer to standard behavior.

In the second case, toolName would not be aware of the '*' unless it was single-quoted. Bash would expand it to match every file, and the toolName binary would see $argN as each filename.

ls does not show files starting with .

But there is a driving purpose behind that, hidden vs non-hidden is binary. With so many media formats I agree that consistency is very important.

The reason is because it was a lazy hack to hide . and .. from ls and then people started using this behaviour to hide files.

It's still largely arbitrary. I'm pushing back against the general notion that standard Unix-y command line tools are some shining example of consistency. Most of it is just us confusing familiarity for consistency.

There are some edge cases, but those cases are well-known and simple to understand.

If you haven't run across it before, google up The Unix-Haters Handbook for an entertaining book-length rebuttal.

Yeah, but those files are known as "hidden files". In other words, it is the creators of those files who purposefully prepend them with a . to hide them from ls and other tools.

One can argue whether this "starting with a . means hidden" is a hack or not, but I think it's manifestly different than not showing particular file types based on size or something like that.

I agree just not showing pdf files by default because they render slowly is a design mistake.

The thing I'm getting at is not whether one behaviour or another is 'right' - just that they are both inconsistent so in this case 'consistency' is probably not the right design criterion on which to base this criticism.

> One can argue whether this "starting with a . means hidden" is a hack or not

The story from Rob Pike is that this came about from a combination of (1) not wanting to show "." and "..", and (2) some sloppy programming in the implementation of that feature.

https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp

Reply on news.ycombinator.com