General Advice for shell scripts

taladar, 3 months ago

I use bash for scripts almost exclusively even though i use zsh interactively (startup scripts for zsh are an obvious exception).

The vast majority of my scripts start with

<span style="color:#323232;">  set -e -u
</span>

which makes the script exit if a command (that is not in a few special places like an if) exits with an error status code and also complains about unbound variables when you use them.

Use

<span style="color:#323232;">bash -n
</span>

and

<span style="color:#323232;">shellcheck
</span>

to test your script for errors and problems if you try it.

Always use curly braces for variables to avoid issues with strings after the variable name being interpreted as part of the variable name.

Always use 10# before numbers in $(()) expressions to avoid leading zeroes turning your decimal number variables into octal ones.

Always use

<span style="color:#323232;">while read -r foo
</span><span style="color:#323232;">do
</span><span style="color:#323232;">...
</span><span style="color:#323232;">done < <(command ...)
</span>

instead of

<span style="color:#323232;">command ... | while read -r foo
</span><span style="color:#323232;">do
</span><span style="color:#323232;">...
</span><span style="color:#323232;">done
</span>

to avoid creating a subshell where some changes you make will not affect your script outside the loop.

In

<span style="color:#323232;">while read -r foo
</span><span style="color:#323232;">do
</span><span style="color:#323232;">...
</span><span style="color:#323232;">done < ...
</span>

loops always make sure you redirect all stdin from /dev/null or otherwise close it with suitable parameters or the content of your loop will eat some of the lines you meant for the read. Alternatively fill a bash array in the loop and then use a for loop to call your commands and do more complex logic.

When using temporary directories or similar resources use

<span style="color:#323232;">cleanup()
</span><span style="color:#323232;">{
</span><span style="color:#323232;"> ...
</span><span style="color:#323232;">}
</span><span style="color:#323232;">trap cleanup EXIT
</span>

handlers to clean up after the script in case it dies or is killed (by SIGTERM or SIGINT,…; obviously not SIGKILL).

When writing scripts for cronjobs take into account that the environment (PATH In particular) might be more limited. Also take into account that stderr output and non-zero exit status can lead to an email about the cronjob.

Use pushd and popd instead of cd (especially cd …), redirect their output to /dev/null. This will prevent your scripts from accidentally running later parts of the script in a wrong directory.

There are probably many other things to consider but that is just standard stuff off the top of my head.

If you do need any sort of data structure and in particular arrays of data structures use a proper programming language. I would recommend Rust since a compiled language is much easier to run on a variety of systems than the Python so many others here recommend, especially if you need to support the oldest supported version of an OS and the newest one at the same time.

atzanteol, 3 months ago

Great list! I would add “always surround variables with quotes in case the value contains spaces”.

taladar, 3 months ago

Good point, forgot one of the basics.

Also, to make your scripts more readable and less error prone use something like

<span style="color:#323232;">if [[ $# -gt 0 ]] && [[ "$1" == "--dry-run" ]]; then
</span><span style="color:#323232;">  dry_run=1
</span><span style="color:#323232;">  shift
</span><span style="color:#323232;">else
</span><span style="color:#323232;">  dry_run=0
</span><span style="color:#323232;">fi
</span><span style="color:#323232;">
</span><span style="color:#323232;">if [[ $# != 3 ]]; then
</span><span style="color:#323232;">  echo "Usage: $0 [ --dry-run ] <description of foo> <description of bar> <description of baz>" >&2
</span><span style="color:#323232;">  exit 1
</span><span style="color:#323232;">fi
</span><span style="color:#323232;">
</span><span style="color:#323232;">foo="$1"
</span><span style="color:#323232;">shift
</span><span style="color:#323232;">bar="$1"
</span><span style="color:#323232;">shift
</span><span style="color:#323232;">baz="$1"
</span><span style="color:#323232;">shift
</span>

at the start of your script to name your parameters and provide usage information if the parameters did not match what you expected. The shift and use of $1 at the bottom allows for easy addition and removal of parameters anywhere without renumbering the variables.

Obviously this is only for the 90% of scripts that do not have overly complex parameter needs. For those you probably want to use something like getopt or another language with libraries like the excellent clap crate in Rust.

GravitySpoiled, 3 months ago

Thankyou very much!

danielquinn, 3 months ago (edited 3 months ago)

I recommend writing everything in Bourne shell (/bin/sh) for a few reasons:

• Bash is more capable, which is nice, but if you’re fiddling with complex data structures, you probably should be using a more maintainable language like Python.
• Bash is in most places, but crucially not everywhere. Docker-based deployments for example often use Ash which is very similar to Bash, but lacks support for arrays and a few other things.
• Bourne’s limitations force you to rethink your choices regularly. If you find yourself hacking around a lack of associative arrays for example, it’s probably time to switch to a proper language.

Also two bits of advice.

1. Use shellcheck. There’s a website that’ll check your script for you as well as a bunch of editor extensions that’ll do it in real time. You will absolutely write better, safer code with it.
2. If your script exceeds 300 lines. Stop and rewrite it in a proper language. Your future self will thank you.

BrianTheeBiscuiteer, 3 months ago

Bash script for simple things (although Fish is my regular shell) and Node or Python scripts for complex things. Using #!/usr/bin/env node works just like it would for Bash so you know.

lolcatnip, 3 months ago

This. I still write plenty of bash scripts, but I’ve noticed that except for really simple cases, I very quickly reach a point where I would have been better off using Python instead. And when I start with a Python scripts I often end up redoing it in Rust for a variety of reasons. It’s just easy to underestimate how serious a programming project is. At least I’ve never started something in bash that I needed to migrate to Rust.

(I think a lot of people would see Go as the next logical step from Python, but I personally find some things about Go really irritating.)

Quackdoc, 3 months ago

I make my scripts with modern shells in mind since they let you use arrays for arguments which is vastly superior to doing `` for continuing the script line, I give the example here docs.blissos.org/…/advanced-qemu-config/#flexible…

gnuhaut, 3 months ago (edited 3 months ago)

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 #!/bin/sh 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.

SpaceCadet, 3 months ago (edited 3 months ago)

Do not use #!/bin/sh if you’re not writing bash-only scripts

Actually #!/bin/sh 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 #!/bin/sh.

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.

gnuhaut, 3 months ago

Oh I wanted to say, “Do not use #!/bin/sh if you’re not writing 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.

SpaceCadet, 3 months ago

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:

<span style="color:#323232;">When invoked as sh, bash enters posix mode after the startup files are read.
</span><span style="color:#323232;">...
</span><span style="color:#323232;">--posix
</span><span style="color:#323232;">    Change  the  behavior  of bash where the default operation differs from the POSIX standard to 
</span><span style="color:#323232;">    match the standard (posix mode). See SEE ALSO below for a reference to a document that details 
</span><span style="color:#323232;">    how posix mode affects bash's behavior.
</span>

But if you create a file with a few well known bashisms, and a #!/bin/sh shebang, it runs the bashisms just fine.

starman, 3 months ago

That’s the way I do it:

<span style="color:#323232;">#!/usr/bin/env nix
</span><span style="color:#323232;">#! nix shell nixpkgs#nushell <optionally more dependencies>  --command nu
</span><span style="color:#323232;">
</span><span style="color:#323232;"><script content>
</span>

But those scripts are only used by me

thedeadwalking4242, 3 months ago

This is the way

Dirk, 3 months ago

• Do you use bash? If not, which one do you use? zsh, fish? Why do you do it?
• Do you write #!/bin/bash or #!/bin/sh? Do you write fish exclusive scripts?

I use bash, and I use #!/bin/bash for my scripts. Some are POSIX compliant, some have bashisms. But I really don’t care about bashisms, since I explicitly set the bash as interpreter. So no, no fish exclusive scripts, but some “bash exclusive” scripts. Since fish is aimed towards being used as interactive shell I don’t see a real reason to use it as interpreter for scripts anyways.

• 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?

I have my scripts in $HOME/.scripts and softlink them from a directory in $PATH. Some of the scripts are versioned using Git, but the repository is private and I do not plan sharing them because the repoand the scripts scripts contain some not-tho-share information and mostly are simply not useful outside my carefully crafted and specific environment. If I want to share a script, I do it individually or make a proper public Git repository for it.

Since my server(s) and my workstations have different use cases I do not share any configuration between them. I share some configuration between different workstations, though. My dotfiles repository is mainly there for me to keep track of changes in my dotfiles.

is it bad practice to create a handful of commands

It becomes bad practice if it is against your personal or corporate guidelines regarding best practices. While it is not particularly bad or insecure, etc. to create bash scripts containing a single command, maybe use an alias instead. The $1 is automatically the first parameter after typing the alias in the shell.

<span style="color:#62a35c;">alias </span><span style="font-weight:bold;color:#795da3;">podup</span><span style="font-weight:bold;color:#a71d5d;">=</span><span style="color:#183691;">"podman compose up -d"
</span><span style="color:#62a35c;">alias </span><span style="font-weight:bold;color:#795da3;">poddown</span><span style="font-weight:bold;color:#a71d5d;">=</span><span style="color:#183691;">"podman compose down"
</span><span style="color:#62a35c;">alias </span><span style="font-weight:bold;color:#795da3;">podlog</span><span style="font-weight:bold;color:#a71d5d;">=</span><span style="color:#183691;">"podman logs -f --tail 20"
</span>

Not quite sure about the podman syntax, if podman exec /bin/sh -it “$1” also works, you can use alias podenter="podman exec /bin/sh -it, Otherwise a simple function would do the trick.

daddyjones, 3 months ago

Am I missing something - doesn’t bash have tab completion or of the box?

zwekihoyy, 3 months ago

hardly

bionicjoey, 3 months ago

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

jherazob, 3 months ago

A good idea i have been spreading around relevant people lately is to use ShellCheck as you code in Bash, integrate it in your workflow, editor or IDE as relevant to you (there’s a commandline tool as well as being available for editors in various forms), and pass your scripts through it, trying to get the warnings to go away. That should fix many obvious errors and clean up your code a bit.

DasFaultier, 3 months ago (edited 3 months ago)

• I use bash, because I never had the time to learn anything else.
• Like @jlsalvador said, I use the #!/usr/bin/env bash shebang.
• Nope
• Also nope
• Nope. Shell scripts reside in Git repos on Gitlab/Gitea/Forgejo and are checked out using Ansible playbooks onto the servers as necessary.
• For scripts? Python. Read this blog post by the great @isotopp. For interactive use? bash is just fine for me, though I’ve customized it using Starship and created some aliases to have colored/pretty output where possible.
• Use 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.
• Be prepared to shave yaks. Take breaks, touch grass, pet a dog. Use set -x inside your Bash script or bash -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.
• Nope, it’s absolutely not bad practice to create aliases to save you some typing in interactive shell. You shouldn’t use them inside your scripts though, because they might/will not be available in other environments.

I switched to fish because it has tab completion Yeah, so does Bash, just install it.

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

ToolsDebian-Packages available- mtr - iputils-tracepath - iproute2 - zsh - httpie - aria2 - icdiff - progress - diffoscope - atop - powertop - ntopng - ethtool - nethogs - vnstat - ss - glances - discus - dstat - logwatch - swatch - multitail - lynis - ncdu (du-clone), alias du=“ncdu --color dark -rr -x --exclude .git --exclude node_modules” - nnn (fully-featured terminal file manager. It’s tiny, nearly 0-config and incredibly fast. github.com/jarun/nnn) - slurm - calcurse - newsbeuter - tig (“ncurses TUI for git. It’s great for reviewing and staging changes, viewing history and diffs.”) - qalc -ttyrec - taskwarrior - ttytter - ranger - ipcalc - pandoc - moreutils - googler - weechat - pdftk - abcde - dtrx - tload - ttyload - cockpit - sar - ht (hte Hex Editor) - dhex - ack (grep-clone) - silversearcher-ag (grep-clone) - ripgrep (“recursively searches file trees for content in files matching a regular expression. It’s extremely fast, and respects ignore files and binary files by default.”, github.com/BurntSushi/ripgrep) - exa (statt ls) the.exa.website (“replacement for ls with sensible defaults and added features like a tree view, git integration, and optional icons.”) - fzf (CLI fuzzy finder), alias preview=“fzf --preview ‘bat --color "always" {}’” - fd (simple, fast and user-friendly alternative to ‘find’, github.com/sharkdp/fd) -entr (watch-clone) - csvkit (awk-clone) - ccze (log coloring) - surfraw -hexyl (“hex viewer that uses Unicode characters and colour”, github.com/sharkdp/hexyl) -jq (“awk for JSON. It lets you transform and extract information from JSON documents”, stedolan.github.io/jq/) -pass (“password manager that uses GPG to store the passwords”, github.com/lunaryorn/mdcat) - restic (“backup tool that performs client side encryption, de-duplication and supports a variety of local and remote storage backends.”, restic.net) - mdp (Markdown Presentation on CLI) -grepcidr - qrencode - caca-utils (show images on the CLI) - fbi ( & fbgs) (show images in Framebuffer device) - fbcat (take screnshot on framebuffer device) - nmap - micro (CLI Text Editor, ab Debian 11, micro-editor.github.io) - masscan (github.com/robertdavidgraham/masscan) - socat (Nachfolger von netcat, www.heise.de/select/ix/2017/11/1509815804306324) - dc3dd (patched version of GNU dd with added features for computer forensics) - smem (memory reporting tool) - free (Show Linux server memory usage) - mpstat (Monitor multiprocessor usage on Linux, part of sysstat package) - pmap (Montor process memory usage on Linux, part of the procps) - monit (Process supervision) - oping & noping - saidar (Curses-basiertes Programm für die Anzeige von Live-Systemstatistiken) - reptyr (Tool for moving running programs between ptys) - gron (github.com/tomnomnom/gron, makes JSON greppable, kann HTTP-Requests absetzen) - jc (github.com/kellyjonbrazil/jc, CLI tool and python library that converts the output of popular command-line tools and file-types to JSON or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.) - bat (cat-clone), alias cat=‘bat’ (“alternative to the common (mis)use of cat to print a file to the terminal. It supports syntax highlighting and - git integration.”, github.com/sharkdp/bat) - ioping (github.com/koct9i/ioping, simple disk I/0 latency measuring tool, auch für disk seek rate/iops/avg) - vd (Visidata, multipurpose terminal utility for exploring, cleaning, restructuring and analysing tabular data. Current supported sources are TSV, CSV, fixed-width text, JSON, SQLite, HTTP, HTML, .xls, and .xlsx) - pdfgrep - duf github.com/muesli/duf (combined df and du, ncurses-based) - nala (apt-alternate, gitlab.com/volian/nala, christitus.com/stop-using-apt/) - iprange - tldr - rmlint - nvtop (github.com/Syllo/nvtop, GPUs process monitoring for AMD, Intel and NVIDIA) - lf (lf (as in “list files”) is a terminal file manager written in Go with a heavy inspiration from ranger file manager) no Deb pkg avail- oh-my-zsh (ohmyz.sh) - webmin - observium - cheat (github.com/cheat/cheat, create and view interactive cheatsheets on the command-line.) - bropages - ipbt / its-playback-time - todo - earthquake - suplemon - Newsroom - unity - ired - wpe - prettyping (ping), alias ping=‘prettyping --nolegend’ - diff-so-fancy (diff-clone) - q (query CSV Files with SQL) harelba.github.io/q/- gping (ping with a graph in CLI) - http-prompt (install via pip) - alt (“finding the alternate to a file. E.g. the header for an implementation or the test for an implementation. I use it paired with Neovim”, github.com/uptech/alt) - chars (“shows information about Unicode characters matching a search term.”, github.com/antifuchs/chars) - dot (“dotfiles manager. It maintains a set of symlinks according to a mappings file”, github.com/ubnt-intrepid/dot) - dust (“alternative du -sh. It calculates the size of a directory tree, printing a summary of the largest items.”, github.com/bootandy/dust) - eva (“command line calculator similar to bc, with syntax highlighting and persistent history.”, github.com/NerdyPepper/eva) - hyperfine (“command line benchmarking tool. It allows you to benchmark commands with warmup and statistical analysis.”, github.com/sharkdp/hyperfine) - mdcat (“renders Markdown files in the terminal”, github.com/lunaryorn/mdcat) - podman (“alternative to Docker that does not require a daemon. Containers are run as the user running Podman so files written into the - host don’t end up owned by root. The CLI is largely compatible with the docker CLI.”, podman.io) - skim (“fuzzy finder. It can be used to fuzzy match input fed to it. I use it with Neovim and zsh for fuzzy matching file names.”) - z (“tracks your most used directories and allows you to jump to them with a partial name.”, github.com/rupa/z) - alias wetter_graph=‘finger dresden@graph.no’ - alias wetter_color=‘curl wttr.in’ - alias maps_cli=‘telnet mapscii.me’ - github.com/say4n/crappybird- asciicker.com- cbonsai gitlab.com/jallbrit/cbonsai- GNU poke binary editor www.jemarch.net/poke / git.savannah.gnu.org/cgit/poke.git- gdu GoDiskUsage github.com/dundee/gdu- Cirrus CLI github.com/cirruslabs/cirrus-- tuxi github.com/Bugswriter/tuxi personal CLI assistant - ngrep github.com/jpr5/ngrep- topgrade github.com/r-darwish/topgrade- ndiff nmap.org/ndiff/ compare nmap scans - natlas github.com/natlas/natlas- sift sift-tool.org grep-alternative - xplr github.com/sayanarijit/xplr (hackable, minimal, fast TUI file explorer, stealing ideas from nnn and fzf) - croc github.com/schollz/croc (allows any two computers to simply and securely transfer files and folders, great for forensics) - slidev sli.dev (HTML5 presentations) - lfs github.com/Canop/lfs (df alternative) - vtop (github.com/MrRio/vtop) - gtop (github.com/aksakalli/gtop) - up (Ultimate Plumber github.com/akavel/up) - ttyd (github.com/tsl0922/ttyd, Share your terminal over the web) - nms (no more secrets, github.com/bartobri/no-more-secrets, A command line tool that recreates the famous data decryption effect - seen in the 1992 movie Sneakers.) - xsv (github.com/BurntSushi/xsv, A fast CSV command line toolkit written in Rust.) - fx (github.com/antonmedv/fx, Terminal JSON viewer) - ccat (github.com/owenthereal/ccat, colorized cat mit Syntax Highlighting) - delta (github.com/dandavison/delta, A syntax-highlighting pager for git, diff, and grep output. VORSICHT: Paket einer anderen Software mit gleichem Namen unter Debian Bullseye als Paket verfügbar!) - dyff (github.com/homeport/dyff, /ˈdʏf/ - diff tool for YAML files, and sometimes JSON)

___

DasFaultier, 3 months ago

Rest of the list:

Tools pt. 2- skim (github.com/lotabout/skim, Fuzzy finder in Rust) - choose (github.com/theryangeary/choose, A human-friendly and fast alternative to cut and (sometimes) awk) - sd (github.com/chmln/sd, wie sed, Intuitive find & replace CLI, mit regex) - map (github.com/soveran/map, Map lines from stdin to commands, gemütliche Variante von xargs mit einfacherer Syntax und weniger Funktionsumfang) - crush (github.com/liljencrantz/crush, Crush is a command line shell that is also a powerful modern programming language. Kann u.a. SQL-Statements) - xxh (github.com/xxh/xxh, Bring your favorite shell wherever you go through the ssh.) - starship (starship.rs, Shell-Prompt anpassen mit Nerdfont) - q (github.com/natesales/q, A tiny & colorful command line DNS client with support for UDP, TCP, DoT, DoH, DoQ and ODoH.) - gping (github.com/orf/gping, Ping, but with a graph) - broot (github.com/Canop/broot, A new way to see and navigate directory trees : dystroy.org/broot) - dust (github.com/bootandy/dust, intuitive du colored) - dutree (github.com/nachoparker/dutree, a tool to analyze file system usage written in Rust) - lsd (github.com/Peltoche/lsd, next-gen ls) - mcfly (github.com/cantino/mcfly, Fly through your shell history using neural nets) - procs (github.com/dalance/procs, A modern replacement for ps written in Rust, color, human readable, multi-column keword search) - bottom (github.com/ClementTsang/bottom, top replacement, cross-platform graphical process/system monitor, zoom support) - btop++ (github.com/aristocratos/btop, resource monitor CPU, RAM, IO, processes, IN SCHICK!!!, C+±continuation of bpytop github.com/aristocratos/bpytop) - musikcube (github.com/clangen/musikcube, cross-platform, terminal-based music player, audio engine, metadata indexer, and server in c++ with an ncurses TI, incl.Android App) - viu (github.com/atanunq/viu, Terminal image viewer with native support for iTerm and Kitty, auch animated gif) - glow (github.com/charmbracelet/glow, Render markdown on the CLI) - falsisign (gitlab.com/edouardklein/falsisign, For bureaucratic reasons, a colleague of mine had to print, sign, scan and send by email a high number of pages. To save trees, ink, time, and to stick it to the bureaucrats, I wrote this script.) - ponysay (github.com/erkin/ponysay, wie cowsay mit bunten Ponies) - sniffnet (github.com/GyulyVGC/sniffnet, cross-platform application to monitor your network traffic with ease, Debian-Pakete von GitHub verfügbar) - netop (github.com/ZingerLittleBee/netop, monitor network traffic with bpf) - corefreq (github.com/cyring/CoreFreq, CPU monitoring software for 64-bits Processors.) - ctop (github.com/bcicen/ctop, Top-like interface for container metrics) - dua (github.com/Byron/dua-cli, View disk space usage and delete unwanted data, fast.) - dust (github.com/bootandy/dust, A more intuitive version of du in rust) - helix editor - lnav (github.com/tstack/lnav Log navigator) - bottom (github.com/ClementTsang/bottom, another cross-platform graphical process/system monitor) - broot (github.com/Canop/broot, a different than ranger/lf approach to navigating folders) - mdr (github.com/michaelmure/mdr, a markdown viewer) - eza (github.com/eza-community/eza, modern ls, with cool features like file icons) - ouch (github.com/ouch-org/ouch, It’s a CLI tool for compressing and decompressing for various formats. such as .tar .zip 7z .gz .xz .lzma .bz .bz2 .lz4 .sz .zst .rar) - spotify-tui (github.com/Rigellute/spotify-tui, Spotify CLI frontend (Spotify via terminal)) - toilet (caca.zoy.org/wiki/toilet, turn text into ASCII art) DNS tools: - viewdns.info - dnslytics.com - dnsspy.io - leafdns.com - dnsdumpster.com - intodns.com - www.zonecut.net/dns - xip.io - nip.io - ptrarchive.com - www.whatsmydns.net - ceipam.eu/en/dnslookup.php - spyse.com/tools/dns-lookup - www.buddyns.com/delegation-lab Good stuff for pentesters and security researchers: - contained.af - cryptohack.org - 0x00sec.org - hack.me - chall.stypr.com - crackmes.one - hackxor.net - tryhackme.com - ctftime.org - ctflearn.com - picoctf.org bash ### .bashrc ### CUSTOM FUNCTIONS # https://www.linuxjournal.com/content/boost-productivity-bash-tips-and-tricks ftext () { grep -iIHrn --color=always “$1” . | less -R -r } duplicatefind (){ find -not -empty -type f -printf “%sn” | sort -rn | uniq -d | xargs -I{} -n1 find -type f -size {}c -print0 | xargs -0 md5sum | sort | uniq -w32 --all-repeated=separate } generateqr (){ # printf “$@” | curl -F-=<- qrenco.de printf “$@” | qrencode -t UTF8 -o - }

GravitySpoiled, 3 months ago

My brian has too little ram to process the list of packages 😂 good to know the rest!

DasFaultier, 3 months ago

Neither does mine, but, I keep it to test a new tool from time to time.

exu, 3 months ago (edited 3 months ago)

I use Bash for scripts, though my interactive shell is Fish.

Usually I use #!/usr/bin/env bash 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. (Use #!/usr/bin/env sh then.)

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.

GravitySpoiled, 3 months ago

#/usr/bin/env bash typo? #!/usr/bin/env bash

thx for the tips!

I prefer single files over aliases since I can more easily manage each command.

exu, 3 months ago

You’re right, it’s #!

Strit, 3 months ago

I use bash and I usually put /bin/bash in my scrtipts, because that’s where I know it works. /bin/sh is only if it works on many/all shells.

I don’t have many such scripts, so I just have one. I don’t really share them, as they are made for my usecase. If I do create something that I think will help others, then yes, I share them in git somewhere.

I do have a scripts folder in my Nextcloud that I sync around with useful scripts.

Some of your examples can probably just be made into aliases with alias alias_name=“command_to_run”.

GravitySpoiled, 3 months ago

thx! Why do you think that aliases are better for it?

I moved away from aliases because I have a neat command management where each command is one script.

Strit, 3 months ago

I can’t speak for anyone else, but for me, it’s just one file to backup to keep all your custom commands (.bashrc) while it would be many files if you have a script for each.

I can’t see the benefit of having a script for just one command (with arguments) unless those arguments contain variables.

tfowinder, 3 months ago

Use

set -x

For debugging

GravitySpoiled, 3 months ago

Good to know!

jlsalvador, 3 months ago

<span style="color:#323232;">#!/usr/bin/env bash
</span>

A folder dotfiles as git repository and a dotfiles/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).

clmbmb, 3 months ago

#!/usr/bin/env bash

This is the way!

GravitySpoiled, 3 months ago

why?

unlawfulbooger, 3 months ago (edited 3 months ago)

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:

<span style="font-style:italic;color:#969896;">#!/usr/bin/env bash
</span><span style="color:#62a35c;">set</span><span style="color:#323232;"> -euo pipefail
</span>

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.

GravitySpoiled, 3 months ago

Nice, thx!

bizdelnick, 3 months ago

/bin/sh is always /bin/sh.

clmbmb, 3 months ago

#!/usr/bin/env will look in PATH for bash, and bash 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.

GravitySpoiled, 3 months ago

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 wiki.archlinux.org/title/Dotfiles

mryessir, 3 months ago

Instead of a install skript, check out GNU stow. It does exactly that and you can interqctively choose which things to install/symlink.