With ramda-cli, the jq example would be:
npm outdated --json | ramda --raw-output 'map (.latest)' to-pairs 'map join "@"'CLI: Improved
191–200 of 280 posts
Re: CLI: Improved
#192Another tool I use religiously: `autojump` (aliased to `j`) rather than `cd`. It learns where you go and lets you fuzzy-jump there. https://github.com/wting/autojump I also use `loop`, my own Rust-based replacement to bash's native loops: https://github.com/Miserlou/Loop
The "learn+fuzz" part seems to always produce weird results due to my navigational habits, so I have a zero-dependency very short {ba,z}sh function that allows me to jump to preset locations (kd for "quicK Dir" or "worK Dir"):
$ cd ~/go/src/github.com/my/project
$ kd awesome_project $PWD # create bookmark
$ kd aw # BAM
$ # yay, straight to my project!
$ cd app/controllers/whatever/deeply/nested
$ kd # back to the project root!
$ make
Re: CLI: Improved
#193Is anyone else impressed with the quality (and speed!) of some of the tools written in Rust? I'm an avid user of fd and bat, the former being ridiculously fast. Often I find something on github, I'm impressed by the quality of the documentation, features, UI etc, then lo and behold it's written in Rust. Another one potentially for this list is tokei[1] I was trying to count the code in our repos at work and used the…
This could actually be caused by disk caching effects. Have you tried running cloc second time afterwards?
I tried cloc multiple times. tokei much faster. Try it yourself.
Re: CLI: Improved
#194Earlier quoted context omitted.
Of course, but its primary purpose (combining files) differs from its primary usage (showing a file’s content).
The primary usage us just a special case of its primary purpose. You're concatenating the file with nothing.
If it’s a special case then is it really its primary purpose? :)
Re: CLI: Improved
#195Anyone know of a good markdown viewer that is formatted instead of showing the source with colors? I'm using pandoc to convert it to groff and read it like a formatted man page, which is ok but not great as it loses some formatting. pandoc -s -f markdown -t man markdown.md | groff -T utf8 -man | less -R
Actually plain less works quite well when using filters:
#!/bin/bash
# ~/.lessfilter
case $1 in
*.md) view-md $1;;
*.json) jq -C . $1;;
*) pygmentize $1;;
esac
#!/usr/bin/env ruby
require 'tty-markdown'
puts TTY::Markdown.parse(ARGF.read, colors: 256)
Re: CLI: Improved
#196Aliasing "help" is not a great idea, in my opinion. help gives fantastic usage instructions for builtin shell commands.
Re: CLI: Improved
#197GNU 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.
There is a Rust clone[0], that works seamlessly for my -- arguably simple -- use cases.
Re: CLI: Improved
#198Earlier quoted context omitted.
I don't feel the plain text portion has aged well at all in regards to composability. It leads to a lot of headache as the complexity of the task grows because of the in-band signaling and lack of universal format. I think it is high time the standard unix tools were replaced with modern equivalents that had a consistent naming scheme and pipelined typed object data instead of plain text.
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 it's already making trillions for its users. Changing the whole ecosystems would cost millions and millions, for only a very long term and unclear benefit.
In other words, worse is better.
Re: CLI: Improved
#199Why not just using vim instead of bat?
or view (comes with vim)
Re: CLI: Improved
#200Earlier 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.
Can you share your setup?