101–110 of 252 posts
A simple trick I only figured recently is following logs with fuzzy search: tail -f /var/log/foo.log | fzf +s Or something similar for output from a dev server: make serve | fzf --ansi +s
- automatically have this for any command that outputs more than 10 lines?
- automatically exit when the main command (for example a dev server) exits?
- print the output of the main command to stdout after this is done?
I write quick and dirty single-purpose utilities for myself because I want relatively simple programs. I try to keep program size reasonably small so I use C not Go or Rust. I avoid creating options. FWIW, seems like that was true of most of djb's utilties, too. Some of the best "new" UNIX utilities I have seen have come from from people who use djb's C functions and/or copy his programming style, including the preference for small program size and few-to-no options. For example, the authors of runit or s6 have some interesting utilities. The author of tinysshd has some useful ones as well. These projects are generally not popular but they are generally high quality, IMHO.
There are some JSON utilities listed on this blog page. Despite so many options for libraries and programs to process JSON, I still cannot find one that does something very simple: 1. extract JSON from HTML, 2. print it in a customised, human-readable, left-justified format that 3. makes it easy to process further with other programs. Hence I wrote a stupid program for myself that extracts JSON, prints the keys and values left-justified, making it easy for me to read with less(1) and to process with traditional UNIX text-processing utilities. (I am probably mistaken but I believe the one I wrote may be able to operate at the same speed regardless of the size of the JSON data. This needs to be tested.)
I have written several shell scripts over the years that have a subset of the functionality of fzf (or a superset of urlview's, which came much earlier), namely finding and selecting items from lists. I am still not a fzf convert because generally it does not do anything essential I cannot already do myself. Plus it is larger, more complex and generally slower.
Someone once said the best interface is no interface. For me, the less required user-interaction (including selecting options), the more powerful the utility.
Ah, delta is missing! Right from the docs, it's "[a] syntax-highlighting pager for git, diff, and grep output". [1] https://github.com/dandavison/delta (edit: nevermind, somehow I missed it)
Straight from the repo: "Like jq, but for HTML."
I find it useful for quickly hacking scripts together and exploring data. Very useful for the iterative process of finding good CSS selectors with the data that I can get without javascript running.
--- [1] https://github.com/mgdm/htmlq
Any terminal based solutions for Postman/Insomnia/Nightingale? I am just using curl and text files for api testing.
You still have to create the collections in Postman, however.
None of the "replacements" interest me. When I try the "new" ones I cannot get interested in them either. When trying new programs I am looking for whether a program can do something essential that I cannot do myself, e.g., with shell scripts. However I am beginning to think another reason is that these "new" utilities are consitently too complicated, e.g., too many options. It often seems as if the authors are tryin…
I’m a fan of nnn for a terminal file manager, so I’m keen to try out broot. Does anyone have other recommendations I should try? https://github.com/jarun/nnn
How does nnn compare to ranger https://github.com/ranger/ranger ?
direnv is such a godsend that I shill for it on every team and in every company now, it's such a great tool.
I read through the direnv docs, but I'm trying to think of how I'd use it. Can you or anyone else give me some examples? Even just listing which directories you have .env or .envrc files in, and what environment variables you use in them.
Also, many scripts start by just defining a bunch of variables -- and many of those, in terms of other variables. Say, a PROJECT_ROOT directory, and a PROJECT_DOCS directory defined relative to that, etc. Then, a bunch of command parsing logic, after defining all those default values, so the user can set values of their own. Then, finally, the script can start doing the thing it was put there for in the first place.
With the .envrc approach, some of that stuff is pulled out of the script (making it shorter and simpler) and considered part of the directory environment.
[1] https://12factor.net/configAs a maintainer, I hoped to see Hurl [1], a tool for testing HTTP with plain text and curl, but alas it isn’t here! [1] https://hurl.dev
sed (ed) - 1979 (1971)