this post was submitted on 12 Jun 2024
29 points (100.0% liked)

Linux

48328 readers
602 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

Hey,

As an avid CLI user, I always aimed to master non-interactive tools to perform most of my work, given that they are easy to use, create, extend, and connect.

However, I found myself dealing with software projects with many files (mostly under the yoke of corporate oppression; an ordeal which I endure to sustain myself, as most of those reading me do, and therefore I will not go further into this topic) and started to hit the limits of non-interactive tools to find and edit files. Indeed, I could go faster if I followed the temptation of monstrous IDEs, as I did in my innocent past.

I did not despair, as naturally I heard of the usefulness of interactive fuzzy finders such as fzf. After spending an afternoon evaluating the tool, I concluded that it indeed increases the complexity of my workflow. Still, this complexity is managed in a sensible way that follows the UNIX tradition.

I now ask you two general questions:

  • Did you reach similar conclusions to me and decide to use interactive fuzzy finders to solve working on software projects with many files?
  • If you use fzf or similar tools, what can you tell me about your workflow? Any other third-party tools? Do you integrate it into your scripts? Any advice that you can give me out of a long time of experience using the tool that is not easily conveyed by the documentation?

I also ask this very specific question:

  • The one part of fzf which I found missing was a way to interact with the results of grep, and to automatically place the selected file(s) in the prompt or an editor. For that, I created the following two commands. Do you have a similar workflow when you want to bring the speed of fuzzy finding to grep?
#! /usr/bin/env bash

# gf: grep + fzf
# basically a wrapper for 'grep <ARGS> | fzf | cut -f 1 -d:'

# print usage on -h/--help
if [[ "$1" == "-h" || "$1" == "--help" ]]; then
    echo "Usage: gf <grep-args>"
    echo
    echo "~~~ that feel when no 'gf' ~~~"
    echo
    echo "- Basically a wrapper for 'grep <ARGS> | fzf | cut -f 1 -d:'"
    echo "- Opens fzf with grep results, and prints the selected filename(s)"
    echo "- Note: As this is meant to search files, it already adds the -r flag"
    echo
    echo "Example:"
    echo "  $ nvim \`gf foobar\`"
    echo "  $ gf foobar | xargs nvim"
    exit 0
fi

# run grep with arguments, pipe to fzf, and print the filename(s) selected
custom_grep () {
    grep -E --color=always --binary-files=without-match --recursive "$@"
}
remove_color () {
    sed -E 's/\x1b\[[0-9;]*[mK]//g'
}
custom_fzf () {
    fzf --ansi --height ~98%
}
grep_output=$(custom_grep "$@")
if [[ "$?" -ne 0 ]]; then
    exit 1
else
    echo "$grep_output" | custom_fzf | remove_color | cut -f 1 -d:
fi
#! /usr/bin/env bash

# ge: grep + fzf + editor
# basically a wrapper for 'grep <ARGS> | fzf | cut -f 1 -d: | $EDITOR'

# print usage on -h/--help
if [[ "$1" == "-h" || "$1" == "--help" ]]; then
    echo "Usage: ge <grep-args>"
    echo
    echo "- Basically a wrapper for 'grep <ARGS> | fzf | cut -f 1 -d: | \$EDITOR'"
    echo "- Opens fzf with grep results, and edits the selected file(s)"
    echo "- Note: As this is meant to search files, it already adds the -r flag"
    echo "- Note: Internally, it uses the 'gf' command"
    echo
    echo "Example:"
    echo "  $ ge foobar"
    exit 0
fi

# takes output from 'gf' and opens it in $EDITOR
grep_fzf_output=$(gf "$@")
if [[ -n "$grep_fzf_output" ]]; then
  $EDITOR "$grep_fzf_output"
fi

Have a wonderful day, you CLI cowboys.

you are viewing a single comment's thread
view the rest of the comments
[–] Kualk@lemm.ee 4 points 5 months ago* (last edited 5 months ago) (1 children)

Fish is all I need for daily CLI. It is zero customization effort for me. Spend your time on productive side, not fzf your shell history.

https://fishshell.com/docs/current/tutorial.html

Keep bash as default root shell and just start fish manually when using root. It is for cases when linux panics on boot.

[–] sebastiancarlos@lemmy.sdf.org 4 points 5 months ago (1 children)

And what's your workflow when working with lots of files in projects with fish?

[–] Kualk@lemm.ee 2 points 5 months ago* (last edited 5 months ago)

I don’t get the question.

I usually use vscode to work with files. It has excellent remote editing over ssh. For example, I have large private collection of markdown notes that is kept on remote server.

At work I deal with large GO project that targets Docker images and my setup is:

  • windows 11 laptop
  • WSL Debian with full systemd integration installed (that’s the hardest part)
  • visual studio installed on windows, I have no development tools on windows: no docker, no git, no GO compiler
  • debian on WSL has all the dev tooling: git, go lang, ssh server is turned on

My workflow is to start Debian WSL and forget about terminal. Start vscode on windows, connect to Debian over ssh, open project directory. Work on project without ever leaving editor, use built in terminal in vscode. Fish runs inside vscode. Editor is primary. Fish is secondary and it excels at recalling history.

Use each tool for what it was designed. No terminal will ever match my productivity in vscode. Vscode has all the fuzzy search built-in.

I used to use vim for heavy coding, but abandoned that route 20 years ago. I am still able to use vim for quick short changes in config files, but anything serious is handled with visual studio code over ssh.

Primary vim scenario:

sudo vim /etc/config-file-name

Vscode 1st approach is a modern day version of emacs approach Or vim with plugins. Only difference is vscode is actually low effort to get started on new machine, low learning curve, low maintenance effort unless you have sunken months into your terminal editor and refuse to abandon your investment.