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.
Good advice. I'll add that any time you have to parse command line arguments with any real complexity you should probably be using Python or something. I've seen bash scripts where 200+ lines are dedicated to just reading parameters. It's too much effort and too error prone.
It depends. Parsing commands can be done in a very lightweight way if you follow the bash philosophy of positional/readline programming rather than object oriented programming. Basically, think of each line of input (including the command line) as a list data structure of space-separated values, since that's the underlying philosophy of all POSIX shells.
Bash is basically a text-oriented language rather than an object-oriented language. All data structures are actually strings. This is aligned with the UNIX philosophy of using textual byte streams as the standard interface between programs. You can do a surprising amount in pure bash once you appreciate and internalize this.
My preferred approach for CLI flag parsing is to use a
case-esacswitch block inside awhileloop where each flag is a case, and then within the block for each case, you use theshiftbuiltin to consume the args like a queue. Again, it works well enough if you want a little bit of CLI in your script, but if it grows too large you should probably migrate to a general purpose language.Here's a simple example of what I mean:
Showing how to do long flags with B and flags with parameters with C and D. The parameters will correctly work with quoted strings with spaces, so for example you could call this script with
--dee="foo bar"and it will work as expected.Hoho, now do that in POSIX shell.
I had a rude awakening the day I tried it, but my scripts are bulletproof now (I think) so I don't mind at this point
Imma be real, I never remember which parts of bash aren't POSIX. Luckily it doesn't matter in my line of work, but it's good to be aware of if you have a job that often has you in machines running other types of UNIX.
Arguments don't work the same way and POSIX doesn't have the concept of arrays outside of @