Due to file permissions, Cmder won't start up:
Failed to backup ConEmu.xml file to ./config folder!
After changing the file permissions, Cmder will start. But opening a mintty shell isn't possible due to spaces in the path:
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
Oh yeh windows treats the program files area extra special, we don't recommend cmder there at all. Would you move it please and update us if the "space in path" error is still present to investigate?
C:\Program Files is the default location for applications in Windows, so it is strange that Cmder doesn't work when installed there, especially since this is not mentioned in the install instructions.
Since I cannot install it to Program Files anyway, I have now installed it to C:Cmder, sidestepping any possible issues caused by spaces in the path.
I'm sure it used to, sorry for the run around.
Vista+ added protections to that path and UAC add more as well. We'd need a proper installer and code signing to use program files, and then have to split your customisations into appData, which for software that's supposed to be easily portable.. well, it isn't once you do that.
You might want to use C:\programData\cmder for somewhere equally out the way yet for programs if you don't want cmder around your documents or something. That's untested so let us know how you get on.
Thanks for this documentation @brechtm !
You might want to use C:programDatacmder for somewhere equally out the way yet for programs if you don't want cmder around your documents or something. That's untested so let us know how you get on.
I just moved over to using this location and things seem completely fine. It might be good to put this advice in the installation instructions.
I'm not trying to be confrontational or anything but why do so many people insist on putting this in "C:program files" it's a portable piece of software it can go anywhere.
Cmder relies on several unix/linux like binaries where paths with spaces are generally not used.
While paths with spaces in them are a common thing in Windows it was never a good idea. Microsoft has even moved away from the practice where possible in newer versions of windows.
If it doesn't work in a specific location move it to another location.
I have always advised that cmd should never be put into 'Program Files' for the reasons @Jackbennett mentioned previously. Cmder is a portable tool and should be used like any other portable tool, left in the Downloads directory, on your Desktop or even on a USB drive, the work to allow Cmder to work with no issues in 'Program Files' is the same as creating an installer, a lot of work to make this portable tool, non-portable.
@MartiUK we are in complete agreement!
why do so many people insist on putting this in "C:program files" it's a portable piece of software it can go anywhere
C:\Program Files is the standard place that installed software goes in Windows. It's contrary to expected behavior that "a portable piece of software" that "can go anywhere" would not be able to actually "go anywhere". That's the only reason I mentioned that it would make sense to document it.
Another solutions is to give config folder permission. I gave it full control to users and it works under C:Program Files.
It probably won't work for multiuser environment, as users will be writing to the same config folder.
try this "C:Program Files" with ""
"C:Program FilesMongoDBServer4.0binmongo.exe"
Most helpful comment
C:\Program Filesis the standard place that installed software goes in Windows. It's contrary to expected behavior that "a portable piece of software" that "can go anywhere" would not be able to actually "go anywhere". That's the only reason I mentioned that it would make sense to document it.