🟡 medium - bug
File: cmd/root/api.go (line 108)
Code
// Monitor stdin for EOF to detect parent process death.
// Only enabled when --exit-on-stdin-eof flag is passed.
// When spawned with piped stdio, stdin closes when the parent process dies.
if f.exitOnStdinEOF && stdin != nil {
var cancel context.CancelFunc
ctx, cancel = context.WithCancel(ctx)
defer cancel()
go monitorStdin(ctx, cancel, stdin)
}
Problem
The code sets os.Stdin = nil on line 105. However, before that, stdin := os.Stdin (line 102) copies the original os.Stdin value to a local variable. The check stdin != nil on line 110 is therefore checking the original os.Stdin, which will almost always be non-nil. This check is redundant and potentially misleading, as the os.Stdin variable itself has been nulled out at that point. The intent seems to be to check if the original stdin was valid.
Suggested Fix
The stdin != nil check is not strictly necessary as os.Stdin is almost always non-nil unless explicitly set to nil or encountering some very unusual system configuration. If the intent is to ensure stdin is a valid file, then the check is fine. However, to clarify the code, it could be removed, or a comment could be added to explain why it's there. Given that os.Stdin is a global variable, this specific line does not cause a bug but is rather a point of confusion for future maintainers.
Found by nightly codebase scan
🟡 medium - bug
File:
cmd/root/api.go(line 108)Code
Problem
The code sets
os.Stdin = nilon line 105. However, before that,stdin := os.Stdin(line 102) copies the originalos.Stdinvalue to a local variable. The checkstdin != nilon line 110 is therefore checking the originalos.Stdin, which will almost always be non-nil. This check is redundant and potentially misleading, as theos.Stdinvariable itself has been nulled out at that point. The intent seems to be to check if the original stdin was valid.Suggested Fix
The
stdin != nilcheck is not strictly necessary asos.Stdinis almost always non-nil unless explicitly set tonilor encountering some very unusual system configuration. If the intent is to ensurestdinis a valid file, then the check is fine. However, to clarify the code, it could be removed, or a comment could be added to explain why it's there. Given thatos.Stdinis a global variable, this specific line does not cause a bug but is rather a point of confusion for future maintainers.Found by nightly codebase scan