Hacker News new | ask | show | jobs
by Klonoar 1022 days ago
If the owner is outright missing, to the point where the newer fork owners can't even get the repo archived, one would reasonably assume that they'd need to rename/rebrand the tool in order to publish it elsewhere.

It frankly doesn't seem like a deprecation in the traditional sense.

1 comments

Either way, it still speaks to the maintainability of these modern replacements, many of which are personal projects.

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.

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

... as in

   if [ -z "$(which exa)" ]
   then
     LS1='ls -1'
   else
     :
   fi
   ${LS1} ${SOME_DIR} | ... 

?
I just have in my personal systems ls aliased to exa (with some of my preferred options like group-directories-first) and on other systems it's still ls. So my usage is the same regardless of whether it's exa or ls. This isn't a programming language or a complicated tool like jq vs competitors where what I need to do changes. I just get the nicer presentation on my local machine and "graceful degradation" back to the defaults of GNU ls on remote machines which don't have my preferred setup installed on them.
If you do that consider if command -v exa > /dev/null instead, so you don't spawn subprocesses unnecessarily.
Exa is an interactive utility. It doesn't make much sense to put it in a script like that. If you were to use rg or ug instead of grep, branching like that would probably be worthwhile, though.