bug: stdin read error message uses wrong name

Created originally in Butane by @deepak0x: https://github.com/coreos/butane/issues/726

---

name

Bug report

about

io.ReadAll error message uses infile.Name() instead of the filename variable

title

stdin read error message uses wrong name

labels

kind/bug

warning

No response

---

Bug Description

In internal/main.go, when io.ReadAll fails on line 127, the error message is formatted using infile.Name():

// internal/main.go, line 127 (commit cb34e120)
fail("failed to read %s: %v\n", infile.Name(), err)

https://github.com/coreos/butane/blob/cb34e120e5267bfd5bdfa83fa8c2e44e06dedda2/internal/main.go#L127

When no --input flag is given, infile is assigned os.Stdin (line 113). os.Stdin.Name() returns "/dev/stdin" on Linux. However, the filename variable is set to "<stdin>" (line 114) for exactly this case, and updated to the real path only when --input is provided (line 122):

infile := os.Stdin
filename := "<stdin>"
if input != "" {
    var err error
    infile, err = os.Open(input)
    if err != nil {
        fail("failed to open %s: %v\n", input, err)
    }
    defer infile.Close()
    filename = input
}

The error on line 119 and the TranslateBytes call on line 132 both use filename or input directly. Line 127 is the only site that diverges by calling infile.Name().

Current behavior

When io.ReadAll fails reading from stdin, the error reads:

failed to read /dev/stdin: <error>

Expected behavior

The error should use the same friendly identifier used everywhere else in the function:

failed to read <stdin>: <error>

Evidence

os.Stdin.Name() returns "/dev/stdin" on Linux (this is the value returned by the underlying file descriptor's name, not the user-facing label). The filename variable was explicitly initialized to "<stdin>" to present a human-readable name in messages, as is already done for the TranslateBytes report path on line 132.

Release checklist

No response

Tagging

No response

Fedora packaging

No response

GitHub release

No response

Quay release

No response

Start in internal/main.go around lines 113-132 and compare the stdin setup with the error handling for reading and translation. Verify that a failed stdin read reports the friendly identifier while an explicit input path continues to report its real filename.