Earlier quoted context omitted.
Just another "command not found" on that remote machine you forgot you were on.
Not hard to fix: if command -v exa &> /dev/null; then alias ls='exa' fi
alias vim='$(command -v nvim || echo vim)'151–160 of 244 posts
Earlier quoted context omitted.
Just another "command not found" on that remote machine you forgot you were on.
Not hard to fix: if command -v exa &> /dev/null; then alias ls='exa' fi
alias vim='$(command -v nvim || echo vim)'Earlier quoted context omitted.
Just another "command not found" on that remote machine you forgot you were on.
This is the problem with all tools outside the most basic and you have to keep muscle memory for grep and ls to deal with it. Thus the fancy replacement tools have a cost. I can bear to pay that cost for "fd" (fdfind) and ripgrep but exa didn't really offer me enough.
If you spend a ton of time on remote machines you won't get control of, I can absolutely get it though. I think as long as you know the backup and you can adapt, we'll be fine most of the time. Knowing the idioms to get you part of the way there to the convenient functionality is a good enough mental polyfill.
Earlier quoted context omitted.
> 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} | ... ?
Earlier quoted context omitted.
> Most people don't type `ls` directly either. Aliases like `l`, `ll` and `la` are very common, in which case it really doesn't matter which tool you're using. Huh. I always use plain ls with flags and deliberately unset aliases like ll. I guess I'm weird.
You're not alone, is saving one character worth losing the muscle-memory?
I've been using LSD instead of Exa, so I'm lightly relieved that I don't have to change over. 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 termi…
I hope that the author Benjamin Sago is alright. It's always concerning when FOSS developers disappear for a while - even though it isn't uncommon.
Their personal site is gorgeous: https://bsago.me The tech notes are particularly useful: https://bsago.me/tech-notes There’s a ray of hope on their RSS feed: https://bsago.me/tech-notes/feed.json The last published date is September 2022, which is almost a year after their last GitHub activity: https://github.com/ogham?tab=overview&from=2021-12-01&to=202... So in absence of other information, I’d rather believe they…
Earlier quoted context omitted.
> Most people don't type `ls` directly either. Aliases like `l`, `ll` and `la` are very common, in which case it really doesn't matter which tool you're using. Huh. I always use plain ls with flags and deliberately unset aliases like ll. I guess I'm weird.
You're not alone, is saving one character worth losing the muscle-memory?
Here are my aliases:
if type exa >/dev/null 2>&1; then
alias l='exa -alg --color=always --group-directories-first --git'
alias ll='exa -aliSgh --color=always --group-directories-first --git'
alias lt='exa -@alT --color=always --git'
alias lr='exa -alg --sort=modified --color=always --group-directories-first --git'
else
alias l='ls -alh --group-directories-first'
alias ll='ls -al --group-directories-first'
alias lr='ls -ltrh --group-directories-first'
fi
I still retain `ls -ltrh` in my muscle memory, but after years of typing it, `lr` has saved me a lot of time and effort.Aliases are not just a way to type less. They also serve as a way to define configuration. If I ever need to tweak the output for all my usage of `ls`, I can just add it to all aliases, as I've done for `--group-directories-first`.
Earlier quoted context omitted.
And so will exa, probably. And if it won't, it will be forked. Which is exactly the reason "ls" is working perfectly fine for you today. The original AT&T UNIX "ls" has been forked over and over again and rewritten from scratch several times. You're using an evolved fork of this "ls" if you're using macOS or BSD, but if you're on Linux you're using a rewrite (GNU coreutils ls), and if you're running BusyBox you're us…
That's mostly rubbish though. The reason ls works perfectly fine today is no one dares fuck with the interface in case they break everything that depends on 30 years of assumptions even if they do suck a little bit. That includes all the forks and rewrites. This is almost entirely missing in "modern" software development. And I don't think any of us have time or energy really to track down varying different forks of…
Earlier quoted context omitted.
> 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} | ... ?
Earlier quoted context omitted.
Their personal site is gorgeous: https://bsago.me The tech notes are particularly useful: https://bsago.me/tech-notes There’s a ray of hope on their RSS feed: https://bsago.me/tech-notes/feed.json The last published date is September 2022, which is almost a year after their last GitHub activity: https://github.com/ogham?tab=overview&from=2021-12-01&to=202... So in absence of other information, I’d rather believe they…
[flagged]