Show HN: Facad – A colorful directory listing tool for the command line

[y-f-honeyguide]

https://github.com/yellow-footed-honeyguide/facad

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'

Facad takes this concept further, offering more flexibility and visual clarity.

[lelandbatey]

Why four column and not one column? If I add a new file that's longer than the old ones, the columns will re-flow and now where I used to look is no longer where I was looking, it's moved off to the side. Why not have just a single column so your eye only has to move in a single direction to find things, a-la `ls -alh` ?

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

[SuperNinKenDo → lelandbatey]

A huge amount of wasted horizontal space would be the main reason I guess. Me, I prefer a `-l` most of the time though, personally.

[y-f-honeyguide]

Hello everyone,

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

   I've also added emoji-based visual representation of file permissions for improved clarity. You can see these updates in action in the screenshots on the GitHub release page: https://github.com/yellow-footed-honeyguide/facad/releases/tag/v2.1.0

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!

[grugagag]

This is cool. I’d fancy a set of command line tools that drop you briefly into simple TUIs to make discoverability and composition intuitive. Something like fish or zsh but more advanced a few notches.

[tovej → grugagag]

Would a commander type TUI work for you?

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

[romwell → tovej]

I should add the venerable FAR Manager to the list:

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

[tovej]

Feels like there are a lot of fancy human-used terminal listing tools these days, and to me all of them feel like a waste of time.

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.

[atorodius → tovej]

Some strawman arguments IMHO

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

[tovej → atorodius]

1) Except it doesn't work on the standard set of terminals installed on most systems. SSHing into some vanilla flavored system (a VPS on AWS/linode, <insert company>'s internal servers, your raspberry PI) and using these tools does not work out of the box on any system

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

[mixmastamyk → tovej]

Generally shouldn’t ssh into production servers. Exceptions can use ansible if needed. Simply not caring they are different is an option too, if a small fraction of time.

[dadarecit → tovej]

you must be fun at parties

[tovej → dadarecit]

I would like to think that I am. But we're discussing a technical topic on an industry forum, not at a party.

This site is still named hacker news, I would assume software projects should be discussed from a hacker's point of view.

[motohagiography]

the idea of having emojis in the terminal opens up the conceptual possibility of publishing web like applications that are navigable by a basic shell DSL and no browser.

[specialist → motohagiography]

A REPL for the hypermedia? Intriquing idea. I'd probably go for something like that.

[skeptrune]

I'm so for this. I wish more things came as a TUI. More emojis seem great. Makes it much easier for folks who don't work in the terminal consistency to use it.

[sp0ck]

My ls alternative: alias ls 'exa -lh --color always --group-directories-first --icons' alias tree 'exa --tree -L3 --long'

[yencabulator → sp0ck]

FYI exa is unmaintained, you want eza these days. Link in the exa repo (some of the eza people have push access to exa repo, but can't touch the website etc).

[dhruvkb → yencabulator]

I would love to see if you would try `pls` and provide your thoughts? Disclaimer: I am the maintainer of the project.

[pls]: https://pls.cli.rs

[0xfeba]

How do you pronounce the name?

[flyingcircus3 → 0xfeba]

I assume its pronounced the same as "facade" - an outward appearance that is maintained to conceal a less pleasant reality.

[airstrike → flyingcircus3]

Which is really "façade", but oh well

[Tagbert → airstrike]

That would be the French equivalent to the English word, facade.

[lionkor → airstrike]

"fashade"?

[airstrike → lionkor]

Only if you're Sean Connery

RIP

[fsckboy → lionkor]

no façade, is pronounced fah-sahd, fah as in

"do re mi fa" <-- that one,

then make "-sahd" rhyme with that.

[SwiftyBug → lionkor]

"fassade"

[nullbyte → 0xfeba]

Lord Farquad

[wmeredith → 0xfeba]

I assume it's the same as "facade" https://www.merriam-webster.com/dictionary/facade

[mmh0000]

What is the benefit of sorting on extensions? Since extensions have no meaning to the kernel and, only a few oddball applications (tar, gzip) care about extensions.

The emojis are cute, but is it really quicker than reading a `-`, `d`, or `l` in the ls output?

This is my daily goto:

  alias ls='ls -Av --time-style="+%Y-%h-%d %r" --group-directories-first --color'

  alias ll='ls -lh'

[lolinder → mmh0000]

> Since extensions have no meaning to the kernel and, only a few oddball applications (tar, gzip) care about extensions.

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.

[ruthmarx → lolinder]

> only a few oddball applications (tar, gzip) care about extensions.

Most desktop gui programs care about extensions.

[burnte → mmh0000]

> What is the benefit of sorting on extensions? Since extensions have no meaning to the kernel and, only a few oddball applications (tar, gzip) 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.

[anigbrowl → mmh0000]

I always sort on extensions. I want to know what things are and group similar things together.

[kristopolous → anigbrowl]

Ideally are we talking extension or mime here and if it's the latter, how far down do you slice? Do we separate our PNGs from our JPEGs?

[Modified3019 → kristopolous]

Yes. The easiest thing to do is just group by same extension, moving onto the next one alphabetically.

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.

[GlacierFox → kristopolous]

Yeah :S

[shric → anigbrowl]

I usually group similar type things into directories so that I don't get much of an extension mix. The exception is my download directory and for that I generally want to order by time or size.

[IgorPartola → shric]

Something like photos processed by darktable are a good example of why this isn’t always practical. You have your raw files and your sidecar files side by side. You could separate them in settings I suspect but that’s not the default and god forbid you ever lose one. If you are in the habit of putting JPEGs in the same place you really want to separate by extension.

[Tagbert → shric]

I always group by project. The OS can handle different file types in a folder. I need to be able to archive a folder and have all of the files regardless of file types.

[imbnwa → mmh0000]

> alias ls='ls -Av --time-style="+%Y-%h-%d %r" --group-directories-first --color'

Stupid macOS ls binary: unrecognized option `--time-style=+%Y-%h-%d %r'

[mmh0000 → imbnwa]

Use homebrew to install gnu coreutils.

MacOS uses traditional Unix tooling, not GNU.

[nine_k → mmh0000]

With 30+ years of history, GNU userland is also "traditional". But it's not BSD, and Apple is not a big fan of GPL.

[mmh0000 → nine_k]

Yeah, but GNU's Not Unix, so... GNU tooling isn't "traditional Unix tooling" =P

It might be traditional, but whatever tradition it is, it isn't Unix =D. I could argue this all day long!

;)

[rswail → mmh0000]

Use Macports, it works better with MacOS and the existing frameworks etc.

Has all the same things like the GNU coreutils etc, they live in /opt/local/bin and don't fight with SEP or users.

[jshen]

I can never get icons to work on remote machines when I SSH in. Is there some doc or blog explaining how this stuff works?

[3np → jshen]

Check your TERM variable at every level. If you use screen or tmux, do without first.

Server side may need some additional terminfo depending on software, server, and terminal (e.g. kitty-terminfo package if you use kitty).

[jshen → 3np]

Thanks, what am I checking for?

[mafriese]

Is this in any way better than eza? https://github.com/eza-community/eza

[thelibrarian → mafriese]

I guess if you prefer emoji over Nerd Font icons?

[dhruvkb → mafriese]

I would love to see if you would try `pls` and provide your thoughts? Disclaimer: I am the maintainer of the project.

[pls]: https://pls.cli.rs

[whalesalad → mafriese]

TIL eza is a continuation of exa

[imbnwa]

>alias ls='ls -A -F --group-directories-first --sort=extension --color=always'

Stupid macOS ls binary: unrecognized option `--group-directories-first'

[tambourine_man → imbnwa]

Not stupid, just BSD heritage, not GNU. See FreeBSD

[mprovost → tambourine_man]

Another comment was arguing that anything since POSIX is a "waste of time", presumably including the GNU extensions. (The BSD utilities were the first "user-friendly" alternatives to the original AT&T versions...)

[jeffhuys → imbnwa]

Use brew to install gnu coreutils…

[lolinder]

I like it! The emojis make it really easy to identify files at a glance—with more precision than the simple `d` and `l` indicators in ls.

[ilaksh]

Nice. There is also 'exa'.

[elashri → ilaksh]

exa is unmaintained, you can use the active fork eza instead [1].

[1] https://github.com/eza-community/eza

[dhruvkb → elashri]

Another alternative is `pls`. Disclaimer: I am the maintainer of the project.

[pls]: https://pls.cli.rs

[ast21 → elashri]

lsd is also a good cross-platform alternative [1].

[1] https://github.com/lsd-rs/lsd

[codedokode]

Regarding emojis: I believe they should be monochrome in console. The problem is that when you have text with emojis they stand out too much and distract you. So they should be monochrome, not so large and not so standing out.

[stouset → codedokode]

Do most emoji actually look decent in monochrome in practice?

[lolinder → stouset]

You'd get an emoji font specifically designed to be monochrome:

https://emojipedia.org/noto-emoji

[seanw444 → stouset]

Unless they mean a completely new style of emoji to complement the monochrome, then I'd say no. Flattening existing emojis to one color would probably be awful.

[sanex → seanw444]

Like some of the random notification icons on Android that are just a circle. Useless.

[uniq7 → codedokode]

You can configure your terminal to use a custom font with monochrome emojis.

[klardotsh → uniq7]

Sometimes... one of the biggest problems with TUIs is that every terminal emulator is extremely opinionated about how it wants to render anything that isn't trivial ASCII, even in 2024.

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.

[kccqzy]

I don't like emojis in this context. I like them when humans use them to communicate over text when facial expressions and such aren't available. I feel weirded out when a computer program sprouts emojis at me. A computer program needs to treat human users with respect, and emojis convey the wrong tone. Like languages with T-V distinction, emojis strictly belong to the T form and are unsuitable for communication from a computer program to a human.

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.

[Supermancho → kccqzy]

> I like them when humans use them to communicate over text when facial expressions and such aren't available.

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.

[hatthew → kccqzy]

These are technically emoji, but in my perception it would be accurate to call them icons.

[bbor → kccqzy]

I encourage you to try to move past it, you’re missing out! Of all the arbitrary cultural norms, “computers should only use icons, not emojis” is the most arbitrary. No offense ofc, and I believe you that the psychological effect is real — I’m just saying it’s probably an arbitrary one that would go away pretty quickly.

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.

[sgarland → bbor]

Hard pass. I want my terminal to present me with text, and only text. That way, as I cry bitter tears of defeat, the textual output will remain, stolidly presenting its harsh reality to me. Emoji would falsely present an aura of hope and congeniality where there is only pain; the cruel reminder that I have once again failed to live up to its inflexible and demanding expectations.

…seriously though, I have absolutely no desire for emoji in the terminal.

[Sleaker → sgarland]

Emoji are text though?

[sgarland → Sleaker]

When (Western) people say text, they generally mean ASCII. If your language requires glyphs, that is of course reasonable to also be called text.

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.

[ehnto → sgarland]

Emoticons was a western word for emoji I think, which originated in Japan. Emo(emotion) Ji (glyph/character).

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.

[f33d5173 → ehnto]

picture (e) character (moji) actually

Though the similarity to emoticon is amusing.

[ehnto → f33d5173]

Oh yeah, you are right. I had recalled it was a contraction of emotion and character.

I wonder if the specific kanji for (e) was picked for it's reading, and thus double entendre in English, intentionally.

[ruthmarx → ehnto]

> Emoticons was a western word for emoji I think, which originated in Japan.

Emoticons predate emoji are were always purely ascii text based.

[mprovost → ruthmarx]

In an alternative universe where someone other than Americans invented the popular character set, would emoticons have existed at all if computers had the capability to display Unicode glyphs from the start? It feels like still insisting on using Morse code after keyboards were invented.

[ruthmarx → mprovost]

> would emoticons have existed at all if computers had the capability to display Unicode glyphs from the start?

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.

[ehnto → ruthmarx]

I prefer the aesthetic of it.

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.

[sgarland → ruthmarx]

Yes, though there were intermediaries like CP437 [0] which contained crude emoji. That said, though I was exposed to them growing up in the 90s, emoticons by far dominated every message board and chat service I ever used. Emoji didn’t really take off (at least, in America) until smartphones hit.

[0]: https://www.aivosto.com/articles/charsets-codepages-dos.html

[sham1 → sgarland]

Eh, you'd get plenty of Westerners who'd argue that text goes beyond ASCII. Most of Europe, for example, requires Latin-1 at the very least.

Not to even mention Greek and the like.

[sgarland → sham1]

Fair point. I still think there’s a vast difference between letters / glyphs and emoji, though. One is the default for communication, the other is optional at best.

[drdaeman]

Looks nice! I think it would be cool to know the differences between Facad, lsd, and eza (https://github.com/lsd-rs/lsd and https://github.com/eza-community/eza) aka "why do I want to try Facad rather than alternatives". No offense meant, but the latter two already exist for a while, available in most distros and seem to do at least approximately the same thing.

[bbor → drdaeman]

Also, AFAICT both of those offer icons, not emojis — though at least lsd is open to manual configuration. Cute, either way! This is a way more fun way to waste time than comparing IDE fonts, thanks for sharing. Will have to try out all three tonight

[nine_k → drdaeman]

Apparently Facad is much smaller, less feature-rich, written in C (both lsd and eza are written in Rust), and uses slightly more permissive license (MIT).

[srockets]

But can you use it to play Flappy Bird[0]?

--

[0] https://www.youtube.com/watch?v=AUSNWkdvoRo

[ok123456]

Hardcoding the ANSI escape characters hurts portability. Try looking up the escape using termcap/terminfo.

[jstanley → ok123456]

Hurts portability to what?

Maybe it once did, but now it's akin to complaining that a program misbehaves on EBCDIC systems.

[ok123456 → jstanley]

For instance, if you detect that it's not going to a terminal, but rather a pipe, you probably don't want terminal escape codes and want the dumb terminal entry.

[dang → scudsworth]

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

[fsckboy]

what does it mean to pipe the output?

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

[umbra07 → fsckboy]

this isn't an 'mc' replacement, this is an 'ls' replacement for traditional-style terminal use.