Skip to content
New issue

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

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

Already on GitHub? # to your account

CMDER_START should always be set to USERPROFILE unless explicitly set through /START parameter #772

Closed
1 of 2 tasks
MartiUK opened this issue Dec 14, 2015 · 8 comments
Closed
1 of 2 tasks

Comments

@MartiUK
Copy link
Member

MartiUK commented Dec 14, 2015

  • CmderLauncher.cpp: set CMDER_START to USERPROFILE unless set through /START param.
  • Conemu.xml: Always use CMDER_START for new tasks.
@jankatins
Copy link
Contributor

cmder is also registered as "C:\Users\jschulz\Dropbox\Programme\cmder\Cmder.exe" "%V" but the startup requires /START https://github.com/cmderdev/cmder/blob/development/launcher/src/CmderLauncher.cpp#L290

@jankatins
Copy link
Contributor

Whatever, adding it also didn't make cmder start up in the directory I rightclicked.

@MartiUK
Copy link
Member Author

MartiUK commented Jan 11, 2016

I haven't made these changes yet, but it should fix most issues regarding /START.

@jankatins
Copy link
Contributor

Ok, I think it's ok not to have /START in the context menu integration, but I think that the path argument is ignored in https://github.com/cmderdev/cmder/blob/development/launcher/src/CmderLauncher.cpp#L155 So in the moment it looks like the right click integration is broken? At least it doesn't work on my computer :-(

@MartiUK
Copy link
Member Author

MartiUK commented Jan 11, 2016

The problem with cmder_here stems from the fact that the tasks do not use CMDER_START as an initial directory to work with. Which is part of this issue.

@jankatins
Copy link
Contributor

What should the outcome be here?

  • cmder /START <dir> (right click "cmder here") -> should overwrite all settings?
  • the tasks can specify it's own startup path
  • if a user sets CMDER_START -> not sure what priority that should have?

It seems for PS, the path gets applied to a registry key which is then used to set the CWD. For cmd, this registry key is ignored and CMDER_START env variable is used (which is not set by cmder.exe). shell doesn't seem to change anything...

Unfortunately, the init.bat file always overwrites the current dir with the "%HOME%" if CMDER_START is not set.

IMO:

  • if a path is set in cmder /START <path>, this path should overwrite everything
  • if a user specifies a CMDER_START environment variable, it should be applied
  • as a last measure, the set working dir (by the task) should be taken last.
  • all tasks should set a working directory (which they do? -new_console:d:%USERPROFILE%)

IMO this could be done by letting cmder.exe setting/overwriting CMDER_START if path is set. And get that implemented in all startup scripts.

@jankatins
Copy link
Contributor

tried to make #772 (comment) happen in #798

MartiUK added a commit that referenced this issue Jan 15, 2016
CMDER_START should always be set as a result of either:
1. The user passes a directory to cmder.exe using `/START $DIR`
- or -
2. Sets CMDER_START as a default environment variable.
Fixes #772
@MartiUK
Copy link
Member Author

MartiUK commented Jan 15, 2016

@JanSchulz See #803 also.

@MartiUK MartiUK closed this as completed Feb 8, 2016
sonictk pushed a commit to sonictk/cmder that referenced this issue May 21, 2016
CMDER_START should always be set as a result of either:
1. The user passes a directory to cmder.exe using `/START $DIR`
- or -
2. Sets CMDER_START as a default environment variable.
Fixes cmderdev#772
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants