kubectl-slice
kubectl-slice copied to clipboard
Windows - Can't pipe into slice
What did you do?
On Windows, when I run the following command:
helm template --debug . | kubectl slice -o generated
What did you expect to see?
I expect the flat rendered template to be piped into the slice command. I would see a directory labeled generated
with the individual files
What did you see instead?
I get this error:
error: validation failed: unable to open file "/dev/stdin": open C:\dev\stdin: The system cannot find the path specified.
Error: exit status 1
Hey @kennedy!
Appreciate the issue! Would you mind providing more information around your setup?
Are you using cygwin, bash on windows or some other sort of terminal emulation? I've never worked with PowerShell but I'm not sure if piping would work there (based on a quick Google search it seems it would!)
Funny enough, I do develop on Windows, but either via WSL or a remote Linux machine. I'll do some testing later today!
Hello @patrickdappollonio! nice to meet you, thank you for following up.
My set up is Win11 Pro x64. My helm/kube session is not behind WSL, but in native PowerShell Core 7.2.2 (installed from Windows App Store).
I installed:
-
kubernetes-cli
from chocolatey -
krew
from Scoop.sh -
slice
by following the instructions from this repo's README.
The command helm template --debug . | kubectl slice -o generated
was tested on my macOS workstation and was able to pipe into slice
correctly.
I did some digging and someone made a ticket in the golang/os
package commenting on piping on windows https://github.com/golang/go/issues/13697. Even though the maintainers were unable to recreate it, i thought it would be related.
$ kubectl version --client
Client Version:
Major:"1",
Minor:"23",
GitVersion:"v1.23.5",
GitCommit:"c285e781331a3785a7f436042c65c5641ce8a9e9",
GitTreeState:"clean",
BuildDate:"2022-03-16T15:58:47Z",
GoVersion:"go1.17.8",
Compiler:"gc",
Platform:"windows/amd64"
$ krew version 0.4.3
$ kubectl slice --version
kubectl-slice version 1.2.1
Name Value
---- -----
PSVersion 7.2.2
PSEdition Core
GitCommitId 7.2.2
OS Microsoft Windows 10.0.22000
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Nice to meet you too! Let me review all of this and I'll get back to you. I want to try a few things too.
I wonder if https://github.com/patrickdappollonio/tgen has the same issue... Probably!
Apologies for the early close. I submitted a patch that should take care of it. I did a quick test on Windows using the tools you mentioned for installation (chocolatey and scoop) and it seems to be working correctly. Plus I learned something new 😜 on Windows, it seems that stdin
is still mapped to a name of /dev/stdin
, but you're expected to use the pointer, not the actual file.
Before, I was grabbing the file's name and opening it as such. Now if it is stdin
, we just point to the pointer of the file instead of trying to open it like any other file.
I'll keep this open so you can give it a shot! Please keep me posted 😄 The new version is published under v1.2.2
.
My test on PowerShell:
PS X:\slice> type .\test1.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-ingress
---
apiVersion: v1
kind: Namespace
metadata:
name: production
And slicing...
PS X:\slice> .\kubectl-slice.exe --input-file .\test1.yaml --stdout
# File: pod-nginx-ingress.yaml (58 bytes)
apiVersion: v1
kind: Pod
metadata:
name: nginx-ingress
---
# File: namespace-production.yaml (61 bytes)
apiVersion: v1
kind: Namespace
metadata:
name: production
2 files parsed to stdout.
@patrickdappollonio Im glad you were able to learn something from this 😄
Unfortunately it seems like its not working still for me.
$ kubectl slice --version
kubectl-slice version 1.2.2
$ helm template --debug . ; kubectl slice -o generated
...
error: validation failed: unable to open file "C:\\dev\\stdin": open C:\dev\stdin: The system cannot find the path specified.
Error: exit status 1
Hey @kennedy I'm so sorry for the delay, life happens and I was away from Github only merging automated PRs. I took some time today to look into this and found a faster way to test your situation and why we ended up there.
The latest release, v1.2.3
should have fixed your issue. Please test it whenever you can and let me know!
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.