241–250 of 280 posts
- ranger (and the ranger-cd script) are pretty useful to explore folders in the terminal. https://github.com/ranger/ranger - percol and ripgrep as alternatives to grep - tig as TUI for git - kakoune as alternative to vim
I like vifm over ranger. Simple dual pane with vi key binding.
Earlier quoted context omitted.
Notmuch, which is IMHO superb and totally underrated. I like it a lot due to its clever architecture. It never ever touches your email. It operates on a separate tag database. Then, it's the task of a backend to translate tag changes into maildir actions before and after syncing email. Keeping tag to actions decoupled from the GUI is extremely clever, because it allows implementing basically any email workflow you ca…
+1. I spent a while trying to persuade Apple Mail to let me receive notifications only for threads I was 'watching'. I never did come up with a sane answer, and finally decided "well, I use Emacs for almost everything else. Might as well see how email pans out..." With notmuch and mbsync I have the best email setup I ever have. I wish I'd done it years ago.
Is Rust a particularly good fit for CLI tools like these ? Why so ?
$ filewatcher '**/*.js' 'jshint $FILENAME'
Earlier quoted context omitted.
Plain text was chosen to interface the various programs of Unix OSes because it's the least common denominator all languages share. It also forces all tools to be composable with each other. You can take output text that was obviously not formatted for easy consumption by another program and still use all the information it outputs for input into another program. Programs that were only thought to have users handling…
How hard is it to come up with a object format (more like a data structure format since I wouldn't want logic/code being passed around) and then come up with a standard text serializer for it? Not that hard, in my opinion. You'd standardize it once via an RFC and you'd be done with it. I don't think your problem is as big as you say it is. The real problem is that this pile of code we already have kind of works and i…
Earlier quoted context omitted.
Which I can then pipe to "gron" so that I can make something sensible and greppable out of that json output, right? ;)
Well, you could pipe it to "jq" - https://stedolan.github.io/jq/
Earlier quoted context omitted.
Of course, because someone wrote a md5 executable for you to call. You can do the same on PowerShell and write a pipeline just the same way.
You're right that a shell alone can't calculate md5 but a separate md5 binary does it for you, but the question still stands when the common answer on the internet seems to be to write that cryptic code as that's probably the easiest way provided on PowerShell. The best alternative I could find is some community maintained PowerShell extension (with just 177 GitHub stars now), which is far better but the lack of inte…
GNU Parallel is the first thing I usually install on top of a standard Unix userland. It's almost a superset of xargs, with many interesting features. It depends on perl, though. htop is also pretty much a great replacement for top. And ripgrep a great replacement for the find | xargs grep pattern. Aside from that, I'm pretty content with the Unix userland. It's remarkable how well tools have aged, thanks to being co…
I had issues using gnu parallel in the past because of --will-cite. I ended up not using it.
I usually just run --citation once on a new system, and never see the notice again, and I have never had the notice cause any problems as it only shows if the output is to the screen.
Earlier quoted context omitted.
For just listing without additional info, I'm good with just the file tree. With '-l' it can show bunch of stuff. $ l (exa --tree --level 1) https://i.imgur.com/RxppCIt.png $ l2 (exa --tree --level 2) https://i.imgur.com/Mba79iz.png
How did you get the folder/file icons in there?
Earlier quoted context omitted.
Plain text was chosen to interface the various programs of Unix OSes because it's the least common denominator all languages share. It also forces all tools to be composable with each other. You can take output text that was obviously not formatted for easy consumption by another program and still use all the information it outputs for input into another program. Programs that were only thought to have users handling…
How hard is it to come up with a object format (more like a data structure format since I wouldn't want logic/code being passed around) and then come up with a standard text serializer for it? Not that hard, in my opinion. You'd standardize it once via an RFC and you'd be done with it. I don't think your problem is as big as you say it is. The real problem is that this pile of code we already have kind of works and i…
Also there is no need really to change anything (as in, breaking existing scripts). Selecting a different output format can simply be a command line option. Many tools already offer Json, XML or CSV output. But since development of those tools is so decentralized you'd be hard pressed getting them all to agree on one. But theoretically you can pick any tool you want right now, add --json support and submit a patch.