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