some kubectl stdOut messages are sent to stdErr

[todd-dsm]

What happened

Attempted to use GNU/Bash command substitution to assign the output of a command to a variable:

% yo="$(kubectl get pods -n kube-public)"; echo "$yo" | cat -vte
No resources found in kube-public namespace.
$

This results in the message being printed to stdErr and nothing being assigned to the variable yo.

1. the error prints to the terminal, then
2. the empty variable prints to the terminal: $

After redirecting stdErr back to stdOut the issue is resolved:

% yo="$(kubectl get pods -n kube-public 2>&1)"; echo "$yo" | cat -vte
No resources found in kube-public namespace.$

What you expected to happen:

The message to the user "No resources found in kube-public namespace." should be sent through stdOut.

How to reproduce it (as minimally and precisely as possible):

See above.

Anything else we need to know?:

For reference, even given a similar command with a resulting failure, like searching for namespace foo (and there is no namespace foo) should even be sent to stdOut (if there is a message) and accompanied by exit status:1 ; kubectl is telling the human something important.

If there is nothing to share with the user (no messages printed to the terminal) then simple exit with status:1 and move on.

For Reference:

The most programmatically friendly thing to do is:

• Send ALL kubectl messages (errors and everything) to stdOut, and
• Whenever kubectl has nothing to share with the human (rarely) THAT should exit with status:1.

Example

Given these conditions:

% cat /tmp/yo
a1 b1 c1
a2 b2 c2
a3 b3 c3

grep will indicate success with a message and exit status:

% grep b2 /tmp/yo; echo $?
a2 b2 c2    # information for user
0           # exit status: success

In this case the succeeding operation outputs a message to the user: a2 b2 c2.

% grep foo /tmp/yo; echo $?
1           # exit status: fail (no message to user)

In this case there is nothing to share with the user; the purpose of the operation failed to return anything. But, given the exit status, we can make subsequent automation decisions on the exit status - simple.

Please see excerpts from our bible, The Linux Programming Interface. While this excerpt only explains the mechanics, the grep example supports historic implementation.

I'd be interested in hearing from those with more gray hairs than me about the whys behind the historic bits.

Environment:

• Kubernetes client and server versions (use kubectl version): Client Version: v1.31.0
• Cloud provider or hardware configuration: NA
• OS (e.g: cat /etc/os-release): macOS Sonoma/14.6.1

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ardaguclu]

I think, this KEP kubernetes/enhancements#2551 will resolve the issue explained in here.

[todd-dsm]

@ardaguclu thanks for linking this up. I looked for something but couldn't find it.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten