I avoid them unless I'm capable of maintaining them myself. My primary reason for using classic Unix utilities is trusting that they'll still work in a few years. The initial stages of a rewrite can be a lot of fun, but I want to use it long after the excitement has worn off.
It frankly doesn't seem like a deprecation in the traditional sense.
tools like ls or grep are certainly showing their age, but that has also been their strength. The POSIX ecosystem comes in many flavors but I can always depend on it.
It’s not like I can ever expect to shell into any arbitrary system or container and expect to have exa/lsd/rg or any of these nice replacements available to me. My tooling needs to be somewhat more portable.
Ah yes, because it's 100% impossible to learn new tools and fall back to the core ones when you need to. ;P
I've been doing this for decades now, it's just not that big of a deal.
if [ -z "$(which exa)" ]
then
LS1='ls -1'
else
:
fi
${LS1} ${SOME_DIR} | ...
?But if what the comment I replied to meant by "capable of maintaining them myself" was about having an organizational structure where they could become an official maintainer of the official project rather than needing to fork it if the owner becomes unavailable, then yep, that's a great point about these single-owner projects.
But my original interpretation was about the difficulty of maintaining the code. To me, these rust tools are a huge improvement in that way.
But in practice, the tooling for making those tools never got very good. (That is, in my opinion - there is at least one commenter here who replied to me about actually liking autotools, which is fair enough, just not my opinion.)
So while fully recognizing the value of the old tools that will always exist, for new useful tools, I'm very happy to see this renaissance of writing them in rust. In my opinion, it is much easier to build them, dig into their implementation, and contribute to them (especially without introducing security vulnerabilities or data races).
Where I do absolutely agree, and what I do wish for is that more of this were being done under the auspices of an organization, like how the `ls` most of us are using is likely maintained by either GNU or one of the BSD organizations.
After not noticing for months, because exa kept on wokring fine and still being more pleasant than `ls`. Oh noooooo.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
Which ones gave you trouble?
A timeless tautology.
Some things just are easy and pleasant. Caddy server, Cargo, ripgrep come to mind. Some things are easy only once you've learned them. No kidding!
Agreed that cargo has bugs and I hope it improves over time (granted: it is not at all new). But say what you want about cargo, at least it's an ethos!
> I saw a book entitled "Die GNU Autotools" and I thought "My feelings exactly". Turns out the book was in German.
https://twitter.com/timmartin2/status/23365017839599616
gnu autotools i suppose works for some projects, but wow does it seem to be completely annoying to use.
Even VS Code uses it for its search beneath the hood.
Related: the Lindy effect (https://en.wikipedia.org/wiki/Lindy_effect)
Beware of [HN] bias. People are very quick to rain on Rust for reasons none of them have ever explained substantively and with facts, and many others are quick to agree without checking.
I'm not sure what this paragraph is doing in this context. I was specifically talking about my own experience. I see far more praise for Rust compared to negative comments in any case, and was biased towards assuming "Rust rewrites of tools may lack features (due to being newer) or be less portable or whatever else, but the one thing they'll have is stability and reliability". That came crashing down when exa crashed and core dumped.
It didn't turn me into some anti-Rust fanatic either (which people seem to interpret any criticism of Rust-related things as), it just made me realize that in the end it's still up to the individual tool and programmer, and I shouldn't make strong assumptions based on the language a tool is written in.
Just a small precautionary statement. I've observed it enough times to get very wary of it.
> I see far more praise for Rust compared to negative comments in any case, and was biased towards assuming "Rust rewrites of tools may lack features (due to being newer) or be less portable or whatever else, but the one thing they'll have is stability and reliability".
Filter bubbles in a nutshell, I usually see mostly negative ones and barely see any praise (though I'd define "praise" here as "fan-boying", and NOT as "recognizing the strong sides"; the latter is quite normal and should not be called praising).
> That came crashing down when exa crashed and core dumped.
That's the part I find a bit overly dramatic, this was likely Rust's `panic` mechanism so they likely just didn't handle an expectation / assertion in the code? I had several Rust services in production for years and former colleagues have contacted me to tell me the thing hasn't crashed even once and was only ever restarted for upgrades.
> It didn't turn me into some anti-Rust fanatic either (which people seem to interpret any criticism of Rust-related things as), it just made me realize that in the end it's still up to the individual tool and programmer, and I shouldn't make strong assumptions based on the language a tool is written in.
Yes, fair. If you pepper your Rust code with `.expect()` and `.unwrap()`, the program ending abruptly is expected because the team hasn't taken precautions to handle all possible errors.
Mine is that they're ubiquitous and I can rely on them existing on all Unices. For the same reason, I avoid getting used to any features that are unique to a particular platform or distribution. It just causes additional friction when I'm working on a different system.
Exa was nice but it's command line options were just different enough in places to clash with my muscle memory. Lsd looks a lot closer.
The muscle memory of `ls -alt` and `ls -alrt` was too powerful for me to switch to `-snew`, even after literal years.
This was actually a big draw of GNU implementations in the mid-to-late 1980s vs. the "then classics" of the mid-to-late-1970s. Before the dominance of Linux / OSX, people on SunOS / Ultrix / HP-UX / Irix / AIX / *BSD would often quickly install those more featureful GNU utilities. I imagine AIX/*BSD people still do.
Quite true for many in the macOS subset of BSD
well-rustomized
There, fixed it for you.
But holy hell is getting a working font a nightmare. I spent multiple days desperately trying to figure out font issues, because LSD refuses to list what fonts actually work for it.
And if you just something from Nerd Fonts thinking it will work, you'll find that 3/4 or more are missing some stupid symbol or another that LSD uses.
And then you find out that getting it working on other systems is awful. WSL which uses the Windows command prompt under the hood needs a TTF version instead of OTF, which many Nerd Fonts don't bother to make. On MSYS2 it just indefinitely hangs. It's a nightmare.
I have gotten LSD to work once in all my trying on one system.
You could use Windows Terminal instead? Or does it have the same issue?
None of those three "use" anything.
On machines that predate the new ConPTY replacement mechanism (so, everything before Win11), any app that is a command line program (such as cmd.exe, Powershell, anything compiled to be a console program and not a GUI program (this can be any program, and is chosen at compile time)), it is ConPTY.
ConPTY can see OTF fonts (afaik, I remember that working, I don't have a system old enough to check), but can't see any fonts that are in your user font directory (%LOCALAPPDATA%\Microsoft\Windows\Fonts).
As of Win11, however, ConPTY (which has been in existence since NT4, and has been an ugly pain in the ass for just as long) has been replaced with a mechanism to allow you to chose which one you want: a user supplied terminal that can supply that dependency (currently only Microsoft Terminal, but it is documented so any terminal can do it), or a ConPTY replacement owned by the Terminal team (which is basically the renderer and parser ripped out of Terminal, and a massive in-place upgrade, while still looking and acting like ConPTY otherwise). If the old ConPTY can't see OTF fonts (which would stem from using the oldest and most classic font API still in Windows), the new one can (as it uses DirectWrite).
On Win11 machines set to use Terminal instead of new-ConPTY, launching cmd.exe, Powershell, WSL.exe, or any other console program, will launch Terminal to display itself if not already in a console session.
However, fundamentally, for the entire conversation preceding this, it doesn't matter if a font is TTF or OTF for the purposes of supplying Unicode or Nerdfonts icons. OTF only matters if you want Type1-style glyphs (cubic Bézier curves vs quadratic) or want to use OTF features (which aren't meaningful for terminals, generally).
* Windows shells (at least for me, right now) won't DETECT a .otf font. You can't even choose to use it in the options of powershell/prompt/etc
* Most nerd fonts don't bother to convert to TTF. They only provide an OTF.
Even if they're fundamentally the same that doesn't matter if Windows won't detect it in the first place to let you select it.
This ConPTY replacement ('Windows Terminal') sounds fairly recent, so I think you'll forgive me if I didn't know about it. Our work machines only updated to Windows 11 in the last couple of days.
In any case, without access to the store I can't install it anyways. Nice for those who are on 11 already and have access though.
They use the nerdfont patcher, which mainly mutilates fonts, and often breaks them trying to add the nerdfont glyphs. The nerdfonts project also distributes these broken fonts while ignoring the font licenses, and also ignoring the fact that fonts update and then nerdfonts refuses to patch and distribute the new version.
Many projects distribute both OTF and TTF versions, while nerdfonts only distributes the patched OTF version (as you, indeed, have noticed).
The upside is, since the patcher exists, you can just run it on your own fonts and do whatever you want.
I highly recommend avoiding nerdfonts altogether, disable it in any program you find it in, and also consider filing bugs with those projects to entice them to remove support entirely.
Unicode exists for a reason, and fonts should strive to cover as much of it as possible. Corporate logos and custom icons should not be enshrined into any font, not even as something niche like nerdfonts, even if nerdfonts lives entirely in the Unicode private use area (PUA).
The issue also lays with LSD, since they recommend Nerd Fonts.
I always try to push projects to, if they choose to support nerdfonts, to default to off. It is confusing for new users to have to install a specific font (especially when they probably already have their chosen font, and possibly one that can't be nerdfont patched) to use a program.
LSD, in particular, can just either turn symbols off or just map them to commonly available Unicode symbols (a "well formed" terminal font covers most of, if not all, of the Box Drawing, Geo Shapes, Legacy Computing, and Arrows Unicode blocks, which is all you really need).
2019 first release, replaced the old Windows Console as a default since Windows 11 22H2.
Both projects are amazing little utilities that when combined with a well-customized shell, really make using the terminal a joy.
I absolutely love the trend of rewriting classic Unix utilities in rust, because the new tools often have (small or large) usability and quality of life improvements that altogether make the terminal a much more powerful environment.