Forem: vast cow

Understanding `$@`, `$`, `"$@"`, and `"$"` in Shell Scripts

vast cow — Fri, 17 Apr 2026 10:20:55 +0000

When working with shell scripts, handling command-line arguments correctly is critical. Variables like $@ and $* are commonly used to access all positional parameters—but their behavior changes significantly depending on whether they are quoted.

This subtle distinction is a frequent source of bugs. In this article, we’ll break down exactly how each form behaves, with concrete examples.

Positional Parameters: A Quick Refresher

Consider the following script invocation:

./script.sh foo bar "baz qux"

The positional parameters are:

$1 → foo
$2 → bar
$3 → baz qux

To refer to all arguments, we use $@ or $*.

Summary Table

Expression	Meaning	Behavior
`$@`	All arguments	Word-split into separate tokens
`$*`	All arguments	Word-split into separate tokens
`"$@"`	All arguments	Preserves each argument as a separate item
`"$*"`	All arguments	Joins all arguments into a single string

`$@` and `$*` (Unquoted)

for arg in $@; do
  echo "$arg"
done

for arg in $*; do
  echo "$arg"
done

Behavior

Without quotes, both $@ and $* behave almost identically:

They expand to all arguments
Then undergo word splitting based on whitespace

Problem

./script.sh "hello world"

This will be treated as:

hello
world

The original argument structure is lost, which can lead to incorrect behavior.

👉 In practice, unquoted $@ and $* are rarely appropriate.

`"$@"`: The Safe Default

for arg in "$@"; do
  echo "$arg"
done

Behavior

Each argument is preserved as a distinct element
Whitespace inside arguments is retained

Example

./script.sh foo "bar baz"

Output:

foo
bar baz

Key Properties

Maintains the original number of arguments
Preserves boundaries between arguments
Safe for filenames and arbitrary input

👉 This is the form you should use in almost all cases.

`"$*"`: Single String Expansion

echo "$*"

Behavior

All arguments are concatenated into one string
Separated by the first character of IFS (space by default)

Example

./script.sh foo "bar baz"

Output:

foo bar baz

Caveats

Argument boundaries are lost
Not suitable for iteration or per-argument processing

👉 Useful primarily for logging or display purposes.

Visual Comparison

Given:

./script.sh A "B C" D

Expression	Result
`$@`	A B C D
`$*`	A B C D
`"$@"`	"A" "B C" "D"
`"$*"`	"A B C D"

Common Pitfall

❌ Incorrect

for arg in $@; do
  cp "$arg" /dest/
done

If an argument contains spaces, it will be split incorrectly.

✅ Correct

for arg in "$@"; do
  cp "$arg" /dest/
done

This preserves each argument exactly as passed.

Practical Guidelines

Use "$@" when passing or iterating over arguments
Avoid unquoted $@ and $* unless you explicitly want word splitting
Use "$*" only when you intentionally need a single combined string

Why This Difference Exists

The distinction arises from how the shell performs:

Parameter expansion
Word splitting
Quote removal

Notably, "$@" is a special case: it expands to multiple quoted strings, preserving each positional parameter individually. This behavior is unique and not shared by other expansions.

Conclusion

"$@" is the safest and most predictable way to handle arguments
$@ and $* (unquoted) can break argument boundaries
"$*" collapses everything into a single string

If you follow one rule, make it this:

Always use "$@" unless you have a specific reason not to.

My Favorite rclone mount Settings

vast cow — Fri, 17 Apr 2026 06:25:09 +0000

rclone mount is a useful way to access remote storage as if it were a local folder. With the right options, it can feel more responsive and predictable during everyday use. The configuration below is a practical setup for mounting a remote path to a local directory.

Example Configuration

rclone mount remote:/path /mnt/remote \
  --vfs-cache-mode full \
  --vfs-write-back 0s \
  --dir-cache-time 1s \
  --attr-timeout 1s \
  --poll-interval 0 \
  --vfs-read-ahead 1M

Purpose of This Setup

This configuration is designed to make a mounted remote storage path behave more like a normal local filesystem. It is especially useful when you want quick file visibility, immediate write handling, and fewer delays caused by cached directory or file metadata.

The general goal is simplicity: keep the mount usable for regular file operations while reducing the chance of stale information.

What Each Option Does

`--vfs-cache-mode full`

This enables full VFS caching. It helps many applications work correctly with the mounted remote, especially those that expect normal filesystem behavior.

`--vfs-write-back 0s`

This makes writes get handled without an added write-back delay. It is useful when you want changes to be processed immediately.

`--dir-cache-time 1s`

This keeps directory listings fresh by caching them for only a very short time. It helps when files are added, removed, or changed frequently.

`--attr-timeout 1s`

This short timeout reduces how long file attributes are cached. It helps the mount reflect recent changes more quickly.

`--poll-interval 0`

This disables polling for remote changes. In this setup, the mount relies more on short cache times instead of background polling.

`--vfs-read-ahead 1M`

This reads a small amount of extra data in advance. It can improve reading performance without using too much additional memory.

Why This Setup Is Useful

This mount setup is a good choice for users who care about seeing updates quickly and keeping filesystem behavior straightforward. It trades longer cache times for freshness, which can be helpful when the remote content changes often or when you want local access to reflect the remote state more closely.

Conclusion

This rclone mount configuration is a simple and practical setup for everyday use. It focuses on usability, fast visibility of changes, and stable file access. For users who want a remote mount to behave more like a local folder, it is an effective starting point.

Running a non-root Samba server on Singularity (Apptainer) using a non-privileged port and sharing `$HOME`

vast cow — Thu, 16 Apr 2026 12:56:45 +0000

This guide documents how to run a Samba server inside a Singularity / Apptainer container under the following constraints:

No root privileges on the host
Use of a non-privileged port (e.g., 1445 instead of 445)
Sharing the user’s home directory ($HOME)
All writable paths confined to user space

This setup is particularly useful in HPC or restricted environments.

Design Principles

Run smbd as a non-root user
Use port ≥1024 (e.g., 1445)
Disable NetBIOS (nmbd not used)
Use [homes] for per-user home directory sharing
Redirect all writable paths to $HOME
Use bind mounts for filesystem access

1. Build the Container Image

Definition file (`samba.def`)

Bootstrap: docker
From: ubuntu:24.04

%post
    export DEBIAN_FRONTEND=noninteractive
    apt-get update
    apt-get install -y samba smbclient
    apt-get clean
    rm -rf /var/lib/apt/lists/*

Build

singularity build --fakeroot samba.sif samba.def

2. Prepare Host Directories

mkdir -p ~/samba/{etc,log,lock,run,cache,private}
chmod 700 ~/samba/private
mkdir -p ~/samba/run/ncalrpc

3. Create `smb.conf`

~/samba/etc/smb.conf:

[global]
   server role = standalone server
   workgroup = WORKGROUP
   netbios name = MYSMB

   security = user
   map to guest = never

   smb ports = 1445
   disable netbios = yes

   lock directory = /hosthome/USER/samba/lock
   pid directory = /hosthome/USER/samba/run
   state directory = /hosthome/USER/samba/cache
   cache directory = /hosthome/USER/samba/cache
   private dir = /hosthome/USER/samba/private

   log file = /hosthome/USER/samba/log/log.%m
   max log size = 1000

   ncalrpc dir = /hosthome/USER/samba/run/ncalrpc

   load printers = no
   printing = bsd
   printcap name = /dev/null
   disable spoolss = yes

[homes]
   browseable = no
   read only = no
   valid users = %S
   create mask = 0600
   directory mask = 0700

Replace USER:

sed -i "s|USER|$USER|g" ~/samba/etc/smb.conf

4. Bind Mount Setup

Bind your home directory into the container:

export SMB_BIND="$HOME:/hosthome/$USER"

5. Set Samba Password (with fakeroot)

singularity exec --fakeroot \
  --bind "$SMB_BIND" \
  samba.sif \
  smbpasswd -c /hosthome/$USER/samba/etc/smb.conf -a root

In this setup, the password is assigned to the root user inside Samba.

6. Run the Server (Important Fixes Applied)

Prepare log directory bind

mkdir -p ~/samba/varlog

Run

singularity exec --fakeroot \
  --bind "$SMB_BIND" \
  --bind "$HOME/samba/varlog:/var/log/samba" \
  samba.sif \
  smbd --foreground --no-process-group --debug-stdout \
    -s /hosthome/$USER/samba/etc/smb.conf \
    -p 1445

7. Verify

ss -ltnp | grep 1445

smbclient -L //127.0.0.1 -p 1445 -U root

Common Pitfalls and Fixes

1. Read-only `/var/log/samba`

Error:

Unable to open new log file '/var/log/samba/log.smbd'

Fix:

--bind "$HOME/samba/varlog:/var/log/samba"

2. Missing `/run/samba/ncalrpc`

Error:

Failed to create pipe directory /run/samba/ncalrpc

Fix:

Add to smb.conf:

ncalrpc dir = /hosthome/$USER/samba/run/ncalrpc

Create directory:

mkdir -p ~/samba/run/ncalrpc

3. Invalid `-S` option

Error:

Invalid option -S

Fix:

smbd --foreground --no-process-group

4. Privileged ports not allowed

Ports 445 / 139 require root
Use 1445 or another port ≥1024

Summary

This setup enables:

Running Samba without root privileges
Fully contained execution in Singularity
Direct sharing of $HOME
Compatibility with restricted environments (e.g., HPC)

Key Takeaways

Redirect all writable paths to user space
Override container defaults (/var/log, /run)
Always use a non-privileged port

Conceptual Note

This approach is less about “containerizing Samba” and more about:

Running Samba entirely in user space, with Singularity acting as the runtime environment.

Running `sshd` in Rootless Mode

vast cow — Thu, 16 Apr 2026 05:36:51 +0000

This article explains how to run sshd as a normal user without root privileges. The setup uses a custom configuration directory under the user’s home directory and listens on a non-privileged port.

Overview

Normally, sshd is started by the system as root and listens on port 22. In some environments, however, it is useful to run an SSH server without root access. A rootless setup can be used for testing, development, or temporary remote access in user space.

The example here creates a private SSH server environment in ~/.sshd, generates a host key if needed, writes a minimal sshd_config, validates the configuration, and then starts the daemon in the foreground.

Directory and Variable Setup

The setup.sh script begins by defining a few variables:

BASE="$HOME/.sshd"
PORT=2222
SSHD="$(command -v sshd)"

BASE is the working directory for the SSH server files. PORT is set to 2222, which is a non-privileged port and can be used without root. SSHD stores the path to the sshd executable.

The script then creates the required directories:

install -d -m 700 "$BASE" "$HOME/.ssh"

This ensures that both ~/.sshd and ~/.ssh exist with secure permissions.

Generating the Host Key

An SSH server needs its own host key. The script checks whether an Ed25519 host key already exists:

if [ ! -f "$BASE/ssh_host_ed25519_key" ]; then
  ssh-keygen -q -t ed25519 -N '' -f "$BASE/ssh_host_ed25519_key"
fi
chmod 600 "$BASE/ssh_host_ed25519_key"

If the key is missing, it generates one. The permission is then restricted to the owner only. This is important because SSH rejects private keys that are too broadly accessible.

Creating the `sshd` Configuration

The script writes a custom sshd_config file into the user-owned directory.

cat > "$BASE/sshd_config" <<EOF
Port $PORT
ListenAddress 0.0.0.0

UsePAM no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

HostKey $BASE/ssh_host_ed25519_key
PidFile none

PermitRootLogin no
PrintMotd no
PrintLastLog no
X11Forwarding no
AllowUsers $USER

Subsystem sftp internal-sftp
EOF

Key Settings

Port and Listen Address

Port $PORT tells the server to listen on port 2222.
ListenAddress 0.0.0.0 allows connections on all network interfaces.

Authentication

UsePAM no disables PAM because PAM generally requires a system-level setup.
PasswordAuthentication no disables password login.
KbdInteractiveAuthentication no disables keyboard-interactive authentication.
PubkeyAuthentication yes enables public key login.

This makes the server simpler and safer for rootless use by relying only on SSH keys.

Host Key and PID File

HostKey $BASE/ssh_host_ed25519_key points to the host key generated earlier.
PidFile none avoids writing a PID file, which is useful in lightweight user-space execution.

Restrictions

PermitRootLogin no disallows root login.
PrintMotd no and PrintLastLog no suppress extra login messages.
X11Forwarding no disables X11 forwarding.
AllowUsers $USER limits access to the current user only.

SFTP Support

Subsystem sftp internal-sftp enables SFTP using the built-in internal subsystem.

Validating the Configuration

At the end of setup.sh, the script verifies the configuration:

"$SSHD" -t -f "$BASE/sshd_config"

This is a useful step because it checks the syntax before starting the server.

Starting the SSH Server

The start.sh script is very small:

#!/bin/bash
BASE="$HOME/.sshd"
SSHD="$(command -v sshd)"
exec "$SSHD" -D -e -f "$BASE/sshd_config"

What This Does

-D keeps sshd in the foreground.
-e sends log output to standard error.
-f "$BASE/sshd_config" tells sshd to use the custom configuration file.

Using exec replaces the shell process with sshd, which is a clean way to launch the server.

How to Use It

A typical flow is:

Run setup.sh once to create the configuration and host key.
Make sure your public key is present in ~/.ssh/authorized_keys.
Run start.sh to launch the SSH server.
Connect to it on port 2222.

For example:

ssh -p 2222 user@host

Benefits of This Approach

This rootless SSH setup has several advantages:

It does not require system-wide configuration.
It avoids privileged ports.
It works well for personal environments and temporary setups.
It keeps all SSH server files under the user’s home directory.

Conclusion

This example provides a compact way to run sshd without root privileges. By using a private configuration directory, a non-privileged port, and public key authentication only, it creates a simple and practical SSH server for user-space operation.

Scripts

setup.sh

#!/bin/bash 
BASE="$HOME/.sshd" 
PORT=2222 
SSHD="$(command -v sshd)" 

install -d -m 700 "$BASE" "$HOME/.ssh" 

# server host key 
if [ ! -f "$BASE/ssh_host_ed25519_key" ]; then 
  ssh-keygen -q -t ed25519 -N '' -f "$BASE/ssh_host_ed25519_key" 
fi 
chmod 600 "$BASE/ssh_host_ed25519_key" 

cat > "$BASE/sshd_config" <<EOF 
Port $PORT 
ListenAddress 0.0.0.0 

UsePAM no 
PasswordAuthentication no 
KbdInteractiveAuthentication no 
PubkeyAuthentication yes 

HostKey $BASE/ssh_host_ed25519_key 
PidFile none 

PermitRootLogin no 
PrintMotd no 
PrintLastLog no 
X11Forwarding no 
AllowUsers $USER 

Subsystem sftp internal-sftp 
EOF 

"$SSHD" -t -f "$BASE/sshd_config"

start.sh

#!/bin/bash 
BASE="$HOME/.sshd" 
SSHD="$(command -v sshd)" 
exec "$SSHD" -D -e -f "$BASE/sshd_config"

How to Build NCCL Tests in an NVIDIA HPC SDK Environment

vast cow — Tue, 14 Apr 2026 08:23:44 +0000

To build nccl-tests in an NVIDIA HPC SDK environment, you need to set the correct paths for CUDA, NCCL, and MPI, and then run make. This article briefly explains the required environment variables and the build command.

Overview

First, define the locations of CUDA and NCCL based on your NVIDIA HPC SDK installation. Then set MPI_HOME to the Open MPI bundled with HPC-X alongside NCCL.

export CUDA_HOME="$NVHPC_ROOT/cuda"
export NCCL_HOME="$NVHPC_ROOT/comm_libs/nccl"
export MPI_HOME="$(readlink -f "$NCCL_HOME")/../hpcx/latest/ompi"
make -kj MPI=1 CUDA_HOME="$CUDA_HOME" NCCL_HOME="$NCCL_HOME" MPI_HOME="$MPI_HOME"

Meaning of Each Environment Variable

`CUDA_HOME`

CUDA_HOME points to the CUDA directory inside the NVIDIA HPC SDK installation.

export CUDA_HOME="$NVHPC_ROOT/cuda"

This allows the build process to find the correct CUDA headers and libraries.

`NCCL_HOME`

NCCL_HOME specifies the location of the NCCL library included in the HPC SDK.

export NCCL_HOME="$NVHPC_ROOT/comm_libs/nccl"

nccl-tests uses this path to locate the NCCL installation.

`MPI_HOME`

MPI_HOME points to the Open MPI installation provided through HPC-X near the NCCL package.

export MPI_HOME="$(readlink -f "$NCCL_HOME")/../hpcx/latest/ompi"

Using readlink -f resolves the symbolic link and ensures that the path is based on the actual NCCL installation directory.

Build Command

After setting the environment variables, run the following command to build nccl-tests.

make -kj MPI=1 CUDA_HOME="$CUDA_HOME" NCCL_HOME="$NCCL_HOME" MPI_HOME="$MPI_HOME"

Key Points

MPI=1 Enables MPI support during the build.
CUDA_HOME=... Explicitly sets the CUDA location.
NCCL_HOME=... Explicitly sets the NCCL location.
MPI_HOME=... Specifies which MPI implementation to use.
-kj Enables parallel build execution.

Summary

To build nccl-tests in an NVIDIA HPC SDK environment, the main requirement is to correctly define CUDA_HOME, NCCL_HOME, and MPI_HOME, and pass them to make. A notable point is that MPI_HOME should be set to the HPC-X Open MPI installation associated with NCCL. With this setup, nccl-tests can be built cleanly within the HPC SDK environment.

Showing the Model Name in ChatGPT with User-Agent Switcher and Manager

vast cow — Mon, 13 Apr 2026 10:03:22 +0000

This article explains a simple way to make the model name appear more explicitly in the ChatGPT interface by using the User-Agent Switcher and Manager Chrome extension with a custom setting for chatgpt.com.

Overview

By configuring User-Agent Switcher and Manager to send a mobile Chrome-on-iPhone user agent only for chatgpt.com, the ChatGPT site can display the model more clearly in the model selection area.

The key idea is to apply a custom user agent to a specific domain rather than changing the browser identity globally.

Configuration Used

The following JSON configuration was used in the extension:

{
  "blacklist": [],
  "custom": {
    "chatgpt.com": "Mozilla/5.0 (iPhone; CPU iPhone OS 13_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/146.0.0.0 Mobile/15E148 Safari/604.1"
  },
  "last-update": 1776073925509,
  "mode": "custom",
  "parser": {},
  "popular-browsers": [
    "Internet Explorer",
    "Safari",
    "Chrome",
    "Firefox",
    "Opera",
    "Edge",
    "Vivaldi"
  ],
  "popular-oss": [
    "Windows",
    "Mac OS",
    "Linux",
    "Chromium OS",
    "Android"
  ],
  "protected": [
    "google.com/recaptcha",
    "gstatic.com/recaptcha",
    "accounts.google.com",
    "accounts.youtube.com",
    "gitlab.com/users/sign_in",
    "challenges.cloudflare.com"
  ],
  "remote-address": "",
  "user-styling": "",
  "userAgentData": true,
  "whitelist": [],
  "json-guid": "8455108d-186e-47c2-89ec-41d7384aec1e",
  "json-forced": false
}

What This Setting Does

The important part of the configuration is this entry:

"custom": {
  "chatgpt.com": "Mozilla/5.0 (iPhone; CPU iPhone OS 13_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/146.0.0.0 Mobile/15E148 Safari/604.1"
}

This tells the extension to use a specific iPhone Chrome user agent when visiting chatgpt.com. Because the setting is domain-specific, it does not affect unrelated websites.

The extension is also set to:

"mode": "custom"

That means the browser applies the custom rules defined in the custom section.

Why the Model Name Becomes Visible

With this setup, ChatGPT may serve a different interface variant based on the browser identity it detects. In this case, the model selection area can show the model name more explicitly.

In practical terms, changing the user agent causes the site to treat the browser more like a mobile client, and that can alter how the interface presents model information.

Important Details

Site-Specific Behavior

This configuration only targets:

chatgpt.com

It does not apply the iPhone user agent to every site.

Protected Domains

The protected list includes domains such as reCAPTCHA, Google sign-in pages, and Cloudflare challenge pages. These are excluded from spoofing to avoid login or verification problems.

User-Agent Client Hints

The setting:

"userAgentData": true

indicates that user-agent-related client hint behavior is also enabled. This can matter because modern websites may use more than the classic user agent string when deciding which interface to show.

Practical Result

After applying this configuration in User-Agent Switcher and Manager, ChatGPT can be displayed in a way that makes the model shown in the model selector easier to identify.

This is a lightweight workaround for users who want clearer visibility of the active model without changing their full browsing environment.

Conclusion

Using User-Agent Switcher and Manager with a custom entry for chatgpt.com is a simple method for changing how ChatGPT presents its interface. With the iPhone Chrome user agent shown above, the model name can appear explicitly in the model selection area, making it easier to confirm which model is currently being used.

Interactive SLURM Job Attachment with Bash

vast cow — Mon, 13 Apr 2026 09:49:03 +0000

This script provides a streamlined method for attaching an interactive shell to a running SLURM job. It integrates several command-line tools to identify active jobs, optionally prompt the user for selection, and then attach a terminal session to the chosen job using srun.

Overview

In high-performance computing (HPC) environments managed by SLURM, users often need to inspect or interact with running jobs. This script automates that workflow by:

Verifying required dependencies
Retrieving active job IDs for the current user
Allowing interactive selection when multiple jobs exist
Launching an interactive shell inside the selected job

Dependency Checks

At the beginning, the script ensures that all required commands are available:

squeue: Queries SLURM job information
jq: Parses JSON output
fzf: Provides an interactive selection interface
srun: Attaches to or launches SLURM jobs

If any of these tools are missing, the script exits immediately with an error.

Retrieving Running Jobs

The script uses squeue with JSON output to fetch running jobs for the current user:

squeue --user "$USER" --states Running --json

This output is then processed with jq to extract job IDs. It accounts for different JSON structures (.jobs or .job_array) and filters out empty entries. The final list is sorted and deduplicated.

Handling Job Selection

The script adapts based on how many jobs are found:

No jobs: Exits with a message indicating no running jobs.
One job: Automatically selects that job.
Multiple jobs: Uses fzf to present an interactive selection menu.

If the user cancels the selection, the script exits gracefully.

Attaching to the Job

Once a job ID is determined, the script attaches an interactive shell using:

srun --jobid "$jobid" --overlap --pty /bin/bash --login -i

Key Options Explained

--jobid: Specifies the target job
--overlap: Allows the new step to share resources with the existing job
--pty: Allocates a pseudo-terminal
/bin/bash --login -i: Starts an interactive login shell

The use of exec ensures that the script is replaced by the new shell process.

Error Handling and Robustness

The script uses strict Bash settings:

set -euo pipefail

This enforces:

Immediate exit on errors (-e)
Undefined variable detection (-u)
Proper error propagation in pipelines (-o pipefail)

These safeguards improve reliability, especially in production HPC environments.

Conclusion

This script encapsulates a common operational need in SLURM-based systems: attaching to running jobs efficiently. By combining structured data parsing, interactive selection, and robust error handling, it reduces manual steps and minimizes user error in multi-job scenarios.

#!/usr/bin/env bash
set -euo pipefail

for cmd in squeue jq fzf srun column; do
  if ! command -v "$cmd" >/dev/null 2>&1; then
    echo "Error: '$cmd' not found." >&2
    exit 1
  fi
done

job_lines="$(
  squeue -u "$USER" --states Running --json \
    | jq -r '
        if .jobs then .jobs
        elif .job_array then .job_array
        else []
        end
        | map([
            (.job_id | tostring),
            (.name // "-"),
            (.partition // "-"),
            (.time_used // .run_time // "-"),
            (.nodes // .node_count // "-" | tostring),
            (.node_list // .nodelist // "-")
          ] | @tsv)
        | .[]
      '
)"

if [[ -z "$job_lines" ]]; then
  echo "No running jobs found." >&2
  exit 1
fi

job_count="$(printf '%s\n' "$job_lines" | grep -c '.')"

if (( job_count == 1 )); then
  jobid="$(printf '%s\n' "$job_lines" | cut -f1)"
else
  selected="$(
    {
      printf 'JOBID\tNAME\tPARTITION\tELAPSED\tNODES\tNODELIST\n'
      printf '%s\n' "$job_lines"
    } \
      | column -t -s $'\t' \
      | fzf \
          --prompt='Select job> ' \
          --height=50% \
          --reverse \
          --header-lines=1
  )"

  if [[ -z "${selected:-}" ]]; then
    echo "No job selected." >&2
    exit 1
  fi

  jobid="$(awk '{print $1}' <<< "$selected")"
fi

echo "Using jobid: $jobid" >&2
exec srun --jobid "$jobid" --overlap --pty /bin/bash --login -i

Enabling Persistent Systemd Journal Logging on Linux

vast cow — Mon, 13 Apr 2026 04:58:31 +0000

Systemd’s journal (journald) stores system logs, but by default, these logs may not persist across reboots. This means that troubleshooting issues from previous sessions can be difficult. Enabling persistent logging ensures that logs are retained even after a system restart.

Why Enable Persistent Logging

By default, many systems store journal logs in a temporary directory (/run/log/journal), which is cleared on reboot. Enabling persistent storage allows you to:

Access logs from previous boots
Investigate system crashes or unexpected reboots
Maintain a continuous log history for auditing and debugging

Steps to Enable Persistent Journal Storage

1. Create the Persistent Log Directory

sudo mkdir -p /var/log/journal

This directory is where systemd will store persistent journal files.

2. Apply Correct Permissions and Settings

sudo systemd-tmpfiles --create --prefix /var/log/journal

This command ensures that the directory has the proper ownership and permissions required by journald.

3. Restart the Journaling Service

sudo systemctl restart systemd-journald

Restarting the service makes the change effective immediately.

Verifying the Configuration

Check Directory Existence

ls -ld /var/log/journal

This confirms that the directory exists and has the expected permissions.

List Available Boot Logs

journalctl --list-boots

After enabling persistence and rebooting at least once, this command will show a list of previous system boots, allowing you to inspect logs from earlier sessions.

Summary

Enabling persistent journaling is a straightforward but important configuration step for maintaining system observability. Once configured, you gain access to historical logs that are essential for diagnosing issues and understanding system behavior over time.

Using Tinyproxy as a Simple Proxy

vast cow — Fri, 10 Apr 2026 07:23:26 +0000

This article focuses strictly on setting up and using Tinyproxy—a lightweight HTTP/HTTPS proxy—on Alpine Linux. The goal is to get a minimal proxy running and understand how to use it from another machine or client.

1. Installing Tinyproxy

On Alpine Linux, installation is straightforward:

apk add tinyproxy

This installs the Tinyproxy service and default configuration files.

2. Basic Configuration

The main configuration file is typically located at:

/etc/tinyproxy/tinyproxy.conf

At minimum, configure the following:

Port 8080
Listen 0.0.0.0

What these settings mean

Port 8080
Tinyproxy will listen for incoming proxy connections on port 8080.
Listen 0.0.0.0
Allows connections from any network interface (not just localhost).
This is required if you want to access the proxy from another machine.

3. Starting Tinyproxy

You have two operational modes depending on your use case.

Option A — Run in foreground (debug mode)

tinyproxy -d -c /etc/tinyproxy/tinyproxy.conf

-d: Runs in foreground (useful for debugging/logging)
-c: Specifies config file

Use this when testing or troubleshooting.

Option B — Run as a background service

rc-service tinyproxy start
rc-update add tinyproxy

Starts Tinyproxy as a daemon
Enables it to launch automatically at boot

4. Using Tinyproxy

Once running, Tinyproxy acts as a standard HTTP proxy.

Example: Using it from a client

If your Tinyproxy server is at:

172.27.59.40:8080

You can configure tools to use it as a proxy.

Using `curl`

curl -x http://172.27.59.40:8080 http://example.com

Using environment variables

export http_proxy="http://172.27.59.40:8080"
export https_proxy="http://172.27.59.40:8080"

Now most CLI tools will route traffic through Tinyproxy.

5. Example: Using Tinyproxy with SSH (via netcat)

Tinyproxy can also proxy TCP connections using the HTTP CONNECT method.

Add this to your SSH config:

Host foomachine
    HostName 1.2.3.4
    ProxyCommand nc -X connect -x 172.27.59.40:8080 %h %p

Explanation

nc -X connect → uses HTTP CONNECT proxy mode
-x 172.27.59.40:8080 → specifies the Tinyproxy server
%h %p → target host and port

Then connect normally:

ssh foomachine

The connection will be routed through Tinyproxy.

Summary

Tinyproxy provides:

A minimal, lightweight HTTP/HTTPS proxy
Simple configuration (port + listen address)
Flexible usage:
- CLI tools (curl, env vars)
- SSH tunneling via nc
- General proxy routing

For most use cases, the minimal configuration shown above is sufficient to get a working proxy quickly.

How to Automatically Re-Enable Low Power Mode on iPhone

vast cow — Sun, 29 Mar 2026 07:54:15 +0000

And Add a Shortcut to Toggle the Automation On and Off

Low Power Mode on iPhone is useful, but in some cases it can turn itself off automatically.
When that happens, turning it back on manually every time gets old fast.

A practical solution is to combine:

an automation that turns Low Power Mode back on whenever it gets turned off
a separate Shortcut that lets you enable or disable that behavior whenever you want

In this setup, a hidden file stored in On My iPhone is used as a flag to determine whether automatic re-enabling should run. The toggle Shortcut switches between .lowpowermode-enabled and .lowpowermode-disabled, and also turns Low Power Mode itself on or off at the same time.
The re-enable Shortcut checks for .lowpowermode-enabled, and only turns Low Power Mode back on when that flag is active. It can also display a notification afterward.

What this article will build

By the end of this guide, you will have three parts working together.

1. A toggle Shortcut

This Shortcut lets you switch the behavior between:

enabled
disabled

Internally, it does that by renaming a flag file stored in On My iPhone.
When enabled, the file is .lowpowermode-enabled.
When disabled, the file is .lowpowermode-disabled.

2. A re-enable Shortcut

This Shortcut is triggered by automation when Low Power Mode turns off.
It checks whether the enabled flag is present, and if so, it turns Low Power Mode back on.

3. A personal automation

This automation runs when Low Power Mode is turned off and launches the re-enable Shortcut.

How the system works

The logic is straightforward.

A toggle Shortcut changes whether the feature is enabled or disabled.
That state is stored using a flag file name.
Low Power Mode turns off.
A personal automation runs.
The re-enable Shortcut checks the flag.
If enabled, it turns Low Power Mode back on.

The key idea is that the automation itself remains in place all the time.
Whether it actually re-enables Low Power Mode is controlled by the flag file.

That is much easier to manage than editing the automation every time you want to pause or resume the behavior.

Preparation

Before building the Shortcuts, create the flag file structure.

Storage location

This setup uses On My iPhone as the storage location.
The uploaded Shortcut definitions also point to local storage under that location.

Files used as flags

Create one of these files to start with:

.lowpowermode-enabled
.lowpowermode-disabled

If you want the auto-re-enable behavior to start in the active state, create .lowpowermode-enabled first.

Important note

The file names need to match exactly.
If the names are off by even one character, the logic will fail.

Part 1: Build the toggle Shortcut

Start by creating the Shortcut that enables or disables the entire behavior.

What this Shortcut does

Based on the uploaded Shortcut definition, the flow works like this:

Try to get .lowpowermode-enabled
If that file is returned, rename it to .lowpowermode-disabled
Turn Low Power Mode off
Otherwise, get .lowpowermode-disabled
Rename it to .lowpowermode-enabled
Turn Low Power Mode on

So this Shortcut handles two things at once:

switching the flag state
switching Low Power Mode itself

How to create it

1. Create a new Shortcut

Open the Shortcuts app and create a new Shortcut.

A few good names:

Low Power Mode Auto Toggle
Toggle Low Power Mode Auto Restore

2. Add “Get File from Folder”

Add Get File from Folder as the first action.

Configure it like this:

Location: On My iPhone
File path: .lowpowermode-enabled
Error if not found: Off

3. Add an “If” action

Set the condition to:

If File has any value

This checks whether .lowpowermode-enabled was successfully returned.

4. In the “If” branch

Add these actions:

Rename File .lowpowermode-enabled → .lowpowermode-disabled
Set Low Power Mode Off

This means the feature is currently enabled, so the Shortcut disables it.

5. In the “Otherwise” branch

Add these actions:

Get File from Folder .lowpowermode-disabled
Rename File .lowpowermode-disabled → .lowpowermode-enabled
Set Low Power Mode On

This means the feature is currently disabled, so the Shortcut enables it.

Result

Once finished, this Shortcut becomes a single tap toggle for the whole system:

enabled → disabled
disabled → enabled

It also keeps the actual Low Power Mode state synchronized with the flag state.

Part 2: Build the re-enable Shortcut

Now create the Shortcut that turns Low Power Mode back on when needed.

What this Shortcut does

According to the uploaded definition, its logic is:

get .lowpowermode-enabled
check it with an If condition
if the file has a value, turn Low Power Mode on
show a notification saying: “Turned Low Power Mode back on”

How to create it

1. Create a new Shortcut

Create another Shortcut in the Shortcuts app.

Suggested names:

Re-enable Low Power Mode
Restore Low Power Mode

2. Add “Get File from Folder”

Add Get File from Folder.

Configure it like this:

Location: On My iPhone
File path: .lowpowermode-enabled

3. Add an “If” action

Use this condition:

If File has any value

This means the rest of the Shortcut only runs if the enabled flag is present.

4. In the “If” branch

Add these actions:

Set Low Power Mode On
Show Notification Title: Turned Low Power Mode back on

That matches the uploaded Shortcut behavior.

Part 3: Create the personal automation

With both Shortcuts ready, the last step is connecting the re-enable Shortcut to a personal automation.

Steps

1. Open the Automation tab

In the Shortcuts app, go to Automation.

2. Create a new personal automation

Tap Create Personal Automation.

3. Choose “Low Power Mode” as the trigger

From the available triggers, select Low Power Mode.

4. Set the trigger to “Is Turned Off”

This is the critical setting.
You want the automation to run when Low Power Mode is turned off.

5. Add “Run Shortcut”

For the action, choose Run Shortcut and select your re-enable Shortcut, such as:

Re-enable Low Power Mode

6. Turn off confirmation prompts

Adjust these settings as needed:

turn off Ask Before Running
optionally adjust Notify When Run

Now, whenever Low Power Mode turns off, the automation runs the re-enable Shortcut automatically.

How to use it

Daily use is simple.

When you want auto re-enable active

Run the toggle Shortcut once.

That changes:

.lowpowermode-disabled → .lowpowermode-enabled
Low Power Mode → On

When you want to pause the behavior

Run the same toggle Shortcut again.

That changes:

.lowpowermode-enabled → .lowpowermode-disabled
Low Power Mode → Off

So in practice, one Shortcut controls the entire system.

Why this setup is useful

You do not need to edit the automation every time

The automation can stay in place permanently.
You only change the flag state through the toggle Shortcut.

The state is easy to understand

The file name tells you exactly what mode the system is in:

.lowpowermode-enabled = active
.lowpowermode-disabled = inactive

It is easy to extend

Because the system is flag-based, it is also easy to expand later.
For example, you could:

change the notification text
add logging
allow auto re-enable only during certain hours
disable it while a Focus mode is active

Things to watch out for

Keep the file location consistent

Both the toggle Shortcut and the re-enable Shortcut need to read from the same place.
If one points to a different folder, the system will break.

File names must be exact

Use these names exactly:

.lowpowermode-enabled
.lowpowermode-disabled

Notifications may appear often

The re-enable Shortcut includes a notification action.
If Low Power Mode is turned off frequently, you may see that alert more often than you want.

Conclusion

This approach gives you a clean way to make iPhone automatically turn Low Power Mode back on, while still keeping the behavior easy to control.

The core idea is simple:

use Get File from Folder to read a flag file
use If File has any value to determine whether the feature is enabled
use one Shortcut to toggle the flag state
use another Shortcut to restore Low Power Mode when the automation fires

The toggle Shortcut handles both renaming the flag file and switching Low Power Mode itself, while the re-enable Shortcut checks the enabled flag and only restores the setting when appropriate.

That makes this more practical than a basic always-on automation.
It gives you automatic recovery and manual control.

If You Have Multiple Tailscale Machines Behind the Same NAT, Change the `tailscaled` Port

vast cow — Wed, 11 Mar 2026 09:57:10 +0000

When you run multiple Tailscale nodes at the same site, you may notice that only one machine establishes a direct connection while the others fall back to using a relay.

In environments where several hosts sit behind the same NAT, using the same tailscaled UDP port on every machine can make direct connectivity less reliable. In that case, assigning a different port to each machine is a practical fix.

The Problem

By default, tailscaled uses the same UDP port on every host.

That is usually fine for a single machine. But when you have multiple machines in the same location, all sharing the same public IP address, NAT port mappings can become awkward. As a result, one machine may keep a clean direct path while the others end up using a relay path instead.

This is not always catastrophic, but it is suboptimal. Relay traffic generally adds latency and makes the connection path less direct than it needs to be.

The Fix

A simple approach is to give each machine its own tailscaled port.

On Linux systems managed by systemd, edit:

/etc/default/tailscaled

Set a different port on each host.

For example, on one machine:

PORT=41641

On another:

PORT=41642

And on a third:

PORT=41643

Then restart the service:

sudo systemctl restart tailscaled

Why This Helps

When each machine uses a distinct UDP port, NAT mappings are less likely to collide or behave in a way that prevents stable direct paths. That improves the chances that each node can establish direct peer-to-peer connectivity instead of falling back to relay.

Things to Keep in Mind

Make sure the chosen ports do not overlap across machines at the same site.

Also confirm that local firewall rules or upstream network policies allow the UDP ports you assign.

After restarting tailscaled, verify the result with your usual Tailscale checks, such as connection status or ping tests, to confirm that nodes are using direct paths where expected.

Summary

If you have multiple Tailscale machines behind the same NAT, leaving them all on the same tailscaled port can lead to a situation where only one host gets a direct path and the rest use relay.

A straightforward remedy is:

Edit /etc/default/tailscaled
Assign a unique port per machine
Restart the service

sudo systemctl restart tailscaled

It is a small change, but in multi-node same-site deployments, it can make direct connectivity much more consistent.

Which NVIDIA HPC SDK Versions Bundle (or Don’t Bundle) CUDA 12 and CUDA 13

vast cow — Tue, 24 Feb 2026 07:36:07 +0000

Goal / Interpretation of “latest”	Latest HPC SDK version that matches	Bundled CUDA toolchains (as stated in the sources)	Notes / Boundary
*Latest NVHPC that does not* bundle CUDA 13.0**	25.7	CUDA 11.8 + CUDA 12.9U1	CUDA 13.0 bundling starts at 25.9
First NVHPC that bundles CUDA 13.0	25.9	CUDA 13.0 + CUDA 12.9U1	Marks the transition to CUDA 13.0 in the bundle
*Latest NVHPC that does not* bundle CUDA 12** (i.e., last pre-CUDA-12 era)	22.11	CUDA 10.2 / 11.0 / 11.8	CUDA 12 bundling begins at 23.1
First NVHPC that bundles CUDA 12	23.1	CUDA 12.0 (bundled/support introduced)	From here onward, the “no CUDA 12 bundled” condition is not met

Forem: vast cow

Understanding `$@`, `$*`, `"$@"`, and `"$*"` in Shell Scripts

Positional Parameters: A Quick Refresher

Summary Table

$@ and $* (Unquoted)

Behavior

Problem

"$@": The Safe Default

Behavior

Example

Key Properties

"$*": Single String Expansion

Behavior

Example

Caveats

Visual Comparison

Common Pitfall

❌ Incorrect

✅ Correct

Practical Guidelines

Why This Difference Exists

Conclusion

My Favorite rclone mount Settings

Example Configuration

Purpose of This Setup

What Each Option Does

--vfs-cache-mode full

--vfs-write-back 0s

--dir-cache-time 1s

--attr-timeout 1s

--poll-interval 0

--vfs-read-ahead 1M

Why This Setup Is Useful

Conclusion

Running a non-root Samba server on Singularity (Apptainer) using a non-privileged port and sharing `$HOME`

Design Principles

1. Build the Container Image

Definition file (samba.def)

Build

2. Prepare Host Directories

3. Create smb.conf

4. Bind Mount Setup

5. Set Samba Password (with fakeroot)

6. Run the Server (Important Fixes Applied)

Prepare log directory bind

Run

7. Verify

Common Pitfalls and Fixes

1. Read-only /var/log/samba

2. Missing /run/samba/ncalrpc

3. Invalid -S option

4. Privileged ports not allowed

Summary

Key Takeaways

Conceptual Note

Running `sshd` in Rootless Mode

Overview

Directory and Variable Setup

Generating the Host Key

Creating the sshd Configuration

Key Settings

Port and Listen Address

Authentication

Host Key and PID File

Restrictions

SFTP Support

Validating the Configuration

Starting the SSH Server

What This Does

How to Use It

Benefits of This Approach

Conclusion

Scripts

How to Build NCCL Tests in an NVIDIA HPC SDK Environment

Overview

Meaning of Each Environment Variable

CUDA_HOME

NCCL_HOME

MPI_HOME

Build Command

Understanding `$@`, `$`, `"$@"`, and `"$"` in Shell Scripts

`$@` and `$*` (Unquoted)

`"$@"`: The Safe Default

`"$*"`: Single String Expansion

`--vfs-cache-mode full`

`--vfs-write-back 0s`

`--dir-cache-time 1s`

`--attr-timeout 1s`

`--poll-interval 0`

`--vfs-read-ahead 1M`

Definition file (`samba.def`)

3. Create `smb.conf`

1. Read-only `/var/log/samba`

2. Missing `/run/samba/ncalrpc`

3. Invalid `-S` option

Creating the `sshd` Configuration

`CUDA_HOME`

`NCCL_HOME`

`MPI_HOME`

Using `curl`