What do you advice for shell usage?
- Do you use bash? If not, which one do you use? zsh, fish? Why do you do it?
- Do you write
or
? Do you write fish exclusive scripts?
- Do you have two folders, one for proven commands and one for experimental?
- Do you publish/ share those commands?
- Do you sync the folder between your server and your workstation?
- What should’ve people told you what to do/ use?
- good practice?
- general advice?
- is it bad practice to create a handful of commands like
podup
andpoddown
that replacepodman compose up -d
andpodman compose down
orpodlog
aspodman logs -f --tail 20 $1
orpodenter
forpodman exec -it "$1" /bin/sh
?
Background
I started bookmarking every somewhat useful website. Whenever I search for something for a second time, it’ll popup as the first search result. I often search for the same linux commands as well. When I moved to atomic Fedora, I had to search for rpm-ostree
(POV: it was a horrible command for me, as a new user, to remember) or sudo ostree admin pin 0
. Usually, I bookmark the website and can get back to it. One day, I started putting everything into a .bashrc
file. Sooner rather than later I discovered that I could simply add ~/bin
to my $PATH
variable and put many useful scripts or commands into it.
For the most part I simply used bash. I knew that you could somehow extend it but I never did. Recently, I switched to fish because it has tab completion. It is awesome and I should’ve had completion years ago. This is a game changer for me.
I hated that bash would write the whole path and I was annoyed by it. I added PS1="$ "
to my ~/.bashrc
file. When I need to know the path, I simply type pwd
. Recently, I found starship which has themes and adds another line just for the path. It colorizes the output and highlights whenever I’m in a toolbox/distrobox. It is awesome.
bash
, because I never had the time to learn anything else.#!/usr/bin/env bash
shebang.bash
is just fine for me, though I’ve customized it using Starship and created some aliases to have colored/pretty output where possible.shellcheck
before running your scripts in production, err on the side of caution,set -o pipefail
. There are best practices guides for Bash, use those and you’ll probably be fine.set -x
inside your Bash script orbash -x scriptname
on the CLI for debugging. Remember that you can always fallback to interactive CLI to test/prepare commands before you put them into your script. Think before you type. Test. Optimize only what needs optimization. Use long options for readability. And remember: Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows your address.Oh, I also “curate” a list of Linux tools that I like, that are more modern alternatives to “traditional” Linux tools or that provide information I would otherwise not easily get. I’ll post i
Tools
Debian-Packages available
no Deb pkg avail
___
My brian has too little ram to process the list of packages 😂 good to know the rest!
Neither does mine, but, I keep it to test a new tool from time to time.