One of the most productive tools that I have is being able to search command history for commands typed in the current directory. It becomes a knowledge database. I rolled up my one, but I haven't seen any tool doing it, which surprises me. Perhaps the McFly tool mentioned here.
Command line tools for productive programmers
121–130 of 143 posts
Re: Command line tools for productive programmers
#122Author here. Thanks for sharing! Have you seen gron[1]? It can't do everything that jq can, but it is much more in the unix philosophy than jq. It simply flattens and unflattens json out into lines so you can use standard unix tools on it. ▶ gron "https://api.github.com/repos/tomnomnom/gron/commits?per_page=1" | fgrep "commit.author" json[0].commit.author = {}; json[0].commit.author.date = "2016-07-02T10:51:21Z"; jso…
I personally have settled for fx[1], there's no need to learn yet another tool's syntax, specificities, and quirks. js anonymous functions are valid inputs to the tool. when the transformation turns to be more complex than expected I can just copy and paste what I've made so far into a nodejs script. you can also configure a .fxrc file to automatically import npm packages that you might find useful, shortcuts, or you…
[deleted]
Re: Command line tools for productive programmers
#123I'm a VIM-only dev, spend all my day in a Tmux session, and I use the command-line probably a lot more than average. The single best improvement to my command-line workflow I've done in the last few years has been switching shells. First I moved from Bash to ZSH, but about 2 years ago I switched again to Fish. Why I love it: - history completion searches by default, so I can just type part of a command, hit arrow-up…
On a similar note, zsh-history-substring-search has become something I look for everywhere.
Re: Command line tools for productive programmers
#124Earlier quoted context omitted.
I'd also add ncdu - which is really great when you need to easily see what's eating up disk space. jq is also super nice when you have to parse json data. I also like powerlevel10k: https://github.com/romkatv/powerlevel10k
If you like/use jq and work with html, yq is it’s counterpart. Dyff is in a similar realm.
Do you have any experience with pup to compare with yq? That's the jq look-alike for HTML I first stumbled upon.
Re: Command line tools for productive programmers
#125Author here. Thanks for sharing! Have you seen gron[1]? It can't do everything that jq can, but it is much more in the unix philosophy than jq. It simply flattens and unflattens json out into lines so you can use standard unix tools on it. ▶ gron "https://api.github.com/repos/tomnomnom/gron/commits?per_page=1" | fgrep "commit.author" json[0].commit.author = {}; json[0].commit.author.date = "2016-07-02T10:51:21Z"; jso…
It seems so obvious now that someone's done it. Doing things in a Unix-y way often requires imagination; this is a great example of that.
Re: Command line tools for productive programmers
#126Off topic hijack - I'm trying to find a tool I feel was probably mentioned here at one point - a REPL for shell.
If I recall correctly, you would open up the repl and start typing a command, and the output would refresh as you typed. Does this ring a bell for anyone?
Re: Command line tools for productive programmers
#127Earlier quoted context omitted.
I'd also add ncdu - which is really great when you need to easily see what's eating up disk space. jq is also super nice when you have to parse json data. I also like powerlevel10k: https://github.com/romkatv/powerlevel10k
If you like/use jq and work with html, yq is it’s counterpart. Dyff is in a similar realm.
Or my Xidel to work with html and json with XPath
Re: Command line tools for productive programmers
#128Off topic hijack - I'm trying to find a tool I feel was probably mentioned here at one point - a REPL for shell. If I recall correctly, you would open up the repl and start typing a command, and the output would refresh as you typed. Does this ring a bell for anyone?
Re: Command line tools for productive programmers
#129Earlier quoted context omitted.
That first pkill/killall example is a bit silly, but for the others I can see how a "ruby-each-line" can be useful, especially if you're already familiar with Ruby (although I'd probably name it "el", as that's much less typing). I never really learned awk properly myself either, in spite of being quite familiar with most other shell tools. "ruby-each-line" does more or less the same thing as awk. After all, there's…
Yeah, like I said: I can see how it could be useful for someone who knows only Ruby. > I never really learned awk properly myself either It's really worth it. It's simple — pattern matches and block, BEGIN/END, hashes, match() and gsub() cover 90% of my uses. I very often find myself writing something like this: awk -v id=$id ' $1 == id { go = 1 } { if (go && $4 == "b667226") { km += $5 secs += $6 n++ } } END { print…
awk just always seemed a little too domain-specific to really invest time in. The number of times I think "gee, I really wish I knew better awk" are few.
This week I've been doing some Lua programming; I had done some Lua several years ago for something else, but found that I had forgotten most things. Even for Ruby I've forgotten quite a lot, yet for two years I programmed Ruby every day for a living. It's just that I haven't done much Ruby since, and when I did some Ruby several months ago I had to look up quite a lot of basic syntax things because I had roughly remembered how it worked but not enough to actually get stuff done in it.
In general, I find that effective practical programming skills are a bit of a "use it or lose it" thing. I don't think I'll use awk enough to not "lose it", even though it's a fairly small language, and most problems it solves can also be solved in other ways.
Re: Command line tools for productive programmers
#130Earlier quoted context omitted.
You can do it with inotify too tho , no ? Great project tho !
'entr' will use inotify where available - the utility is that it's 1) cross-platform and 2) easy to integrate with shell scripting (rather than having to write a more complete inotify or other platform-specific tools). As an example, I use 'guard' [0] in a docker container, and on test failure it writes out to a file which is shared outside the container. It's easy for me to fire up a shell script that uses 'entr' to…
Ah niceeeeee