Show HN: Facad – A colorful directory listing tool for the command line (github.com)
Facad is about functionality, not just aesthetics. Key features:
- Intuitive file type representation
- Smart sorting (directories first, then by extension)
- Four-column layout for quick directory analysis
It evolved from this alias:
alias ls='ls -A -F --group-directories-first --sort=extension --color=always'
107 comments
[ 4.2 ms ] story [ 141 ms ] threadhttps://emojipedia.org/noto-emoji
Sometimes you can select color emojis. Sometimes you can't turn OFF color emojis. Sometimes you can set font preferences to use something like FSD Emoji [1] where possible and fall back to other fonts, sometimes you can only set a single font.
Don't get me started on box drawing characters and, worse than any of the above, ligatures (which most open-source terminals have either a religious aversion to at the expense of their users, or refuse to implement any solution that doesn't meet the performance bar similar to non-ligatured font rendering, which functionally means we'll probably never see ligature support in those terminals).
My dream UI I think might be "every window is FLTK/FOX/other lightweight UI toolkit (maybe that one Rust tools like `amdtop` use?), strictly adheres to a system-wide theming protocol (a-la GTK2, most QTs, etc) that provides a highly consistent human interface, and provides Vim-style bindings and a `:command` bar and otherwise pretends to be a terminal window in all ways except the "actually being a monospace character grid" part. In other words: a GUI that pretends mice were never invented (or rather - makes them fully optional and interchangeable with the keyboard). But instead we have the stupid modern UI dichotomy of "keyboard fans have to fit their lives into a character grid, mice fans have to deal with shipping all of Chromium and not one single app on the system looking even remotely like any of the others, and keyboard support is unpredictable at best".
[1]: https://fsd.it/shop/fonts/fsd-emoji/ , note that it's woefully incomplete and honestly this ends up creating an even more jarring experience than just using color Noto/Twemoji everywhere.
The emojis are cute, but is it really quicker than reading a `-`, `d`, or `l` in the ls output?
This is my daily goto:
So .jpg’s would be separate from .jpeg’s, despite meaning the same thing.
While there are thousands of extensions, in practice most of the time you’ve got a dozen or less even in a “downloads” folder, so it’s not really a big deal to scroll to the gifs, jpgs, pngs separately if you are looking for all images.
This tool is pretty clearly meant to be consumed by a human—if you need a directory listing as part of a shell script you'd just use ls—and humans very much do care about extensions even if the kernel and application don't.
Most desktop gui programs care about extensions.
It communicates to the human what the file is, and makes it easier to find the file you want if you only have to look through 5 files of type X rather than 60 assorted files. Humans are the number 1 users of terminal interfaces, so this changes helps that demographic.
Stupid macOS ls binary: unrecognized option `--time-style=+%Y-%h-%d %r'
MacOS uses traditional Unix tooling, not GNU.
It might be traditional, but whatever tradition it is, it isn't Unix =D. I could argue this all day long!
;)
Has all the same things like the GNU coreutils etc, they live in /opt/local/bin and don't fight with SEP or users.
Note I often wonder about bare `ls` usage for the same reason; it always seemed terrible to me, hence why I never type 'ls' and instead always use the `ll` alias (though I've customized it from the default that Ubuntu gave me over a decade ago).
This made me recall that I have `export HOMEBREW_NO_EMOJI=1` in my shell startup. I wish all programs provide me with an opt out like this for this misfeature.
I believe emoji is shorthand for a tableau of common iconography. This is useful, because it is not limited to an OS specified set, allowing for user expansion and culture to determine the core set.
The folder icon, itself, is an emoji in this context.
Personally, “output a concise, hierarchical markdown document with heavy usage of emojis” is a must-have LLM pre-prompt. Helps with scanning the results quickly, and I have a hunch it helps it keep its reasoning straight for complex tasks.
…seriously though, I have absolutely no desire for emoji in the terminal.
I’ll grant emoticons (e.g. :-D) as being textual, because they are composed of the building blocks of ASCII. An emoji, though consisting of Unicode code point[s], cannot say the same, unless you’re arguing that they’re all bits, which is reductionist.
The distinction between one being text and one being pictures isn't a widely used one I don't think, please someone correct me if I am wrong. I think it's perhaps a retroactive distinction in certain social circles/settings but not particularly consistent.
Though the similarity to emoticon is amusing.
I wonder if the specific kanji for (e) was picked for it's reading, and thus double entendre in English, intentionally.
Emoticons predate emoji are were always purely ascii text based.
Probably not.
> It feels like still insisting on using Morse code after keyboards were invented.
For some of us older people it's a habit. Easier to type instead of going looking for an emoji, especially if not on a phone.
But also there are specific tones for me and long term friends, that are not perfectly captured in the myriad different pictures.
For example, ;_; and :P from english IRC days, do not map perfectly to the tongue out picture emojis in almost any set I have seen.
[0]: https://www.aivosto.com/articles/charsets-codepages-dos.html
Not to even mention Greek and the like.
RIP
"do re mi fa" <-- that one,
then make "-sahd" rhyme with that.
Server side may need some additional terminfo depending on software, server, and terminal (e.g. kitty-terminfo package if you use kitty).
--
[0] https://www.youtube.com/watch?v=AUSNWkdvoRo
Maybe it once did, but now it's akin to complaining that a program misbehaves on EBCDIC systems.
[1] https://github.com/eza-community/eza
[1] https://github.com/lsd-rs/lsd
[pls]: https://pls.cli.rs
Stupid macOS ls binary: unrecognized option `--group-directories-first'
https://github.com/MidnightCommander/mc
https://github.com/ranger/ranger
https://github.com/jarun/nnn
There's also superfile and broot. Personally I feel like they try to do a little too much, but that doesn't mean they won't work for you:
https://github.com/yorukot/superfile
https://github.com/Canop/broot
https://www.farmanager.com/screenshots.php?l=en
It's Windows-based, but has been open-sourced by the developer, and so it's got a Linux port[1].
The UI is the closest in spirit to Norton Commander[2], which is what inspired them all (and where the term "command-style TUI" comes from).
On the off-beat, the time is ripe for someone to fork one of these 2-pane split commanders, and brand it "Hawk TUI: Split On That Thing"(c).
[1] https://github.com/elfmz/far2l
[2] https://en.wikipedia.org/wiki/Norton_Commander
https://news.ycombinator.com/newsguidelines.html
if it doesn't mean anything, complete fail.
(piping the output of ls should also mean something better than it means, but you aren't improving ls if you don't improve that)
try midnight commander, seems like that's what you want to replace
[pls]: https://pls.cli.rs
1) There's so many assumptions made about the terminals and fonts these will run in. Are you really using emojis in your terminal workflows? And if so, why? do you sacrifice monospace for it? do you expect the tool to work on a new system (or remote system)?
2) What are you missing in ls? Can your tool even do all that ls can? If you need to sift through a lot of files, why are you listing files in the terminal? Why not use a search tool, terminal or graphical.
3) Your tool is not mandated by POSIX, ls is. ls will survive as long as we have Unix-like OSes, it will always be available in all Unix-like OSes. Your tool will survive as long as the maintainer feels like maintaining it.
In the end, if someone wants to develop an ls-like tool just to get the experience of designing, developing, and maintaining software, I'm all for it. But the technical reasons for adopting this are slim to none.
I do also want to say that a more structured API for machine readable listing of files and certain attributes could be very useful (mime type, project specific file type data, e.g. OpenAPI schema lookup, special magic bytes, etc), but that that is a different type of project than these yassified ls clones.
This site is still named hacker news, I would assume software projects should be discussed from a hacker's point of view.
1) if it works it works. I guess most people use a small set of terminals these days (ie 80% of users probably use 20% or less of terminals)
2) can just use ls if needed. The tool does not need to be a superset to be useful
3) most people use these on a few devices they own and where they can install non-posix tools. Are all programs you use posix? Seems wild
2) What _exactly_ is the use case?
3) If you can install non-posix tools, why not use a full-featured file manager? And if there is no use-case for a program, why am I installing more custom software on my system. ls is already installed, you still have to convince me that installing a less portable version of ls is worth more than the trouble of an additional dependency
P.S. regarding 3, I would not point this out if you had not claimed my post was "Some strawman arguments", but: your 3) is an actual strawman argument. You have created a strawman version of me that you are hinting only uses POSIX programs.
P.P.S. there is a real feature that would be useful for an ls-like program, which is listing directories with a huge number of files. Standard implementations of ls cannot handle reading directories with millions of files (even though the filesystem could) because of a misconfigured buffer size: http://be-n.com/spw/you-can-list-a-million-files-in-a-direct...
[pls]: https://pls.cli.rs
1) Thank you all for your support and feedback. All the questions you've asked are the same ones the skeptical part of me posed during development. And all the answers given are those my sanguine side provided (and even better).
2) I'm excited to announce that facad 2.1.0 is now available! This update includes two new features: -l, --long display detailed directory listing -a, --analytics display directory analytics
3) If you have any ideas for useful additions or features, please don't hesitate to share them. I would also greatly appreciate any advice on maintaining and growing an open-source project.Thank you again for your interest in facad!