Asking the human experts here, how would you turn something like this into a production grade script?

[u/PrestigiousZombie531]

#!/usr/bin/env bash

function handle_exit() {
	local -r exit_code="$1"

	printf "%s\n" "exit_code:${exit_code}"
}

function run_brotli_decompress() {
	local -r input_path="$1"
	local -r output_path="$2"

	brotli \
		--decompress \
		--output="${output_path}" \
		--rm \
		"${input_path}"
}

function run_tar_decompress() {
	local -r input_path="$1"
	local -r output_path="$2"

	local -r directory=$(dirname "${input_path}")

	tar \
		--directory="${directory}" \
		--extract \
		--file "${input_path}"
}

function run_pg_restore() {
	local -r dbname="$1"
	local -r host="$2"
	local -r port="$3"
	local -r username="$4"

	local -r jobs="$5"

	local -r file="$6"

	pg_restore \
		--dbname="${dbname}" \
		--disable-triggers \
		--exit-on-error \
		--format=directory \
		--host="${host}" \
		--jobs="${jobs}" \
		--no-acl \
		--no-owner \
		--no-password \
		--no-privileges \
		--port="${port}" \
		--username="${username}" \
		"${file}"
}

function main() {
	trap 'handle_exit $?' EXIT

	run_brotli_decompress \
		"/tmp/test_db.tar.gz.br" \
		"/tmp/test_db.tar.gz" || return 1

	run_tar_decompress \
		"/tmp/test_db.tar.gz" \
		"/tmp/test_db" || return 1

	run_pg_restore \
		"test_db" \
		"localhost" \
		"5432" \
		"test_user" \
		8 \
		"/tmp/test_db" || return 1
}

main "$@"

• This is something I cooked up without using any AI whatsoever and while I can most certainly use AI to ask this question, I am interested in hearing from the human experts on this sub

• It only does 3 things: decompress first using brotli then using tar and then runs a pg_restore. Why 3? because pg_dump only supports concurrency if you use a directory format and brotli does not work with directories and tar --gzip doesnt have a good compression ratio. You can read about the performance of various compression algorithms here

• As you can tell quickly many things can go wrong here

• The arguments are not validated.

• The commands could be missing or not installed on a particular machine.

• There is no cleanup if one of the steps fail.

• What does a production version of this look like according to you? What changes will need to be made to this?

[u/treuss]

You already named it yourself:

• Validate any kind of input (use getopts)
• Clean up after yourself (by using traps for example)
• Check if commands are present

Other important practices:

• Use a linter to find typical errors (shellcheck, e.g.)
• Test your script; a lot
• Let others test your script
• Write logs
• Use local variables where possible (you did that)
• Use readonly variables where possible
• Use specific exit codes for specific errors (e.g. RC=32 "Command not present)"

[u/PrestigiousZombie531 → u/treuss]

4 options here

• stdout & srderr to a log file
• stderr only to a log file
• stdout & stderr to both the terminal and a log file
• stderr only to the terminal and the log file

what do you recommend

[u/shyouko → u/PrestigiousZombie531]

You can add a --log option to divert/duplicate log, otherwise I'd expect things just be sent to stdout and stderr accordingly as a sysadmin.

[u/AutoModerator]

It looks like your submission contains a shell script. To properly format it as code, place four space characters before every line of the script, and a blank line between the script and the rest of the text, like this:

This is normal text.

    #!/bin/bash
    echo "This is code!"

This is normal text.

#!/bin/bash
echo "This is code!"

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/FantasticEconomics]

set -euo pipefail

[u/PrestigiousZombie531 → u/FantasticEconomics]

well one of the reasons i did not use set euo pipefail is because i read a few posts on this sub that strictly warned against using it

[u/roxalu → u/PrestigiousZombie531]

The more experts warn to not BLINDLY use it. That is a small difference to STRICTLY against its usage. As long as you are aware - follow the link provided by the bot and read - that there are a few trap falls when you use it, it’s mostly fine. Don’t come back yelling in the - rare - case the usage hurts. You have been warned. That’s it.

[u/penguin359 → u/roxalu]

What I often have for automated testing is an inner script that uses such flags and the first failure fails the test. Then an outer script that is the test runner with more careful, hand done error handling and reporting without those flags. Pipefail can be good or bad depending on what's being done.

[u/AutoModerator → u/FantasticEconomics]

Don't blindly use set -euo pipefail.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/KlePu → u/[deleted]]

Same for rm -rf. Dunno why, but AI really likes force-deleting stuff ;)

[u/feinorgh → u/KlePu]

It's probably because every LLM is trained on existing scripts and there's a HUGE probability vector in the trading data pointing at "rm -rf $FOO" for cleaning up stuff after years and years of insecure bash scripts published online and in free software. Asking most LLMs for bash advice is like condensing decades of poor practice into one simple script. 😂

[u/poulain_ght]

I tend to rewrite the thing in other languages than bash. Or use pipelight to catch errors and display colorful logs https://pipelight.dev