Som en fuldtids linux-narkoman, med en tendens til tiling window-managers, så bruger jeg en hel del tid i terminalen/commandlinen. Som andre med sådanne computer interesser, så bliver jeg eksponeret for en del opreklamering, word-of-mouth og andet gøjl for hvad der er det nyeste og sejeste i FOSS-land af software. Jeg faldt fornyelig over en artikel/videoer som belyste terminal-tools som er skrevet i programmeringssproget rust. Af de nævnte eksempler på listen, tænkte jeg at det kunne jeg da godt give et skud, og se om der var noget til det eller ej, så jeg installerede nogen af disse værktøjer på min “test-bench” før jeg ville integrere dem i mit workflow på min main-machine, og HOLLY MOLLY!!!

Nogen af disse værktøjer har virkelig været life/time-savers for mit workflow og forbedret pain-point i min terminal ergonomics. Fremfor at nævne dem alle sammen, vil jeg istedet bare nævne dem der har gjort størst indtryk på mig her, og hvis man vil vide mere kan man læse denne artikel.

Zellij - screen/tmux alternativ

Terminal multiplexer med sane defaults, der gør det muligt hurtigt at lære og bruge som værktøj, både i eksisterende workflows eller i at strukturere helt nye.

Zoxide - et bedre cd

cd (change directories)

Fremfor det standard cd for at ændre lokation i sit fil-system, er zoxides fordel, at den registere de fil-lokationer du navigere til, og rangere dem efter hvor ofte, du navigere til dem. Dette gør det muligt at navigere fil-systemet baseret på “shortcuts”. Eksempelvis ville man med cd være nødt til at skrive følgende for at navigere fra home-directory (~) til undermappen documents/school/1semester.

  cd documents/school/1semester

De fleste vil nok have “tab-autocompletion” som vil spare noget tid. I zoxide, vil jeg efter første gang at jeg har navigeret til mappen, altid kunne tilgå den ved blot følgende uafhængigt af hvor at jeg befinder mig i mit fil-hieraki.

  z 1semester

I det tilfælde at der er flere mapper, som hedder “1semester” i fil-hierakiet, og som er befinder sig forskellige steder, kommer zoxide også med en iteraktiv fil-picker. Her ville man så kunne gøre nedenstående:

  zi 1semester

Og kunne vælge hvilken instans af de forskellige mapper, som zoxide har registeret til at indeholde den string-combination i sit navn, som man ønsker at navigere til.

For at sætte Zoxide op med bash på nixOS, tilføjede jeg bare en linje til min promptInit for bash.

programs.bash = {
  promptInit =
    ''
      (...)
      # adding zoxide to bash on nixos
      eval "$(zoxide init bash)"
    '';

I mit nye nushell-setup, er det sat op med en zoxide.nu fil, som jeg tilføjer med source til min .config/nushell/config.nu. Indholdet af zellij.nu er generet med zoxide init nushell, som kører som en del af nushell’s environment setup, som er sat op med env.nu.

# env.nu
(...)

zoxide init nushell | save -f ~/.config/nushell/zoxide.nu


# config.nu

(...)

source ~/.config/nushell/zoxide.nu

Dust - et bedre du

du (disk usage)

Tiden sparet med at bruge dust over du, bliver især tydelig på servere som opbevare store mængder data, udover den øgede hastighed af dust over du, så er visualiseringen af diskbruget i selve terminalen både som procent og som en grafisk repræsentation en nice added benefit.

Helix - et vim alternativ

Jeg nåede aldrig at blive hooked på vim. Jeg så brugbarheden af modal-editing og keyboard-centrisk navigation, problemet var dog blot at jeg kun brugte vanilla-vim og aldrig gav mig i kast med hverken plugins eller med neovim, før jeg faldt over helix. Og vanilla-vim er et hard sell, i det nuværende miljø i hensyn til “comfort og quality of life”-features.

Helix beskriver sig selv ironisk som en “post-modern editor”, som kommer med batterierne inkluderet. Man slipper altså for at skulle til konfigurere programmet med plugins, og kan istedet som begynder fokusere på at lære “keybinds” og at bruge programmet (med dets sane/reasonable moderne defaults) fremfor at skulle forholde sig til vim/neovim forskellen og brugen af plugin. Nogen vil måske invende at man som begynder kan bruge en neovim distribution, til at få et starts grundlag, problemet er dog at det ikke fjerner problemet med “choice paralysis”.¹ Som dem bag helix-projektet også udtrykker det:

By starting from scratch we were able to learn from our experience with Vim and make some breaking changes. The result is a much smaller codebase and a modern set of defaults. It’s easier to get started if you’ve never used a modal editor before, and there’s much less fiddling with config files. ²

Den påstand ses også praktisk i eksempelvis min egen samlede helix config, og kortheden er værd at holde i mente i sammenligning med noget som eksempelvis en neovim-config:

theme = "gruvbox"

[editor]
shell = ["nu", "-c"]
[editor.soft-wrap]
enable = true
max-wrap = 25

[editor.statusline]
mode.normal = "nor"
mode.insert = "ins"
mode.select = "sel"


[editor.cursor-shape]
normal = "block"
insert = "block"


# min tilføjede "+"-mode, med mine mest brugte commands
# (primært til externe shell-commands i nu) 
[keys.normal."+"]
a = ":sh pdflatex main.tex"
b = ":sh pdftotext main.pdf - | wc -m"
f = ":pipe ^fmt"
g = ":sh git status"
w = "vsplit"

Man kan undre sig, “hvad får en ikke-programmør ud af at bruge tekst-redigerings programmer som kører i terminalen, og som er keyboard-centriske?”. Mit svar til et sådan spørgsmål er nogenlunde, det samme som en programmør og andre der finder sig selv i en lignende situation:

• Hastigheden af at kunne “iterate” og mængden af tekst-ændringer mulige per tid. Sagt anderledes hvor hurtigt at jeg er istand til at producere og redigere tekst som værende muliggjort på en facon, som programmer som word og lignende simpelthen ikke kan konkurere med.
• De ergononomiske og konfigurative muligheder for at optimisere workflows.
• “Friheden”/muligheden til at kunne skifte skrive-program, og stadig have adgang til at redigere sine filer som resultat af at filerne er standard åbne “raw text-files”.

Når disse muligheder kombineres med noget som LaTex eller markdown, bliver det hurtigt muligt at producere dokumenter og andre skriverier, i en bred skare af genre. Det der gør helix til et godt værktøj for programmøre, er blandt andet hvor godt det er til at redigere tekst, det er det samme som gør det til et godt værktøj for mig, selvom jeg brugere det til at redigere prosa, paragraffer og citationer istedet for “if-statements”.

Nushell - et alternativ til bash, fish, zsh

Jeg har altid bare holdt mig til bash som min shell, kun en enkelt gang har jeg tidligere prøvet kræfter med en anden shell, iform af fish. Fish fangede mig dog ikke, og jeg kunne ikke se den gang hvad dets fordele over bash bestod i, taget i betragtning at jeg ikke brugte tid på at customize min shell, men bare brugte hvad der var default prompt for min distro, kun meget senere begyndte jeg at customize min bash prompt.

Fornyeligt har jeg dog givet mig i kast med nushell, en shell som er særdeles anderledes end de andre shells, der er på “markedet”, Nushell er ikke bare skrevet i Rust, men er også kendetegnet ved følgende:

• Non-posix
• Data-driven pipelines (everything is data, og derfor structured data)
• Cross-platform

Men hvad i praktisk use-cases, gør nushell mere ergonomisk³ end bash. Eksempelvis deres pipelines værende data-driven, fremfor strings og istedet functional, giver en nicer oplevelse når man skriver pipelines

Et eksempel mellem bash og nushell’s nu-scripting language.

for FILE in $(find ./ -type f); do
  pandoc -f markdown -t latex -o (FILE+".tex")
done

vil i nu, kune gøres som en pipeline, som følgende:

for $x in (ls) { pandoc -f markdown -t latex -o ($x.name + ".tex") $x.name }

Fordelen er at man med Nushell, arbejder med structured data, og derfor er i stand til at refere til et field af en given instans. Eksempelvis outputet af ls i nu:

Det betyder at man ikke behøves at bruge et værktøj som bash’s find, og kan lave conditional statements baseret på den structured data som man for udleveret eller anvende diverse functioner på dem, som sort og etc.

En anden benefit er inklussionen af et ‘vi’-mode i nushell. Dette er også muligt at bash, men jeg prøvede bare aldrig kræfter med det, men læsbarheden og letheden i at skrive nushell config files, har fået mig til at eksperimentere med en ny del af mit terminal-setup, nemlig selve min prompt. Eksempler er også indbyggede commands som sys og dets subcommands, sys users som bare et under-eksempel.

Et andet eksempel er hvorledes at de ovenstående tabeller er blev lavet, med følgende ls | to md og sys users | to md, et blandt mange af fordelene ved at arbejde med structured data fremfor strings er konsistens og evnen til at sammensætte pipelines, som gavner heraf.