microsoft
Portable Commands have spaces in some cases
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
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
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".
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).
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.
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.
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.
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.
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