Live data from Hacker News

So you've installed `fzf` – now what?

andrew-quinn.me

261–270 of 292 posts

Re: So you've installed `fzf` – now what?

#262
post #259

Earlier quoted context omitted.

FYI, speaking as a skim library user/lover, two things -- 1) it's really not maintained, and 2) once you dig into the code it gets a little gnarly. I have a branch[0] where I'm trying to do things like reduce the user perceptible lag in search, the initial time of ingest, and add small features I need, etc (all done). I've tried to create PRs where I can, and they go unnoticed and unused. One other thing I was trying…

> it's really not maintained What do you mean by maintained? There are commits as recent as yesterday on the project: https://github.com/junegunn/fzf

They are clearly not talking about fzf

Re: So you've installed `fzf` – now what?

#263
post #213

The article is a pretty helpful collection of examples, and I appreciate it. The intro irks me, though: > Software engineers are, if not unique, then darn near unique in the ease with which we can create tools to improve our own professional lives; this however can come at a steep cost over time for people who constantly flit back and forth between different tools without investing the time to learn their own kit in…

A woodworker needs a supply of dry wood and can't just TDD, or undo/redo their way to a table. Ditto for other fields.

Most traditional construction was done with green wood, in fact, and there is a whole bunch of furniture making and other fine work that can be done with green wood. Much carving and turning is preferable on green wood, as it works more easily than dry.

And in fact, testing is one of the most widely shared pieces of advice among woodworkers I have seen working and met. If there is more than one of any cut to be made, it is customary to build a custom jig to hold the work, then test on scrap to ensure all is correct. After work pieces are all in or near their final shape, it is typical to do a dry fit: put the entire (or some substantial subassembly of the) finished product together without glue or fasteners to ensure it does fit. Iteration and small tests which allow for fast failure and early correction are a longstanding tradition in woodworking, much longer than in programming.

In my personal experience, working professionally as a programmer and as a hobbyist in woodwork, I have been much more impressed by the degree to which woodworkers build their own tools to support their workflows than by programmers. This holds up among individuals I know personally, discussions I have followed online, and popular personalities I have been exposed to.

If you follow discussions and developments in both communities, it becomes clear that the difference is not the ease with which one can build tools to make their work better, but the price at which programmers can get professional-grade tools for the same purpose.

BSD and Linux are free. Hyper-powered text editors are free. Most programming languages are free. Postgres (and a plethora of other, databases) is free. Compilers, debuggers, package management, CI/cd tools, collaboration tools are all available for free.

As for the availability of raw materials for building such tools to improve work, that is a question of cost, not ease. It is certainly easy to build tools for a woodworker, and the cost is not prohibitive, based on the observation that every woodshop I have seen has a significant amount of tools and fixtures built by the worker.

Re: So you've installed `fzf` – now what?

#264

Here's a little function that I use pretty often when I want to install a package but I'm not sure what the exact package name is. Give it a keyword and it searches apt-cache and dumps the results into fzf. function finstall { PACKAGE_NAME=$(apt-cache search $1 | fzf | cut --delimiter=" " --fields=1) if [ "$PACKAGE_NAME" ]; then echo "Installing $PACKAGE_NAME" sudo apt install $PACKAGE_NAME fi }

I have a similar one for Homebrew, with the ability to preview package info and install multiple targets:

    # ~/.config/fish/functions/fbi.fish
    function fbi -a query -d 'Install Brew package via FZF'
        set -f PREVIEW 'HOMEBREW_COLOR=1 brew info {}'
        set -f PKGS (brew formulae) (brew casks |sed 's|^|homebrew/cask/|')
    
        set -f INSTALL_PKGS (echo $PKGS \
            |sed 's/ /\n/g' \
            |fzf --multi --preview=$PREVIEW --query=$query --nth=-1 --with-nth=-2.. --delimiter=/)
    
        if test ! -z "$INSTALL_PKGS"
            brew install $INSTALL_PKGS
        else
            echo "Nothing to install…"
        end
    end

Re: So you've installed `fzf` – now what?

#265

The article is a pretty helpful collection of examples, and I appreciate it. The intro irks me, though: > Software engineers are, if not unique, then darn near unique in the ease with which we can create tools to improve our own professional lives; this however can come at a steep cost over time for people who constantly flit back and forth between different tools without investing the time to learn their own kit in…

unique in the ease with which we can create tools to improve our own professional lives I think the key line is the ease in which we can create tools. A software engineer has free access to the lumber yard. Builders of old had to work hard to create tools to create tools.

Cost and ease are different concerns.

On ease, much of what a woodworker needs can be built from wood and with basic hand tools, so the woodworker, by definition can build many of their own tools.

This is similar to programming, where much of what a programmer needs can be written in code.

On cost, simple observation of woodshops—including many in person and among acquaintances that are not professionals—has shown me that the cost is not prohibitive. Every shop I have seen includes a significant amount of self-built tools and fixtures.

Cost also explains the difference in programming environments I have seen. I have met a great many professional programmers, some of whom have no scripts directory or self-written tools, whose only programming output is their direct work product. This reflects the fact that professional-grade tools are available for free to programmers.

As individuals, my observations lead me to understand woodworkers as much more likely to use their skills to build tools for themselves. The same holds true of other craftspeople I have had the opportunity to observe; even in small, one-off projects, it is common to use elements of the craft to build a tool or otherwise aid the endeavor in a way that is not directly producing the work product.

As a collection, I would agree that programmers build tools that allow us to do our work better. The open source community is incredible. Because of the collective action and the cost to individuals, it is much less common for those individual programmers to have to write tools for themselves.

I would argue that it is similarly easy, but circumstances lead to these disparate outcomes.

Re: So you've installed `fzf` – now what?

#266

Am I the only one that tried fzf as a replacement to the default Ctrl+R behavior, then switched back? I'm perfectly satisfied with the default Ctrl+R functionality, to the point that fzf seemed to add visual clutter without any value. I guess I was never let down by inverse search. Context: I'm using Linux and doing SWE and SRE work, and constantly live in the terminal.

The default ctrl+r behavior doesn't allow me to scroll up through my history of matches, which is always disappointing. Often it's some random incantation I'm trying to search for that shares a prefix with other more common commands and the default ctrl+r requires me to type out far enough to be unique, which defeats the purpose of history search. Maybe I'm missing some essential behavior that I'm not familiar with.

> that shares a prefix

ctrl+r matches any part of the line, not just the commands / start of the line. I'm often using it on a unique argument I remember last using the command with.

Re: So you've installed `fzf` – now what?

#267
post #179

> And I found myself asking: Where the heck is nginx.conf? The author lists some ways but misses the standard Unix way: simply use locate https://en.m.wikipedia.org/wiki/Locate_(Unix) Using locate maybe piped to grep is good enough for all my finding needs

Don't you need admin to run `updatedb`? On a work machine, this is my main barrier to using plocate.

Cron/systemd timer to run updatedb every N hours.

Re: So you've installed `fzf` – now what?

#268
post #55

Thanks for this. I didn't know about the built-in-cd. For anyone on macOS trying to get Alt-C to work see https://github.com/junegunn/fzf/issues/164 .

TL;DR - Esc+C works (yes you read that right, Esc+C)

I had to add the fzf plugin in my .zshrc to get this to work

Re: So you've installed `fzf` – now what?

#269
post #222

Earlier quoted context omitted.

It is very useful just be careful when switching between shells and hitting the up arrow to get the previous command, as you may get something from another shell.

That will only happen if PROMPT_COMMAND also contains "history -c; history -r", right? "history -a" just saves it, but "history -c; history -r" clears memory history and reloads from disk.

Yes, that's correct. I overlooked that detail while reading the link on a phone, where the text is quite small.

Re: So you've installed `fzf` – now what?

#270

Earlier quoted context omitted.

My solution is I immediately record the commands, but do not load them. That way new terminals get all the history, but old terminals keep their flow.

But if you go back later, the chains of commands from different terminals are interlaced right?

To some degree; it depends on the amount of multitasking. I mainly care about which commands in which order when I'm looking at recent commands from that terminal; otherwise I use C-r.
Post reply on HN