DEV Community: vast cow

Preventing ` ` from Entering Codex Prompts

vast cow — Mon, 20 Apr 2026 11:57:47 +0000

When using Codex, unwanted line breaks can sometimes appear in the prompt field. This can make prompts harder to read, edit, and send in a clean format. This script is designed to prevent that problem in ChatGPT Codex Cloud.

What This Script Does

This UserScript watches the prompt input area in Codex Cloud and automatically removes newline characters that appear in the text.

More specifically, it monitors the #prompt-textarea element and cleans up line breaks found in its direct paragraph elements. As a result, prompts stay in a single-line format instead of being split across multiple lines unexpectedly.

The script also tries to preserve the caret position after cleaning the text. This helps keep typing smooth and reduces disruption while editing.

Why Use It

The main purpose of this script is to make prompt entry more stable and easier to manage.

It can be useful when you want to:

avoid accidental line breaks in prompts
keep prompts in a clean, single-line format
reduce editing issues caused by unexpected newlines

From a user perspective, it works as a simple helper that automatically removes unwanted line breaks while you type.

How to Use It

Add It as a UserScript

This code is meant to be used as a UserScript. In practice, that means installing a browser extension that supports UserScripts and then adding this script to it.

Once it is installed, the script runs automatically on the matching Codex Cloud pages.

Supported Pages

The script is set to run on these URLs:

https://chatgpt.com/codex/cloud
https://chatgpt.com/codex/cloud/*

When you open one of these pages, the script starts working automatically.

How It Works in Practice

After the page loads, the script waits for the prompt editor to appear. Once the editor is available, it starts listening for input changes.

Each time you type, the script checks whether newline characters have appeared in the prompt. If they have, it removes them and then restores the caret as naturally as possible.

Things to Keep in Mind

It Is Best for Single-Line Prompts

Because this script removes line breaks, it is best suited for workflows where prompts are meant to stay on one line. It is not a good fit if you intentionally want to write multi-line prompts.

It Helps Keep Input Clean

This script is especially useful for people who want a simpler, cleaner prompt field and do not want formatting problems caused by unexpected newlines.

Conclusion

This UserScript is a simple way to prevent unwanted newlines in Codex Cloud prompts. It watches the input field, removes line breaks automatically, and keeps the caret position as stable as possible.

You do not need to understand the internal implementation in detail to use it. In practical terms, it is a lightweight tool for keeping Codex prompts clean and easy to edit.

// ==UserScript==
// @name         ChatGPT Codex Cloud - Remove Newlines in Prompt
// @namespace    https://chatgpt.com/
// @version      1.1.0
// @description  Remove CR/LF from direct <p> children on paste event.
// @match        https://chatgpt.com/codex/cloud
// @match        https://chatgpt.com/codex/cloud/*
// @grant        none
// ==/UserScript==

(() => {
  "use strict";

  let observerA = null; // waits for #prompt-textarea to appear
  let observerB = null; // waits for #prompt-textarea to be removed
  let currentEditor = null;
  let pasteHandler = null;

  function log(...args) {
    console.log("[prompt-textarea-debug]", ...args);
  }

  function sanitizeParagraphs() {
    const editor = document.querySelector("#prompt-textarea");
    if (!editor) {
      log("sanitizeParagraphs(): editor not found");
      return;
    }

    const paragraphs = document.querySelectorAll("#prompt-textarea > p");

    log("sanitizeParagraphs()", {
      paragraphCount: paragraphs.length,
    });

    paragraphs.forEach((p, index) => {
      const before = p.innerHTML;
      const after = before.replaceAll("\r", "").replaceAll("\n", "");

      if (before !== after) {
        log(`paragraph ${index} changed`, { before, after });
        p.innerHTML = after;
      } else {
        log(`paragraph ${index} unchanged`);
      }
    });
  }

  function attachToEditor(editor) {
    log("attachToEditor()", editor);

    currentEditor = editor;

    pasteHandler = (e) => {
      log("paste event fired");

      // paste後にDOMが更新されてから処理
      setTimeout(() => {
        sanitizeParagraphs();
      }, 0);
    };

    editor.addEventListener("paste", pasteHandler);
    log("paste listener attached");

    if (observerA) {
      observerA.disconnect();
      observerA = null;
    }

    observerB = new MutationObserver(() => {
      const stillThere = document.querySelector("#prompt-textarea");

      if (!stillThere) {
        log("#prompt-textarea removed");

        if (currentEditor && pasteHandler) {
          currentEditor.removeEventListener("paste", pasteHandler);
          log("paste listener removed");
        }

        currentEditor = null;
        pasteHandler = null;

        observerB.disconnect();
        observerB = null;

        waitForEditor();
      }
    });

    observerB.observe(document.documentElement, {
      childList: true,
      subtree: true,
    });

    log("observerB started");
  }

  function waitForEditor() {
    log("waitForEditor()");

    const editor = document.querySelector("#prompt-textarea");
    if (editor) {
      attachToEditor(editor);
      return;
    }

    observerA = new MutationObserver(() => {
      const found = document.querySelector("#prompt-textarea");

      if (found) {
        log("#prompt-textarea appeared");
        attachToEditor(found);
      }
    });

    observerA.observe(document.documentElement, {
      childList: true,
      subtree: true,
    });

    log("observerA started");
  }

  log("userscript initialized", { href: location.href });
  waitForEditor();
})();

White Background Color Scheme for Windows Terminal

vast cow — Mon, 20 Apr 2026 09:22:01 +0000

Overview

Windows Terminal allows you to customize its appearance through color schemes, improving both readability and overall usability. This article introduces a simple white background color scheme and explains its purpose and how to apply it.

This scheme uses a light background combined with muted text colors, making it suitable for extended use without excessive eye strain.

Purpose of the Color Scheme

A white background color scheme offers several practical advantages:

Improved readability: Dark text stands out clearly against a white background
Visual consistency: Aligns well with common applications like editors and web browsers
Reduced eye fatigue: Less harsh than dark themes in bright environments

It is particularly effective for daytime use or well-lit workspaces.

Key Configuration Points

The provided configuration defines a balanced and minimal color palette:

Background (background): #FFFFFF (white)
Foreground (foreground): #0C0C0C (near-black)
Cursor (cursorColor): Dark color for clear visibility
Selection (selectionBackground): Dark highlight for contrast

Standard terminal colors (red, blue, green, etc.) and their bright variants are also included, ensuring proper color distinction in command outputs.

How to Apply

1. Open the Settings File

Launch Windows Terminal and open the Settings. Edit the configuration file in JSON format.

2. Add the Color Scheme

Insert the following into the "schemes" array:

"schemes": [
    {
        "name": "Theme Name",
        "background": "#FFFFFF",
        "foreground": "#0C0C0C"
        ...
    }
]

If a "schemes" section already exists, simply add this entry to the list.

3. Apply to a Profile

Assign the scheme to a profile (e.g., PowerShell or Command Prompt):

"colorScheme": "Theme Name"

This activates the color scheme for that profile.

Notes

In dark environments, a white background may feel too bright
Some tools rely on specific color assumptions, which may affect visibility

You can fine-tune individual colors as needed to better match your preferences.

Summary

This white background color scheme provides a clean and readable interface for Windows Terminal. It is easy to implement and well-suited for everyday use, especially in bright environments. Adjust it as necessary to create a comfortable and efficient working setup.

{
    "$help": "https://aka.ms/terminal-documentation",
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "schemes": 
    [
        {
            "background": "#FFFFFF",
            "black": "#0C0C0C",
            "blue": "#0037DA",
            "brightBlack": "#767676",
            "brightBlue": "#3B78FF",
            "brightCyan": "#61D6D6",
            "brightGreen": "#16C60C",
            "brightPurple": "#B4009E",
            "brightRed": "#E74856",
            "brightWhite": "#F2F2F2",
            "brightYellow": "#C19C00",
            "cursorColor": "#0C0C0C",
            "cyan": "#3A96DD",
            "foreground": "#0C0C0C",
            "green": "#13A10E",
            "name": "My Light Theme",
            "purple": "#881798",
            "red": "#C50F1F",
            "selectionBackground": "#0C0C0C",
            "white": "#CCCCCC",
            "yellow": "#856B00"
        }
    ]
}

Make PowerShell Readable on a White Windows Terminal Background

vast cow — Mon, 20 Apr 2026 09:16:08 +0000

When you switch Windows Terminal to a light or white background, the default PowerShell token colors can become hard to read. You can fix this by customizing PSReadLine’s color scheme so that prompts, selections, and syntax tokens use higher-contrast tones.

Below is a minimal configuration that keeps most text at the terminal’s default foreground color, uses a dim gray for numbers, and highlights selections in an inverted style. It also gives commands a warm accent for visibility.

# Run in PowerShell (requires PSReadLine)
Import-Module PSReadLine
Set-PSReadLineOption -Colors @{
    ContinuationPrompt = "$([char]0x1b)[39m"      # default foreground
    Default            = "$([char]0x1b)[39m"      # plain text
    Type               = "$([char]0x1b)[39m"      # type names
    Selection          = "$([char]0x1b)[39;49;7m" # inverse (swap fg/bg)
    Command            = "$([char]0x1b)[33m"      # yellow for commands
    Member             = "$([char]0x1b)[39m"      # .member names
    Number             = "$([char]0x1b)[38;5;242m"# ANSI 256-color gray
}

Why these choices?

[39m] default foreground: Lets Windows Terminal’s color scheme control the actual text color, so it stays readable whether the background is light or dark.
[33m] yellow for commands: A standard, high-contrast accent that stands out on white without being harsh.
[38;5;242m] gray for numbers: Uses the 256-color palette to render numbers in a softer gray that remains legible on light backgrounds.
[7m] inverse for selections: Inverts foreground/background so selections “pop” regardless of theme.

How to apply permanently

Open your PowerShell profile:

   notepad $PROFILE

Paste the Set-PSReadLineOption -Colors block into the profile file and save.
Restart the terminal (or run the block once) to apply.

That’s it—now your PowerShell prompt and syntax colors stay crisp and readable even with a white Windows Terminal theme.

A Tampermonkey Script That Adds a Model Settings Button to ChatGPT

vast cow — Mon, 20 Apr 2026 08:06:24 +0000

This Tampermonkey script is a simple way to make ChatGPT easier to use by adding a Config button to the page. With that button, you can open the model settings screen more quickly without going through the usual steps in the interface.

Purpose

The main purpose of this script is to improve convenience. If you often open the model settings in ChatGPT, repeating the same clicks can become tedious. This script shortens that process by placing a dedicated button in the page header.

Instead of searching through the interface each time, you can use a single visible entry point. This makes the settings screen easier to access during regular use.

How It Works

The script runs on https://chatgpt.com/* and waits for the page header to become available. Once the correct part of the header appears, it inserts a new Config button there.

When you click that button, the script uses the existing elements already present in ChatGPT’s interface. It first activates the model switcher button, then attempts to open the configuration modal. In other words, it does not create a new settings system of its own. It simply provides a faster way to reach the one already built into ChatGPT.

How to Use It

Install the script in Tampermonkey

First, make sure Tampermonkey is installed in your browser. Then create a new user script, paste the provided code into it, and save it.

Open ChatGPT

Go to ChatGPT in your browser. The script will automatically run on matching pages.

Click the Config button

After the page loads, a Config button should appear in the header area. Clicking it will trigger the actions needed to open the model settings screen.

Why It Is Useful

This script is useful because it reduces friction in everyday use. For people who frequently adjust model-related settings, even a small shortcut can make the interface feel smoother and more efficient.

It also includes a waiting mechanism so it does not try to add the button before the necessary page elements are ready. That helps it work more reliably on pages that load dynamically.

Things to Keep in Mind

This script depends on ChatGPT’s current page structure and element names. If the site layout or internal identifiers change, the script may stop working correctly or may need to be updated.

It is also important to remember that this is a browser-side customization, not an official ChatGPT feature. Its behavior may vary depending on browser setup or future changes to the site.

Conclusion

This Tampermonkey script is a practical customization for users who want quicker access to ChatGPT’s model settings screen. By adding a simple Config button to the header, it makes a common action faster and more direct.

It is a small change, but one that can improve the overall experience for people who use ChatGPT regularly.

// ==UserScript==
// @name         Add Config Button With page-header Reattach Detection
// @namespace    http://tampermonkey.net/
// @version      1.2
// @description  Wait for #page-header, add Config button, and re-add it when #page-header is recreated
// @match        https://chatgpt.com/*
// @grant        none
// ==/UserScript==

(function () {
  'use strict';

  const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

  const BUTTON_ID = 'tm-config-button';
  let headerRemovalObserver = null;
  let isRunning = false;

  async function waitForPageHeader(timeoutMs = 30000, intervalMs = 100) {
    const start = Date.now();

    while (Date.now() - start < timeoutMs) {
      const pageHeader = document.querySelector('#page-header');
      if (pageHeader) {
        return pageHeader;
      }
      await sleep(intervalMs);
    }

    throw new Error('Timeout: #page-header was not found.');
  }

  function findButtonContainer(pageHeader) {
    return pageHeader.childNodes[1] || null;
  }

  async function onConfigClick(e) {
    console.log('Config button clicked', e);

    const switcherButton = document.querySelector('button[data-testid="model-switcher-dropdown-button"]');
    if (!switcherButton) {
      console.warn('model-switcher-dropdown-button not found');
      return;
    }

    switcherButton.click();

    await sleep(0);

    const configureModal = document.querySelector('div[data-testid="model-configure-modal"]');
    if (!configureModal) {
      console.warn('model-configure-modal not found');
      return;
    }

    configureModal.click();
  }

  function createConfigButton() {
    const button = document.createElement('button');
    button.id = BUTTON_ID;
    button.innerText = 'Config';
    button.className =
      'group flex cursor-pointer justify-center items-center gap-1 rounded-lg min-h-9 touch:min-h-10 px-2.5 text-lg hover:bg-token-surface-hover focus-visible:bg-token-surface-hover font-normal whitespace-nowrap focus-visible:outline-none';
    button.addEventListener('click', onConfigClick);
    return button;
  }

  function addConfigButton(pageHeader) {
    const target = findButtonContainer(pageHeader);
    if (!target) {
      console.warn('#page-header.childNodes[1] not found');
      return false;
    }

    if (target.querySelector(`#${BUTTON_ID}`)) {
      return true;
    }

    const configButton = createConfigButton();
    target.appendChild(configButton);
    console.log('Config button added');

    return true;
  }

  function observePageHeaderRemoval(pageHeader) {
    if (headerRemovalObserver) {
      headerRemovalObserver.disconnect();
      headerRemovalObserver = null;
    }

    headerRemovalObserver = new MutationObserver(() => {
      if (!document.contains(pageHeader)) {
        console.log('#page-header was removed. Restarting...');
        headerRemovalObserver.disconnect();
        headerRemovalObserver = null;
        run();
      }
    });

    const root = document.body || document.documentElement;
    headerRemovalObserver.observe(root, {
      childList: true,
      subtree: true,
    });
  }

  async function run() {
    if (isRunning) return;
    isRunning = true;

    try {
      // (0) Wait for #page-header
      const pageHeader = await waitForPageHeader();

      // (1) Add config button
      const added = addConfigButton(pageHeader);
      if (!added) {
        isRunning = false;
        await sleep(300);
        run();
        return;
      }

      // (2) Observe removal of #page-header
      // (3) If removed, restart from (1)
      observePageHeaderRemoval(pageHeader);
    } catch (err) {
      console.error(err);
    } finally {
      isRunning = false;
    }
  }

  run();
})();

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.

DEV Community: vast cow

Preventing ` ` from Entering Codex Prompts

What This Script Does

Why Use It

How to Use It

Add It as a UserScript

Supported Pages

How It Works in Practice

Things to Keep in Mind

It Is Best for Single-Line Prompts

It Helps Keep Input Clean

Conclusion

White Background Color Scheme for Windows Terminal

Overview

Purpose of the Color Scheme

Key Configuration Points

How to Apply

1. Open the Settings File

2. Add the Color Scheme

3. Apply to a Profile

Notes

Summary

Make PowerShell Readable on a White Windows Terminal Background

Why these choices?

How to apply permanently

A Tampermonkey Script That Adds a Model Settings Button to ChatGPT

Purpose

How It Works

How to Use It

Install the script in Tampermonkey

Open ChatGPT

Click the Config button

Why It Is Useful

Things to Keep in Mind

Conclusion

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

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`