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

Portable Commands have spaces in some cases #2951

Open
Trenly opened this issue Feb 10, 2023 · 7 comments
Open

Portable Commands have spaces in some cases #2951

Trenly opened this issue Feb 10, 2023 · 7 comments
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Portable Issue related to portable package

Comments

@Trenly
Copy link
Contributor

Trenly commented Feb 10, 2023

Brief description of your issue

When executable names contain spaces, it makes the commands unusable in some shells. See https://github.com/microsoft/winget-pkgs/tree/c6cf13bd8fb11fc67ab01e20b079b61e5fbd4c80/manifests/c/Camunda/Modeler/5.7.0 for an example of a file which has a space in the path.

Steps to reproduce

Use the above manifest

Expected behavior

Command alias to be `Camunda-Modeler'

Actual behavior

Alias is Camunda Modeler

Environment

Windows Package Manager v1.4.10173
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage Issue need to be triaged label Feb 10, 2023
@denelon
Copy link
Contributor

denelon commented Feb 10, 2023

Should we prohibit spaces, or are they expected?

@denelon denelon added Issue-Bug It either shouldn't be doing this or needs an investigation. and removed Needs-Triage Issue need to be triaged labels Feb 10, 2023
@Trenly
Copy link
Contributor Author

Trenly commented Feb 10, 2023

I guess this is a question of usage. The referenced application is a GUI application, so because of #2711 it's required to use start 'Camunda Modeler' at the moment. However, if it were a CLI application, then it wouldn't make sense to call it with start, and using quotations around a command alias in some terminals like Powershell causes it to be treated as a string and not an application call.

To me it's a question of usability, where if a space is present in the file name, it becomes unusable, but if the space is replaced by a -, even though it may not be the exact representation of the file the publisher intended, it is at least functional

@denelon
Copy link
Contributor

denelon commented Feb 10, 2023

What do the "official" docs expect for this package? I'm trying to reason through the best behavior we should be focusing on. We want people to be able to use applications "as expected".

@florelis
Copy link
Member

I don't see the issue with the spaces? In PS you can simply do & "Camunda Modeler". I think in cmd you just need to quote it (and actually, there is some magic parsing of the string so that you don't even need to).

@Trenly
Copy link
Contributor Author

Trenly commented Feb 10, 2023

I don't see the issue with the spaces? In PS you can simply do & "Camunda Modeler". I think in cmd you just need to quote it (and actually, there is some magic parsing of the string so that you don't even need to).

This seems incorrect to me.
image

Also, do a majority of users know about being able to do the & trick or using start? I would argue not, since the submitter of microsoft/winget-pkgs#65988 said:

The unzipped folder is added to path and I can start the application by typing "Camunda Modeler" into the windows run (WIN+R) prompt, but not from pwsh or cmd.

@florelis
Copy link
Member

It's weird that it doesn't start when you call it with &, but it is still finding it. Otherwise you'd get "is not recognized as the name of a cmdlet, ...". Maybe it's the difference between using CreateProcess and ShellExecute, and something about that app in particular.

I've been playing with a copy of "nuget.exe" where I put spaces in the name, and it all works just fine when I call it with &. Same if I use a symlink.

image

I'd think the & call operator is pretty much common knowledge with people who use PS. It even gets auto-added with tab-completion when you are typing a path to an executable and it has spaces, like anything under C:\Program Files

I don't think this is an issue with winget, anyways. If the executable has spaces in its name, that is also the case when you install it outside of winget.

@Trenly
Copy link
Contributor Author

Trenly commented Feb 11, 2023

I don't think this is an issue with winget, anyways. If the executable has spaces in its name, that is also the case when you install it outside of winget.

That is true, but not all portable applications are added to the path by the user, especially when they are GUI apps. Adding every package to path could cause confusion if there are spaces. Perhaps the best action here is to wait and see if any additional feedback comes in

@denelon denelon added this to the v1.5-Client milestone Feb 14, 2023
@denelon denelon added this to WinGet Feb 14, 2023
@denelon denelon added the Portable Issue related to portable package label Feb 21, 2023
@denelon denelon modified the milestones: v1.5-Client, v.Next-Client Apr 19, 2023
@denelon denelon removed this from WinGet Jun 13, 2023
@denelon denelon removed this from the v.Next-Client milestone Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Portable Issue related to portable package
Projects
None yet
Development

No branches or pull requests

3 participants