Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows initializeCommand not using default shell #986

Open
martinbiard opened this issue Apr 7, 2024 · 1 comment
Open

Windows initializeCommand not using default shell #986

martinbiard opened this issue Apr 7, 2024 · 1 comment
Labels

Comments

@martinbiard
Copy link

martinbiard commented Apr 7, 2024

What happened?

On Windows, when using an initializeCommand, it always tries to execute by running it through sh -c ....

I wanted to use a common technique to invoke a script in a cross platform compatible way i.e. you name your scripts as follows:

myscript
myscript.cmd
myscript.ps1

Then, in devcontainer.json, you set your initializeCommand simply to myscript such that on linux shells it will execute myscript and on Windows it will execute myscript.cmd from which you can then pass onto myscript.ps1.

What did you expect to happen instead?

I expected the initializeCommand to be invoked through the OS default shell.

How can we reproduce the bug? (as minimally and precisely as possible)

My devcontainer.json:
This is the default config from microsoft/vscode-remote-try-node with only added initializeCommand at the end.

{
  "name": "Node.js",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:0-18-bullseye",
  "customizations": {
    "vscode": {
      "settings": {},
      "extensions": [
        "streetsidesoftware.code-spell-checker"
      ]
    }
  },
  "portsAttributes": {
    "3000": {
      "label": "Hello Remote World",
      "onAutoForward": "notify"
    }
  },
  "postCreateCommand": "yarn install",
  "initializeCommand": "initializeCommand" // also tested with ["initializeCommand"] array format
}

Logs:

[01:54:17] debug Acquire workspace lock...
[01:54:17] debug Acquired workspace lock...
[01:54:17] info Creating devcontainer...
[01:54:17] debug Inject and run command: 'C:\Program Files\DevPod\devpod-cli.exe' helper ssh-server --stdio --debug
[01:54:17] debug Attempting to create SSH client
[01:54:17] debug Execute command locally
[01:54:18] debug SSH client created
[01:54:18] debug SSH session created
[01:54:18] info Execute SSH server command: C:\Program Files\DevPod\devpod-cli.exe helper sh -c 'C:\Program Files\DevPod\devpod-cli.exe' agent workspace up --workspace-info 'H4sIAAAAAAAA/7RSW2vbMBT+K+M8+5KVtKV6Wkk7GnZJyJzBhqCo1omjVpaMjuxmFP/3cXJpvJG+DPZ45O8cf7cXePbhiRpV4iyYyjgQMBFSLgkDSVk/GBW0lJnGrvFaytK7iJtIUmpcqdZGKV8PbB8Zlkak4YfskbyD5PgrEC9gNAgY4CGB9q+39OLqSl9AAk3wndEYeM+pGhnlyycMkIBvovGO+NPNbPLpdnE/vy7ueOyUbf+AtoRhvjulQcTQYp/A9Ov1pJh+nxY/7ovpl9vZsuDdE9C+T6BW5do45t8nYDQOCBkX0VrzCH0C5NuwU1mZuMDGk4k+/ALB84fKxHX7kJW+FtRVqfH5wIasMpFPaOwm3kVlHIa5imsQwCGUh7d8OBwMLgMqdqMwNVJUdQMCzkZn43Q0TkeXxehcnI/F+8ufkIBVFJfE4t5C7KPeJrKNmmmpCl1kYdaXyoIAtoYT2lHk6syDr4Kq3300litxg92cm7PXWFqT4YZXtH921iu9XHwGAesYGxJ5fjQnt34VU1rv3ckDWlSElB8W826UnWdjSAA3WO4y2WVtkWg4M+E9w9cyGEdRWZawUpaQxZUtRV/zIg/WzI7VOtHWbfzH2P8psv5Uf+9m397qYPLfO/4bAAD//wEAAP//XgJE6BEEAAA=' --debug
[01:54:18] info Use C:\Users\mbiard\.devpod\agent\contexts\default\workspaces\devpod-test as workspace dir
[01:54:18] debug Created logger
[01:54:18] debug Received ping from agent
[01:54:18] debug Create content folder C:\Users\mbiard\.devpod\agent\contexts\default\workspaces\devpod-test\content
[01:54:18] debug Clone Repository
[01:54:18] info Cloning into 'C:\Users\mbiard\.devpod\agent\contexts\default\workspaces\devpod-test\content'...
[01:54:18] debug Using docker command 'docker'
[01:54:19] info Running initializeCommand from devcontainer.json: 'sh -c initializeCommand'
[01:54:19] info exec: "sh": executable file not found in %PATH%
[01:54:19] info devcontainer up
[01:54:19] info github.com/loft-sh/devpod/cmd/agent/workspace.(*UpCmd).Run
[01:54:19] info D:/a/devpod/devpod/cmd/agent/workspace/up.go:96
[01:54:19] info github.com/loft-sh/devpod/cmd/agent/workspace.NewUpCmd.func1
[01:54:19] info D:/a/devpod/devpod/cmd/agent/workspace/up.go:52
[01:54:19] info github.com/spf13/cobra.(*Command).execute
[01:54:19] info D:/a/devpod/devpod/vendor/github.com/spf13/cobra/command.go:916
[01:54:19] info github.com/spf13/cobra.(*Command).ExecuteC
[01:54:19] info D:/a/devpod/devpod/vendor/github.com/spf13/cobra/command.go:1044
[01:54:19] info github.com/spf13/cobra.(*Command).Execute
[01:54:19] info D:/a/devpod/devpod/vendor/github.com/spf13/cobra/command.go:968
[01:54:19] info github.com/loft-sh/devpod/cmd.Execute
[01:54:19] info D:/a/devpod/devpod/cmd/root.go:90
[01:54:19] info main.main
[01:54:19] info D:/a/devpod/devpod/main.go:8
[01:54:19] info runtime.main
[01:54:19] info C:/hostedtoolcache/windows/go/1.20.5/x64/src/runtime/proc.go:250
[01:54:19] info runtime.goexit
[01:54:19] info C:/hostedtoolcache/windows/go/1.20.5/x64/src/runtime/asm_amd64.s:1598
[01:54:19] info exit status 1
[01:54:19] debug Connection to SSH Server closed
[01:54:19] debug Done creating devcontainer
[01:54:19] debug Done executing ssh server helper command
[01:54:19] fatal Process exited with status 1
run agent command
github.com/loft-sh/devpod/pkg/devcontainer/sshtunnel.ExecuteCommand.func2
        D:/a/devpod/devpod/pkg/devcontainer/sshtunnel/sshtunnel.go:122
runtime.goexit
        C:/hostedtoolcache/windows/go/1.20.5/x64/src/runtime/asm_amd64.s:1598

Local Environment:

  • DevPod Version: 0.5.4
  • Operating System: windows
  • ARCH of the OS: AMD64

DevPod Provider:

  • Local/remote provider: docker

Anything else we need to know?

The only little workaround I have for now is adding C:\Program Files\Git\bin to my PATH to make sh.exe available, but Git does not add this directory to the PATH by default on Windows (it adds C:\Program Files\Git\cmd which doesn't contain sh.exe). Also, this workaround is not great because what I really want is access to powershell.

From the devcontainer documentation, you would expect that by saying clearly that it runs the initializeCommand on the host, that it would use the host's native shell. Then, if you really rather use some sh.exe, you can just call it from the native shell.

@pascalbreuninger
Copy link
Member

Hey @martinbiard, thanks for opening the issue. Seems like you've hit a blind spot of DevPod, we'll fix that

@deniseschannon deniseschannon added the bug Something isn't working label May 8, 2024 — with Linear
@deniseschannon deniseschannon removed bug Something isn't working kind/bug labels May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants