feat: add logging to file and countdown

[YerdosNar]

• Add logfile at /tmp/.Blitz_isntall_8997 with a timestamp
• Display log location and pause, user can see logfile location
• Add real time countdown
• Now it is easier to debug

[Copilot]

Pull request overview

This PR enhances the Blitz installation script by adding comprehensive file logging and an improved user experience during the final installation steps. The changes enable better debugging capabilities by persisting all installation logs to a timestamped file.

Key changes:

• Implements file-based logging to /tmp/.Blitz_install_$$ with all log levels (INFO, OK, WARN, ERROR)
• Adds interactive pause showing log file location before launching the menu
• Replaces simple sleep with a visual countdown timer displaying remaining seconds in color

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The echo statement at line 316 is missing a newline at the end, which could cause the menu output to appear on the same line as "Setup complete! Starting menu!". Consider adding a newline character at the end of the message for proper formatting.

Suggested change

	echo -ne "\r\033[KSetup complete! Starting menu!"
	echo -ne "\r\033[KSetup complete! Starting menu!\n"

[Copilot]

The log file creation in log_init() doesn't check if the write operation succeeds. If /tmp is not writable or disk is full, the script will continue silently without logging. Consider adding error handling to verify the log file was created successfully.

Suggested change

	echo "=================================" > "$LOG_FILE"
	echo " Log file created at $(date)" >> "$LOG_FILE"
	echo "=================================" >> "$LOG_FILE"
	echo "" >> "$LOG_FILE"
	chmod 644 "$LOG_FILE"
	if ! {
	echo "=================================" > "$LOG_FILE" && \
	echo " Log file created at $(date)" >> "$LOG_FILE" && \
	echo "=================================" >> "$LOG_FILE" && \
	echo "" >> "$LOG_FILE"
	}; then
	echo "Warning: Unable to create log file at '$LOG_FILE'. Logging will be disabled." >&2
	LOG_FILE="/dev/null"
	return 1
	fi
	if ! chmod 644 "$LOG_FILE"; then
	echo "Warning: Unable to set permissions on log file '$LOG_FILE'." >&2
	fi

[Copilot]

Each logging function appends to the log file without checking if the write operation succeeds. If the log file becomes unavailable or disk is full during installation, these operations will fail silently. Consider adding error handling or redirecting stderr to capture write failures.

Suggested change

	log_init() {
	echo "=================================" > "$LOG_FILE"
	echo " Log file created at $(date)" >> "$LOG_FILE"
	echo "=================================" >> "$LOG_FILE"
	echo "" >> "$LOG_FILE"
	chmod 644 "$LOG_FILE"
	}
	log_info() {
	echo -e "${BLUE}${INFO_MARK} ${1}${NC}"
	echo "[INFO] $1" >> "$LOG_FILE"
	}
	log_success() {
	echo -e "${GREEN}${CHECK_MARK} ${1}${NC}"
	echo "[ OK ] $1" >> "$LOG_FILE"
	echo "" >> "$LOG_FILE"
	}
	log_warning() {
	echo -e "${YELLOW}${WARNING_MARK} ${1}${NC}"
	echo "[WARN] $1" >> "$LOG_FILE"
	}
	log_error() {
	echo -e "${RED}${CROSS_MARK} ${1}${NC}" >&2
	echo "[ERROR] $1" >> "$LOG_FILE"
	# Append a single line to the log file with basic error handling.
	# If the write fails (e.g., disk full or log file unavailable),
	# emit a warning to stderr so the failure is not silent.
	log_to_file() {
	# If LOG_FILE is not set for some reason, just skip logging.
	if [ -z "$LOG_FILE" ]; then
	return 0
	fi
	if ! printf '%s\n' "$1" >> "$LOG_FILE"; then
	printf 'WARNING: Failed to write to log file "%s". Message was: %s\n' "$LOG_FILE" "$1" >&2
	fi
	}
	log_init() {
	if [ -z "$LOG_FILE" ]; then
	return 0
	fi
	if ! {
	printf '=================================\n' > "$LOG_FILE" &&
	printf ' Log file created at %s\n' "$(date)" >> "$LOG_FILE" &&
	printf '=================================\n\n' >> "$LOG_FILE";
	}; then
	printf 'WARNING: Failed to initialize log file "%s".\n' "$LOG_FILE" >&2
	return 1
	fi
	chmod 644 "$LOG_FILE" 2>/dev/null || printf 'WARNING: Failed to set permissions on log file "%s".\n' "$LOG_FILE" >&2
	}
	log_info() {
	echo -e "${BLUE}${INFO_MARK} ${1}${NC}"
	log_to_file "[INFO] $1"
	}
	log_success() {
	echo -e "${GREEN}${CHECK_MARK} ${1}${NC}"
	log_to_file "[ OK ] $1"
	log_to_file ""
	}
	log_warning() {
	echo -e "${YELLOW}${WARNING_MARK} ${1}${NC}"
	log_to_file "[WARN] $1"
	}
	log_error() {
	echo -e "${RED}${CROSS_MARK} ${1}${NC}" >&2
	log_to_file "[ERROR] $1"

[Copilot]

The use of a predictable log path in /tmp (LOG_FILE="/tmp/.Blitz_install_$$") combined with shell redirection and chmod 644 allows a classic symlink attack when this script runs as root. An attacker on the same system can pre-create /tmp/.Blitz_install_<pid> as a symlink to a sensitive file (for example /etc/shadow), causing the log_init function to truncate/overwrite that file and relax its permissions to world-readable. You should instead create the log file using a secure, race-free mechanism (e.g., mktemp), avoid following symlinks, and apply restrictive permissions (e.g., 600) so unprivileged users cannot manipulate or read sensitive logs.

Suggested change

	LOG_FILE="/tmp/.Blitz_install_$$"
	log_init() {
	echo "=================================" > "$LOG_FILE"
	echo " Log file created at $(date)" >> "$LOG_FILE"
	echo "=================================" >> "$LOG_FILE"
	echo "" >> "$LOG_FILE"
	chmod 644 "$LOG_FILE"
	LOG_FILE=""
	log_init() {
	if [ -z "$LOG_FILE" ]; then
	LOG_FILE="$(mktemp -p /tmp .Blitz_install_XXXXXXXX)" || {
	echo "Failed to create log file" >&2
	exit 1
	}
	fi
	chmod 600 "$LOG_FILE"
	echo "=================================" > "$LOG_FILE"
	echo " Log file created at $(date)" >> "$LOG_FILE"
	echo "=================================" >> "$LOG_FILE"
	echo "" >> "$LOG_FILE"

[ReturnFI]

Hello and thank you for your contribution, but is there a specific reason? Because in the initial installation phase, we only install a few packages and Python that does not require debugging.

[YerdosNar]

Maybe it is really unnecessary if you say so.
I had bad connection and other failures in my VPS, so I added this for myself, it was easier to understand was it the script failure or VPS failure, network failure, or packages didn't fully install.
So I added what I myself needed, and thought maybe others would need, too.