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

Calling wt from cmd for working directory "C:\" causes an error #4571

Open
Boereck opened this issue Feb 13, 2020 · 24 comments
Open

Calling wt from cmd for working directory "C:\" causes an error #4571

Boereck opened this issue Feb 13, 2020 · 24 comments
Labels
Area-Commandline wt.exe's commandline arguments Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal.
Milestone

Comments

@Boereck
Copy link

Boereck commented Feb 13, 2020

Hi,

I was testing the new command line options to open a Windows Terminal for a specified working directory. When calling wt new-tab -d "C:\" from PowerShell this seems to work. Calling the same command from cmd however will print the error message [error 0x8007010b when launching powershell.exe']` in the newly opened Windows Terminal instance. Using the "-p" option to launch a different shell will provoke the same error message for the executable associated with the specified profile name.

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.657]
Windows Terminal version: 0.9.433.0

Steps to reproduce

Call wt new-tab -d "C:\" from cmd.

Expected behavior

Open a new Windows Terminal tab with path C:\ set as the current working directory.

Actual behavior

Opens a Windows Terminal instance with the message:
[error 0x8007010b when launching `powershell.exe']

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Feb 13, 2020
@DHowett-MSFT
Copy link
Contributor

Interesting. It looks like we're not handling quotes properly when there aren't spaces.

@DHowett-MSFT DHowett-MSFT added Area-Interaction Interacting with the vintage console window (as opposed to driving via API or hooks) Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. labels Feb 13, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Feb 13, 2020
@german-one
Copy link
Contributor

german-one commented Feb 13, 2020

Unfortunately this is the default behavior if the command line gets tokenized to argv. This is unrelated to spaces in the path. The backslash just escapes the double quote and thus, it's treated as literal character. Also CommandLineToArgvW behaves the same.
You could escape the backslash with another backslash to make it work again like wt new-tab -d "C:\\".
If we want to fix that we would need to establish our own command line tokenization.

@salmanmkc

This comment was marked as off-topic.

@DHowett-MSFT

This comment was marked as off-topic.

@salmanmkc

This comment was marked as off-topic.

@german-one

This comment was marked as off-topic.

@DHowett-MSFT

This comment was marked as off-topic.

@krage
Copy link

krage commented Feb 13, 2020

Similarly I'm trying to set a context menu shortcut via registry to open terminal from a folder's background context menu. I used to do this successfully with cmder by setting the command to "c:\path\to\cmder.exe" /START "%V".

Trying this with "C:\Users\krage\AppData\Local\Microsoft\WindowsApps\wt.exe" --startingDirectory "%V" shows the same 0x8007010b error when the path is the root of a lettered drive. It seems to work for other paths though with or without contained spaces, eg. C:\Windows and C:\Program Files both succeed.

I tried changing the command to "C:\Users\krage\AppData\Local\Microsoft\WindowsApps\wt.exe" powershell.exe -NoExit -Command Set-Location -LiteralPath "%V". Using this in the root of a drive doesn't generate an error but fails to change the path, the powershell session just winds up in the default starting directory of the default terminal profile. Paths without spaces eg. C:\Windows change directory successfully. Powershell shows an error for paths with spaces eg. C:\Program Files gives an error like this as though the quotes around the path didn't survive:

Set-Location : A positional parameter cannot be found that accepts argument 'Files'.
At line:1 char:1
+ Set-Location -LiteralPath C:\Program Files
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Set-Location], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.SetLocationCommand

@DHowett-MSFT
Copy link
Contributor

As a quick hack for %V, you might be able to use.. hmm. "%V\."?

@salmanmkc
Copy link

(Actually, wsl$ is correct here. "cinnamon" and "cinnak" are not correct.)
It also looks like you don't even have a profile named Ubuntu.

Kayla's example was an example, not something that you can just run out of nowhere. You need to have a "command prompt" profile and an "ubuntu" profile, and the directories she's listed in the arguments, for it to work the same way.

You may benefit from the command line arguments documentation.

I have it working with a userprofile of Ubuntu-18.04, but what I'm wondering is what the error as described in the issue is coming from, [error 0x8007010b when launching powershell.exe']`

@DHowett-MSFT
Copy link
Contributor

You're getting that error because you have a specified a working directory (with -d) that does not exist.

@salmanmkc
Copy link

Awesome, thank you, fixed
image

@krage
Copy link

krage commented Feb 14, 2020

As a quick hack for %V, you might be able to use.. hmm. "%V\."?

Thanks, this seems this works everywhere I've tried so far.

@DHowett-MSFT DHowett-MSFT added this to the Terminal v1.0 milestone Feb 14, 2020
@DHowett-MSFT
Copy link
Contributor

Triaged this into 1.0; we should see if there's something we can do about it.

@DHowett-MSFT DHowett-MSFT added Priority-2 A description (P2) Help Wanted We encourage anyone to jump in on these. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Feb 14, 2020
@german-one
Copy link
Contributor

Triaged this into 1.0; we should see if there's something we can do about it.

I can take this and solve it along with #4170. I recall that I already have a piece of code to parse the command line somewhere in my snippet collection. Likely still in C though.

@zadjii-msft Do you think we need an alternative way to preserve literal quotes in the arguments? Or would it be OK to have them removed after tokenization? From what I see in the docs I'd guess it's save to strip them all.

@beviu
Copy link
Contributor

beviu commented Feb 27, 2020

(Sorry I deleted my comment earlier.)

I personally think that the terminal should stay consistent with other apps and use the standard CommandLineToArgvW.

Should we really fix this in the terminal? Is this not cmd.exe/Powershell's own problem? Other apps behave like this as well:

Powershell:

PS C:\Users\gregd> git "hello\" world
git: 'hello\' is not a git command. See 'git --help'.

cmd:

C:\Users\gregd>git "hello\" world
git: 'hello" world' is not a git command. See 'git --help'.

It looks like cmd.exe just passes the whole command line to the app while powershell parses the command line with its own rules and then escapes the arguments to recreate a command line. In particular, powershell doesn't care about backslashes so "C:\" is parsed as an argument with value C:\ which is then correctly escaped for CommandLineToArgvW. But cmd.exe just gives the command line as-is so "C:\" gets parsed as C:".

@ghost ghost removed the Help Wanted We encourage anyone to jump in on these. label Feb 28, 2020
@german-one
Copy link
Contributor

german-one commented Mar 1, 2020

Is this not cmd.exe/Powershell's own problem?

Good point @greg904. But it doesn't behave the same in all shells and unfortunately it's not only a problem of the CMD. It fails from within the Run dialog and it fails also from a shortcut.
However, I just try to fix this in my PR because it has been accepted as an issue ...

@3col
Copy link

3col commented Mar 4, 2020

was struggling with "%V" on command line and seems it need escapes too: \"%V\"
so ended up on this "Terminal window cmd" command on shell shortcut - if any help...
@="PowerShell -windowstyle hidden -Command \"Start-Process cmd -Verb RunAs -ArgumentList '/c start wt -p cmd -d \"%V\"'\""

@DHowett-MSFT
Copy link
Contributor

Just to confirm, you are starting powershell, to start cmd, to start WT, to start powershell.

Why is your invocation three commands when just one would be fine? That’s crazy.

@3col
Copy link

3col commented Mar 5, 2020

I've been using these context menu shortcuts:
(https://www.tenforums.com/tutorials/60132-open-bash-window-here-administrator-add-windows-10-a.html)](https://www.tenforums.com/tutorials/60132-open-bash-window-here-administrator-add-windows-10-a.html)

to be able to easy open "Open command/bash window here as administrator"

but I've not found any hint on how to create the same for Windows Terminal?

Actually there are still two more escapes missing from \"%V\" because this doesn't put the "" around path name and also when using shortcut on top of the Drive it requires the \. ending, so this works for all (Directory-Background/-shell/Drive/LibraryFolder):
@="PowerShell -windowstyle hidden -Command \"Start-Process cmd -Verb RunAs -ArgumentList '/c start wt -p cmd -d \"\"%V\\.\"\"'\""

@DHowett-MSFT
Copy link
Contributor

@3col is there any reason you can’t just use wt.exe /d "%V\." instead of launching THREE DIFFERENT SHELLS AT ONCE

@DHowett-MSFT
Copy link
Contributor

I see: you want the runas verb. Hm.

@microsoft microsoft locked as off-topic and limited conversation to collaborators May 26, 2020
@zadjii-msft zadjii-msft added Area-Commandline wt.exe's commandline arguments and removed Area-Interaction Interacting with the vintage console window (as opposed to driving via API or hooks) labels Jul 7, 2020
@ghost ghost removed the In-PR This issue has a related PR label Jul 19, 2020
@zadjii-msft zadjii-msft modified the milestones: Terminal v2.0, 22H2 Jan 4, 2022
@zadjii-msft zadjii-msft modified the milestones: 22H2, Backlog Jul 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Area-Commandline wt.exe's commandline arguments Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

11 participants