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.
#!/usr/bin/env bash
A folder
dotfiles
as git repository and adotfiles/install
that soft links all configurations into their places.Two files,
~/.zshrc
(without secrets, could be shared) and another for secrets (sourced by.zshrc
if exist secrets).This is the way!
why?
because bash isn’t always in
/usr/bin/bash
.On macOS the version on
/usr/bin/bash
is very old (bash 3 I think?), so many users install a newer version with homebrew which ends up in PATH, which/usr/bin/env
looks at.Protip: I start every bash script with the following two lines:
#!/usr/bin/env bash set -euo pipefail
set -e makes the script exit if any command (that’s not part of things like if-statements) exits with a non-zero exit code
set -u makes the script exit when it tries to use undefined variables
set -o pipefail will make the exit code of the pipeline have the rightmost non-zero exit status of the pipeline, instead of always the rightmost command.
Nice, thx!
/bin/sh
is always/bin/sh
.
!/usr/bin/env
will look inPATH
forbash
, andbash
is not always in/bin
, particularly on non-Linux systems. For example, on OpenBSD it’s in /usr/local/bin, as it’s an optional package.If you are sure
bash
is in/bin
and this won’t change, there’s no harm in putting it directly in your shebang.
dotfiles
Thanks! I’ll check them out. I knew the cooncept existed but so far I didn’t dig deep into managing them. This is my start I guess https://wiki.archlinux.org/title/Dotfiles
Instead of a install skript, check out GNU stow. It does exactly that and you can interqctively choose which things to install/symlink.
Use
shellcheck
Do you use bash?
Personally I use Bash for scripting. It strikes the balance of being available on almost any system, while also being a bit more featureful than POSIX. For interactive use I bounce between bash and zsh depending on which machine I’m on.
Do you write
or
?
I start my shell scripts with
. This is the best way of ensuring that the same bash interpreter is called that the user expects (even if more than one is present or if it is in an unusual location)
Do you have two folders, one for proven commands and one for experimental?
By commands, do you mean bash scripts? If so, I put the ones I have made relatively bulletproof in
~/bin/
, as bash usually makes them automatically on the path with this particular folder name. If I’m working on a script and I don’t think it’s ready for that, or if it goes with a specific project/workflow, I will move it there.Do you sync the folder between your server and your workstation?
No. I work on lots of servers, so for me it’s far more important to know the vanilla commands and tools rather than expect my home-made stuff to follow me everywhere.
good practice? general advice?
Pick a bash style guide and follow it. If a line is longer than 80 characters, find a better way of writing that logic. If your script file is longer than 200 lines, switch to a proper programming language like Python. Unless a variable is meant to interact with something outside of your script, don’t name it an all caps name.
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
?This is a job for bash aliases.
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-esac
switch block inside awhile
loop where each flag is a case, and then within the block for each case, you use theshift
builtin 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:
#! /usr/bin/env bash while [[ -n $1 ]]; do case $1 in -a) echo "flag A is set" ;; -b|--bee) echo "flag B is set" ;; -c) shift; echo "flag C is $1" ;; --dee=*) echo "flag D is ${1#--dee=}" ;; esac shift done
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 @
That’s the way I do it:
#!/usr/bin/env nix #! nix shell nixpkgs#nushell <optionally more dependencies> --command nu <script content>
But those scripts are only used by me
This is the way
Use
set -x
For debugging
Good to know!
I use Bash for scripts, though my interactive shell is Fish.
Usually I use
as shebang. This has the advantage of searching your PATH for Bash instead of hardcoding it.
My folders are only differentiated by those in my PATH and those not.
Most of my scripts can be found here. They are purely desktop use, no syncing to any servers. Most would be useless there.
For good practice, I’d recommend using
set -euo pipefail
to make Bash slightly less insane and use shellcheck to check for issues.
This is personal preference, but you could avoid Bashisms like [[ and stick to POSIX sh. (Usethen.)
With shortened commands the risk is that you might forget how the full command works. How reliant you want to be on those commands being present is up to you. I wouldn’t implement them as scripts though, just simple aliases instead.
Scripts only make sense if you want to do something slightly more complex over multiple lines for readability.#/usr/bin/env bash typo?
thx for the tips!
I prefer single files over aliases since I can more easily manage each command.
You’re right, it’s
#!
Several things
- write bash and nothing else (except posix sh)
- find a good way to take notes. It shouldn’t be in your bashrc
- only write fish for fish config
- use $!/usr/bin/env bash
Good idea I added a “iwish” command a while ago. Whenever I am pissed about gnome not being able to do something, or anything else that didn’t work as it should, I wrote “iwish gnome had only one extension app” and it would add a new line to my wishlist.md Maybe it would be good for notes too.
inote bla
I love thay idea im gonna implement it tonight
- I usually use bash/python/perl if I can be sure that it will be available on all systems I intend to run the scripts. A notable exception for this would be alpine based containers, there it’s nearly exclusively
.
- Depending on the complexity I will either have a git repository for all random scripts I need and not test them, or a single repo per script with Integrationtests.
- Depends, if they are specific to my setup, no, otherwise the git repository is public on my git server.
- Usually no, because the servers are not always under my direct control, so the scripts that are on servers are specific to that server/the server fleet.
- Regarding your last question in the list: You do you, I personally don’t, partly because of my previous point. A lot of servers are “cattle” provisioned and destroyed on a whim. I would have to sync those modifications to all machines to effectively use them, which is not always possible. So I also don’t do this on any personal devices, because I don’t want to build muscle memory that doesn’t apply everywhere.
- I usually use bash/python/perl if I can be sure that it will be available on all systems I intend to run the scripts. A notable exception for this would be alpine based containers, there it’s nearly exclusively
Am I missing something - doesn’t bash have tab completion or of the box?
hardly
It does. It’s not quite as fancy as the completion in fish/zsh which employ a TUI, but it’s reliable in most situations
You are way over thinking it.
Do you use bash? If not, which one do you use? zsh, fish? Why do you do it?
Mostly fish, because it just feels much more modern than bash, it has good built-in autocomplete and I don’t have to install millions of plugins like of zsh.
Do you write #!/bin/bash or #!/bin/sh? Do you write fish exclusive scripts?
Occasionally I also write fish scripts. Just replace sh with fish.
What should’ve people told you what to do/ use?
general advice?
As @[email protected] already suggested, use shellcheck.
is it bad practice to create a handful of commands like podup and poddown that replace podman compose up -d and podman compose down or podlog as podman logs -f --tail 20 $1 or podenter for podman exec -it “$1” /bin/sh?
I don’t think so
I use
sh
to attempt to keep it compatible with POSIX systems.I use pain bash. Never really tried zsh and fish, since most of my Linux work is on servers and I don’t really care for extra features.
I try and write idempotent scripts when possible.
I wouldn’t create those aliases on a fleet because writing them to the configuration file of your shell in an idempotent fashion is hacky and my VMs are like cattle.
I use bash as my interactive shell. When ~20 years ago or so I encountered “smart” tab completion for the first time, I immediately disabled that and went back to dumb completion, because it caused multi-second freezes when it needed to load stuff from disk. I also saw it refuse to complete filenames because they had the wrong suffix. Maybe I should try to enable that again, see if it works any better now. It probably does go faster now with the SSDs.
I tried OpenBSD at some point, and it came with some version of ksh. Seems about equivalent to bash, but I had to modify some of my .bashrc so it would work on ksh. I would just stick to the default shell, whatever it is, it’s fine.
I try to stick to POSIX shell for scripts. I find that I don’t need bashisms very often, and I’ve used systems without bash on them. Most bash-only syntax has an equivalent that will work on POSIX sh. I do use bash if I really need some bash feature (I recently wanted to
set -o pipefail
, which dash cannot do apparently, and the workaround is really annoying).Do not use
if you’re writing bash-only scripts. This will break on Debian, Ubuntu, BSD, busybox etc. because /bin/sh is not bash on those systems.
Do not use #!/bin/sh if you’re not writing bash-only scripts
Actually
is for bourne shell compatible scripts. Bash is a superset of the bourne shell, so anything that works in bourne should work in bash as well as in other bourne compatible shells, but not vice versa. Bash specific syntax is often referred to as a “bashism”, because it’s not compatible with other shells. So you should not use bashisms in scripts that start with
.
The trouble is that it is very common for distros to links
/bin/sh
to/bin/bash
, and it used to be that bash being called as/bin/sh
would change its behavior so that bashisms would not work, but this doesn’t appear to be the case anymore. The result is that people often write what they think are bourne shell scripts but they unintentionally sneak in bashisms… and then when those supposed “bourne shell” scripts get run on a non-bash bourne compatible shell, they fail.Oh I wanted to say, “Do not use
if you’re
notwriting bash-only scripts”. I think I reformulated that sentence and forgot to remove the not. Sorry about the confusion. You’re exactly right of course. I have run into scripts that don’t work on Debian, because the author used bashisms but still specified /bin/sh as the interpreter.Oh I wanted to say, “Do not use #!/bin/sh if you’re not writing bash-only scripts”
Hah, I was wondering if that was wat you actually meant. The double negation made my head spin a bit.
I have run into scripts that don’t work on Debian, because the author used bashisms but still specified /bin/sh as the interpreter.
The weird thing is that
man bash
still says:When invoked as sh, bash enters posix mode after the startup files are read. ... --posix Change the behavior of bash where the default operation differs from the POSIX standard to match the standard (posix mode). See SEE ALSO below for a reference to a document that details how posix mode affects bash's behavior.
But if you create a file with a few well known bashisms, and a
shebang, it runs the bashisms just fine.
- Fish. Much, much saner defaults.
- I am writing
for dead simple scripts, so they will be a tiny bit more portable and run a tiny bit faster. The lack of arrays causes too much pain in longer scripts. I would love to use Fish, but it lacks a strict mode.
- No, why would I?
- I used to share all my dotfiles, scripts included, but I was too afraid that I would publish some secrets someday, so I stopped doing that. For synchronizing commands, aliases and other stuff between computers I use Chezmoi.
- To use Fish instead of fighting with start up time of Zsh with hundreds of plugins
- Always use the so-called “strict mode” in Bash, that is, the
set -euo pipefail
line. It will make Bash error on non-zero exit code, undefined variables and non-zero exit codes in commands in pipe. Also, always use shellcheck. It’s extremely easy to make a mistake in Bash. If you want to check the single command exit code manually, just wrap it inset +e
andset -e
. - Consider writing your scripts in Python. Like Bash, it also has some warts, but is multiplatform and easy to read. I have a snippet which contains some boilerplate like a
main
function definition withArgumentParser
instantiated. Then at the end of the script themain
function is called wrapped intry … except KeyboardInterrupt: exit(130)
which should be a default behavior. - Absolutely not a bad practice. If you need to use them on a remote server and can’t remember what they stand for, you can always execute
type some_command
. Oh, and read about abbreviations in Fish. It always expands the abbreviation, so you see what you execute.
Do you use bash? Yes because it is everywhere and available by default.