docker: 'docker buildx build' requires 1 argument — a generated edit…

Symptom

A test script fails at its image build, right after an edit that only meant to improve the error output:

FAIL: the image build — its last lines:
ERROR: docker: 'docker buildx build' requires 1 argument

Usage:  docker buildx build [OPTIONS] PATH | URL | -

The build command looks correct, with exactly one context path. The edited line, as committed (the grep filter shortened to tail):

docker build -t "$IMAGE" --build-arg VERSION="$SDKV" "$CTX" > "$T/image-build.log" 2>&1 \n  || { echo "FAIL: the image build — its last lines:"; tail -25 "$T/image-build.log"; exit 1; }

It was meant to be two lines joined by a continuation backslash. The \n between them is two characters, a backslash and an n, not a line break.

When it happens

A script or tool writes shell code through one more layer of escaping than intended: a Python edit script fed through a heredoc, a JSON or YAML string, a template, or a code-generating model's tool call. The newline arrives as the two characters \ n. In the reference project this happened twice on a Windows machine, both times from a Python edit script run through a heredoc. Once it broke a tr call in another script, and once it broke the docker build line above.

Cause

Outside quotes, bash treats \n as an escaped n: the backslash is removed and n stays a normal word. The whole thing is still one valid command, so nothing complains about it. Here the n became another positional argument to docker build:

args build -t probe /tmp/ctx > /tmp/args.log 2>&1 \n  || { echo FAIL; }
# args seen: [build] [-t] [probe] [/tmp/ctx] [n]

docker build (buildx 0.37.2, Docker 29.8.2 in the reproduction) refuses two contexts: "requires 1 argument". A command that accepts any number of arguments may instead take the extra n quietly, as one more file name, pattern or branch.

Why it is hard to see:

• bash -n passes. The line is valid syntax (bash -n exit 0 on the broken script).
• The output was redirected into a log, so the message only appears if something prints the log.
• In a diff, \n looks like an ordinary line break in an escaped string.

Fix

Put a real line break after the continuation backslash:

docker build -t "$IMAGE" --build-arg VERSION="$SDKV" "$CTX" > "$T/image-build.log" 2>&1 \
  || { echo "FAIL: the image build — its last lines:"; tail -25 "$T/image-build.log"; exit 1; }

Then fix the tool that wrote it. For edit scripts, the rule the reference project adopted: write the edit script to a file with an editor (or a file-writing tool) instead of passing it through a heredoc. If code must build a newline or a backslash, use chr(10) and chr(92) rather than escape sequences, and check the bytes with od -c after writing.

Verify

Search for a backslash-n followed by spaces and an operator. That shape is almost never intended in a script:

git grep -nE '[^\\][\\]n[[:space:]]+([|][|]|&&)' -- '*.sh'

On the commit that introduced the reference bug this finds the line. On the fixed tree it finds nothing. Put it in CI next to bash -n, because bash -n alone doesn't catch this. od -c on the line shows \ n (two separate characters) where you meant \n (one).

Notes

• When a command fails with "wrong number of arguments" right after an edit, look at the edited line's bytes before blaming the tool or the runner. In the reference incident, a sibling commit also removed a --progress=plain flag from the same line, but the bytes on the line were what needed fixing.
• Printing the build log's last lines on failure (docker build ... > log 2>&1 || tail log) is still a good change. docker build -q had hidden a pip error there before, which is why the line was being edited in the first place.