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
#!/bin/bashor#!/bin/sh? 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
podupandpoddownthat replacepodman compose up -dandpodman compose downorpodlogaspodman logs -f --tail 20 $1orpodenterforpodman 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 bashshebang.bashis just fine for me, though I've customized it using Starship and created some aliases to have colored/pretty output where possible.shellcheckbefore 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 -xinside your Bash script orbash -x scriptnameon 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 availableno Deb pkg avail
Rest of the list:
Tools pt. 2
DNS tools:
Good stuff for pentesters and security researchers:
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.