Use user_conemu.xml or conemu-%computername%.xml directly if '-c [path]' is used to start cmder. #1949

daxgames · 2018-11-10T23:53:22Z

@CollinChaffin Can you test this? Related to #695

Cmder Shared Install Multi User Enhancement

This PR enhances the way Cmder.exe launches ConEmu when /c [path] is used on the command line to enable using a shared install of Cmder.

Sorry for the long explanation but I felt it was necessary.

Current Behavior

Cmder.exe does some ConEmu.xml configuration magic to retain user settings modifications done in the ConEmu GUI. When Cmder.exe is started it does the following logic:

If %CMDER_ROOT%\config\ConEmu-%COMPUTERNAME%.xml file exists
1. If %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.xml file exists
  1. Copy %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.xml to %CMDER_ROOT%config/ConEmu-%COMPUTERNAME%.xml to save any ConEmu GUI settings changes from previous sessions so they can be used in future sessions.
2. Else
  1. Copy %CMDER_ROOT%\config\ConEmu-%COMPUTERNAME%.xml to %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.xml. This is usually done following an upgrade of Cmder to reapply previously backed up configuration.
Else if %CMDER_ROOT%\config\user_conemu.xml exists
1. If %CMDER_ROOT%\vendor\conemu-maximus5/ConEmu.xml exists
  1. Copy %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.xml to %CMDER_ROOT%\config\user_conemu.xml to save any ConEmu GUI settings changes from previous sessions so they can be used in future sessions.
2. Else
  1. Copy %CMDER_ROOT%\config\user-conemu.xml to %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.xml`. This is usually done following an upgrade of Cmder to reapply previously backed up configuration.
Else
1. Copy %CMDER_ROOT%\vendor\ConEmu.xml.default to %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.xml. This happens on a brand new Cmder install whaere no previously backed up config exists.

This is done because the maintainer of ConEmu recommends leaving the ConEmu.xml file in the program folder. This results in all user init scripts and config are stored in a single place, the %CMDER_ROOT%\config folder.

The Problem when you use `/c [path]` command line argument.

The current behavior works great for a single user because all config is stored in %CMDER_ROOT%\config ConEmu runs using the %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.xml file that is backed up on launch to %CMDER_ROOT%\config.

This is not so great for a use case where a shared install of Cmder would be beneficial. Different users WILL want different settings based on personal preference. The default behavior does not allow this but the /c [path] currently partially enabled using a shared install.

The storage of user init scripts and config changes using this command line switch. Init scripts and conemu.xml backups are stored in the [user specified path]\config instead of %CMDER_ROOT%\config. This allows the following:

Cmder.exe can now use the %CMDER_ROOT%\config init scripts to allow a shared set of binaries and some shared configuration. It can now also apply user specific configuration after the shared configuration allowing users to have their own settings - ALMOST.

The problem is that Cmder still applies the same logic detailed above or handling ConEmu.xml config so SOME user unique config is possible but not all. It requires that all users have write access to the %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.xml. This can result in user settings change contention in ConEmu.

This PR fixes the last issue and enables true shared install with complete user customization.

The Difference in this PR.

When -c [path] is used to launch Cmder it does everything mentioned above but the logic handling ConEmu.xml backups changes:

If /c [path] is used
1. If [path]\config\ConEmu-%COMPUTERNAME%.xml file exists
  1. Use [path]\config\ConEmu-%COMPUTERNAME%.xml to launch ConEmu.exe
2. Else if [path]\config\user_conemu.xml exists
  1. Use [path]\config\user_conemu.xml to launch ConEmu.exe
3. Else
  1. Copy %CMDER_ROOT%\vendor\ConEmu.xml.default to [path]\config\user_conemu.xml
  2. Use [path]\config\user_conemu.xml to launch ConEmu.exe

This way no backup is required because changes in the GUI are written directly to the file in [path]\config

…h]' is used to start cmder.

daxgames · 2018-11-11T00:01:50Z

Adding one more thing:

If %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.xml exists in the shared install and there is no current user config in [path]\config\user_conemu.xml
1. copy %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.xml to [path]\config\user_conemu.xml
2. use it to launch ConEmu.

This allows all new users to have a shared starting point for ConEmu config that they can then modify without access to modify the shared config.

…f it exists

CollinChaffin · 2018-11-11T16:33:50Z

Awesome direction Dax! I am anxious to test but I want to verify I'm testing it correctly for the scenarios you envision and not just my workflow. In the scenario of multiple machines for instance all having shared access to a mapped D:\Programs\cmder as the cmder root which has the default cmder distribution structure including cmder\config folder, would you envision each machine still running using this new switch as cmder.exe /s "D:\Programs\CMDer" where "D:\Programs\CMDer\config\Conemu-%computername%.xml" exists for each machine involved, or does this new switch require moving to a totally separate config folder setup like cmder.exe /s "D:\Programs\CMDer_Configs" where this path contains no binaries and strictly config data?

Sorry but as I previously indicated I currently run shared without any use of the /c switch with sheer luck and have just lived with the nuances so want to be sure I'm first of all using that switch properly as intended.

daxgames · 2018-11-11T17:07:08Z

@CollinChaffin if you want each user to have their own init scripts, aliases, and history you would create a shortcut like:

d:\programs\cmder\cmder.exe /c d:\programs\cmder\config_user\%username%

Cmder.exewill create %cmder_root%\config_user\%username% and use the d:\Programs\CMDer\vendor\conemu-maximus5\conemu.xml as a starting point for user specific %cmder_root%\config_user\%username%\config\user_conemu.xml.

If a user wants computer specific config they can copy their %cmder_root%\config_user\%username%\config\user_conemu.xml to
%cmder_root%\config_user\%username%\config\conemu-%computername%.xml and restart Cmder.exe

daxgames · 2018-11-11T17:19:05Z

@CollinChaffin users will have total control of their personal config, history, and conemu settings with no conflicts.

…onfig for conemu.

daxgames · 2018-11-12T13:39:56Z

Just added /m command line switch. It handles auto creating conemu-%computername%.xml if it does not already exist. If the file already exists the switch has no effect and the machine specific config will be used instead of user_conemu.xml as it does today.

daxgames · 2018-11-12T14:26:58Z

/register now recognizes /c [path] and creates a shell extension that uses /c [path]:

Running the below inside Cmder:

cmder /register /c "%cmder_root%\config_user\%username%"

Creates this shell extension:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\Directory\Background\shell\Cmder]
@="Cmder Here"
"NoWorkingDirectory"=""
"Icon"="C:\\Users\\dtgam\\cmderdev\\launcher\\Debug\\icons\\cmder.ico"

[HKEY_CURRENT_USER\Software\Classes\Directory\Background\shell\Cmder\command]
@="\"C:\\Users\\dtgam\\cmderdev\\launcher\\Debug\\Cmder.exe\" /c \"C:\\Users\\dtgam\\cmderdev\\config_user\\dtgam\" \"%V\""

CollinChaffin · 2018-11-12T19:39:03Z

Ok excellent thanks for explanation testing now but one more question that I think I know the (probably unhappy) answer but I'll verify anyway. So, in the above scenario did you consider what happens in the case where TESTUSER is the SAME non-domain (local wkstn) account being used on all three machines as an example using this switch? You said it will auto-create the user folder, I assume it's based on userid? On a shared mapped drive it still collides. I have a really cool approach for you to consider as a solution.

The whole fallback to "-machine.xml" is clear was a different approach to avoid collision in multi-use but it is also not unreasonable to say if you are running a switch asking for a profile specific to a user or computer already, that you should be expected to know which you want hence the switch you used should only support one or the other. So, /c OR /m they cannot be used together, usage is invisible to Conemu since you're calling it not other way around, and all prior usages are still supported with zero changes:

/c (or perhaps should this be /u for "user"?):

%cmder_root%\PROFILES\%computername%-%userid%\config\user_conemu.xml


/m (machine) (or perhaps should this be /c for computer?):

%cmder_root%\PROFILES\%computername%-%userid%\config\conemu-%computername%.xml

The above naming convensions for actual XML config files remains unchanged, only path is being added for profiles.

This common "profile" "pick one or the other" approach would in essence ensure that underlying Conemu remains totally ignorant to any of this, as you then in your code are simply passing the end path to Conemu's launch params and ensure that you could literally now log on to three different machines, all as local machine user TESTUSER, with CMDer installed on a mapped NAS drive U:, and it looks like this:

Machine #1:      TESTPC1
User #1:         TESTUSER
Commandline:     U:\programs\cmder\cmder.exe /c U:\programs\cmder\PROFILES
CMDer config:    U:\programs\cmder\PROFILES\TESTPC1-TESTUSER\config\user_conemu.xml
Conemu History:  U:\programs\cmder\PROFILES\TESTPC1-TESTUSER\config\.history

Machine #2:      TESTPC2
User #2:         TESTUSER
Commandline:     U:\programs\cmder\cmder.exe /m U:\programs\cmder\PROFILES
CMDer config:    U:\programs\cmder\PROFILES\TESTPC2-TESTUSER\config\conemu-TESTPC2.xml
Conemu History:  U:\programs\cmder\PROFILES\TESTPC2-TESTUSER\config\.history

Machine #1:      TESTPC3
User #1:         TESTUSER
Commandline:     U:\programs\cmder\cmder.exe
CMDer config:    U:\programs\cmder\config\user_conemu.xml (conemu-TESTPC3.xml as fallback)
Conemu History:  U:\programs\cmder\config\.history

BONUS SCENARIO:
[Later logon to Machine #1 using same Windows profile, same USERID, but now with a different CMDer icon with /m vs /c, does this support it?]

Machine #1:      TESTPC1
User #1:         TESTUSER
Commandline:     U:\programs\cmder\cmder.exe /m U:\programs\cmder\PROFILES    <--(**NOTE THE SWITCH CHANGE TO /m)
CMDer config:    U:\programs\cmder\PROFILES\TESTPC1-TESTUSER\config\conemu-TESTPC1.xml <--(**Now using machine config)
Conemu History:  U:\programs\cmder\PROFILES\TESTPC1-TESTUSER\config\.history  <--(**But, still using MY history!)

[Yes, as you can see it is simply run with a different USER-based config (desired result), and the same userid that ran earlier on this machine using MACHINE-specific /m hits UP-ARROW after using a totally different USER config, but still has his/her .history file THAT SHOULD ALWAYS be tied to what that USER is doing ON THAT MACHINE but considered different when moving machines (with new profile use)]

This way, straight, simple, never any need to even code additional new fallbacks to %computername% config from user_conemu.xml because the user must decide when using either /c or /m if they want the config to be user or computer specific and it is much cleaner they no longer collide, and Conemu now can store all data history/etc. per user but can still easily fallback to prior behavior, if desired. The big missing piece here causing collisions has always been the FOLDER used for all the different components, and this is a great chance to implement a true front-end of overall "PROFILES" that is missing today in Conemu/Clink but that will support a true shared NAS or similar single instance CMDer/Conemu install, while at the same time greatly enhancing the usability.

Thoughts?

daxgames · 2018-11-13T03:31:31Z

@CollinChaffin

EDIT: You asked for thoughts and I had so many I could not type them all on my phone last night before heading to bed. So here they are!

Your use case is VERY specific and I can't see changing/breaking features that are already in the wild, and have been for some time, so drastically to suit it. Specific features I am speaking of are:

/c [path] - New cmder.exe args and shared install capability #1696 Merged 3/13/2018
Use of %cmder_root%\config\conemu-%computername%.xml simply because it exists. - Added code to check for the existence of a customized ini file.. #427 Merged 12/4/2015

First an explanation of the original features:

/c [path] - Designed to separate Cmder 'user' configuration config and scripts bin folders from the Cmder binaries to provide a sort of shared install capability. This was partially successful see the long diatribe above. Note: This was a huge departure from Cmders 'Portable` app roots based on user feedback through incidents and feature requests. PR New cmder.exe args and shared install capability #1696 by @daxgames :-)
%cmder_root%\config\conemu-%computername%.xml. _Note: This was a based on a user PR Added code to check for the existence of a customized ini file.. #427 by @kodybrown. I'd rather the filename be user-%computername%-conemu.xml but I digress! :-)
- Goals:
  - A single user wanted to share a single copy of Cmder and run it with different ConEmu config on different machines.
- Functionality
  - User must to log into a copy of Cmder stored in the cloud and manually copy %cmder_root%\config\user_conemu.xml %cmder_root%\config\conemu-%computername%.xml
  - Going forward %cmder_root%\config\conemu-%computername%.xml will be used on that machine simply because it exists.

Feature Enhancements in this PR

/c [path] Again see above.
/m - Initially create ConEmu-%computername%.xml so the user does not have to copy it manually.
- Goals:
  - Maintain existing behavior of %cmder_root%\config\conemu-%computername%.xml will be used on that machine simply because it exists.
  - Auto create %cmder_root%\config\conemu-%computername%.xml based on a command line switch if the user desires machine specific config for ConEmu.
- Functionality:
  - User A runs cmder.exe /m on machine A and ConEmu-A.xml will be created and used to start ConEmu.exe.

How this affects your use case

A user can create a shortcut with whatever /C [path] and icon he wants so you could do ALMOST exactly what you suggested using the code that is already written without breaking existing functionality.

The exception being the BONUS SCENARIO. If conemu-%computername%.xml exists wherever the users config is stored, /c [path] or not, it WILL be used.

Usage as designed

Cmder.exe will create the /c [path] exactly as provided, Windows will resolve environment variables, and inside it will be a config and a bin folder to store and use the separated Cmder config:

Init scripts(user_profile.*, user_aliases.*, profile.d/*.*) depending on shell run.
Clink Config - (.hitory, and *.lua) if using cmd.exe or compatible shell.
ConEmu config(conemu-%computername%.xml if it exists or user_conemu.xml)

So you could have a shortcut that is both Computer and User specific as shown below:

U:\programs\cmder\cmder.exe /c U:\programs\cmder\PROFILES\%computername%-%username%

If using scenarios similar to above would produce:

Machine #1: TESTPC1
User #1: TESTUSER
Commandline: U:\programs\cmder\cmder.exe /c U:\programs\cmder\PROFILES\%COMPUTERNAME%-%USERNAME%
CMDer Init: U:\programs\cmder\config\user_profile.cmd
CMDer Profile.d: U:\programs\cmder\config\profile.d\*.cmd
CMDer Host/User Lua: U:\programs\cmder\PROFILES\TESTPC1-TESTUSER\config\*.lua
CMDer Host/User Init: U:\programs\cmder\PROFILES\TESTPC1-TESTUSER\config\user_profile.cmd
CMDer Host/User Profile.d: U:\programs\cmder\PROFILES\TESTPC1-TESTUSER\config\profile.d\*.cmd
ConEmu config: U:\programs\cmder\PROFILES\TESTPC1-TESTUSER\config\user_conemu.xml
Clink History: U:\programs\cmder\PROFILES\TESTPC1-TESTUSER\config\.history

Machine #2: TESTPC2
User #2: TESTUSER
Commandline: U:\programs\cmder\cmder.exe /c U:\programs\cmder\PROFILES\%COMPUTERNAME%-%USERNAME%
CMDer Init: U:\programs\cmder\config\user_profile.cmd
CMDer Profile.d: U:\programs\cmder\config\profile.d\*.cmd
CMDer Host/User Lua: U:\programs\cmder\PROFILES\TESTPC2-TESTUSER\config\*.lua
CMDer Host/User Init: U:\programs\cmder\PROFILES\TESTPC2-TESTUSER\config\user_profile.cmd
CMDer Host/User Profile.d: U:\programs\cmder\PROFILES\TESTPC2-TESTUSER\config\profile.d\*.cmd
ConEmu config: U:\programs\cmder\PROFILES\TESTPC2-TESTUSER\config\user-conemu.xml
Clink History: U:\programs\cmder\PROFILES\TESTPC2-TESTUSER\config\.history

Machine #1: TESTPC3
User #1: TESTUSER
Commandline: U:\programs\cmder\cmder.exe
CMDer Init: U:\programs\cmder\config\user_profile.cmd
CMDer Profile.d: U:\programs\cmder\config\profile.d\*.cmd
ConEmu config: U:\programs\cmder\config\user_conemu.xml (If conemu-TESTPC3.xml exists it will be used - Required for backward compatibility)
Clink History: U:\programs\cmder\config\.history

Responses to your statements:

BONUS SCENARIO

This probably will not happen because you can achieve it with existing /c [path functionality and without some feedback from the larger community because it breaks pre-existing functionality. @kodybrown See above; This suggestion affects you, maybe others this feature has been around since 12/2015.

Later logon to Machine Gvim preferences are not used in {cmd} #1 using same Windows profile, same USERID, but now with a different CMDer icon with /m vs /c, does this support it?

You create the shortcuts, there are multiple icon colors, you can create whatever shortcuts with whatever command line and icon you want.

'as you can see it is simply run with a different USER-based config (desired result)'

/c [path] does this except the user_ConEmu.xml is BOTH Machine and User specific based on the /c U:\programs\cmder\PROFILES\%COMPUTERNAME%-%USERNAME% that was passed on the command line.`

Conemu now can store all data history/etc.

ConEmu does not store history in the Cmder config folder, Clink does you just happen to be using Clink with ConEmu via Cmder. :-)

The big missing piece here causing collisions has always been the FOLDER used for all the different components.

As detailed at length above /c [path] creates a separated Cmder config root folder that can be:

User specific - U:\programs\cmder\cmder.exe /c U:\programs\cmder\PROFILES\%USERNAME%

Computer Specific - U:\programs\cmder\cmder.exe /c U:\programs\cmder\PROFILES\%COMPUTERNAME%

User and Computer Specific - U:\programs\cmder\cmder.exe /c U:\programs\cmder\PROFILES\%COMPUTERNAME%-%USERNAME%

None of the above, separated but hard coded - U:\programs\cmder\cmder.exe /c U:\programs\cmder\PROFILES\Collin's_Config

The same userid that ran earlier on this machine using MACHINE-specific /m hits UP-ARROW after using a totally different USER config, but still has his/her .history file THAT SHOULD ALWAYS be tied to what that USER is doing ON THAT MACHINE but considered different when moving machines (with new profile use)

I am confused as to what you are referring to USER-specific and MACHINE-specific configs. I understand you are talking about the ConEmu config but isn't EVERYTHING in U:\programs\cmder\PROFILES\%COMPUTERNAME%-%USERNAME% both USER AND COMPUTER specific config based on the command line passed to cmder.exe.

In my opinion the pieces of config that should be tied to unique users, possibly on unique machines, are init scripts, aliases, and history because of what they can contain. Preferably securing the folder using a file system permissions and/or 'config' drive mapping model that would prevent one user from accessing another users config.

Example: Credentials(Bad practice I know but it is user config and we can't control what they put there.)

I may be wrong in this but it sounds like you have a ConEmu.xml config that you like that is different from everyone else's and that is what you are trying to maintain. Your ability to run your config when you want to? If that is the case you can do that to. See above.

CollinChaffin · 2018-11-15T12:30:24Z

Hey @daxgames so sorry I didn't reply sooner. I totally misunderstood and do want to reconfirm (and in process of testing myself too) that your new /c behaves the way your latest example (using my sample scenarios) shows. Namely, when you posted that first response above I think I just might have mis-read that it created d:\programs\cmder\cmder.exe /c d:\programs\cmder\config_user\%username% and I read that IT was creating the actual username (and not via env variable) and you were simply indicating that with %username% (it was late, DOH!).

So, I think we were actually thinking pretty identically on this and perhaps you misread my scenario as I think it not only is exactly what the new /c does, but what the prior PR/users use cases with the cloud were which if I had to put it on a poster as a pretty huge selling point of CMDer over straight Conemu would be simply stated as:

"Allows a user to maintain a single, portable installation of CMDer with Conemu that can then be placed into any flavor cloud sync folder of their choosing and configure command-lines on multiple machines to execute the exact same configuration, while still maintaining the minimal required unique data files such as system-specific initialization and command history to support the most common usage scenarios."

And, since it appears that the new /c will allow the user to create the initial parent cmder root via environment variables before appending the config directory (my bad) I think it hits the nail on the head. Lets leave this open just for a bit to do some final testing see if any tweaks are needed if that's okay? Nice work!

daxgames · 2018-11-15T13:00:32Z

@CollinChaffin Cool, I too thought it was a pretty complete solution after reworking it. Working with you and your use case helped me to see where the previous /c functionality was lacking.

Its funny, it has taken more time and text to explain hw what it can do works than it took to make the actual modifications to the code!

Please just let us know if you run into any issues so we can get this peer reviewed and merged. I will release 1.3.9 shortly after.

CollinChaffin · 2018-11-17T11:03:06Z

Okay @daxgames so I've run this through it's paces pretty good now on a number of scenarios, ultimately with great success! There is only one thing that if not now hopefully you can see the value in (although always easier said than done with coding it) which is the initial profile creation. I think you agree since you've nicely added some decent initialization already that now this introduces a whole new level of not only scalability, but support/maintenance overhead. Namely, this same abbreviated scenario we already discussed:

Testing

Shortcut command-line:

Z:\Programs\cmder\cmder.exe /c Z:\Programs\cmder\profiles\%computername%-%username%

Profile does not exist, post 1st run folder structure and config files looks like:

Z:\Programs\cmder\profiles\COMPUTER1-TESTUSER\
Z:\Programs\cmder\profiles\COMPUTER1-TESTUSER\bin (*EMPTY)
Z:\Programs\cmder\profiles\COMPUTER1-TESTUSER\config
Z:\Programs\cmder\profiles\COMPUTER1-TESTUSER\config\profile.d (*EMPTY)
Z:\Programs\cmder\profiles\COMPUTER1-TESTUSER\config\settings
Z:\Programs\cmder\profiles\COMPUTER1-TESTUSER\config\.history
Z:\Programs\cmder\profiles\COMPUTER1-TESTUSER\config\user_aliases.cmd
Z:\Programs\cmder\profiles\COMPUTER1-TESTUSER\config\user_profile.cmd
Z:\Programs\cmder\profiles\COMPUTER1-TESTUSER\config\user-ConEmu.xml

Observations / Issues / Questions

Clink settings file created in new profile is being inherited from which default? My pre-configured settings file in shared config is very different than the vanilla one being created for each new profile (detailed more below).
Many other config files already present/configured in shared config (PoSH profile, etc.) seemingly ignored (and in essence abandoned from perspective of novice user) when new /c is used (detailed more below).
Note the *EMPTY profile.d folder post 1st run. However, the usual one and only prior shared config directory @ Z:\Programs\cmder\config\profile.d contains:

"downloadmp3.alias.ps1"
"explorerHere.alias.ps1"
"Get-ChildItem-Color.ps1"
"gitStatus.alias.ps1"
"goToFolder.alias.ps1"
"goToFolder.config.example"
"listNpmGlobalModules.alias.ps1"
"ls.alias.ps1"
"upOneLevel.alias.ps1"
"word2md.alias.ps1"
"alias.ps1.example"
"chocolist.alias.ps1"
"chocoUpgrade.alias.ps1"
"downloadflac.alias.ps1"

So, this might be intended but for strictly 1st run initialization of these new profiles I want you to consider setting the behavior to automatically copy the legacy shared config files, obviously only if the target profile does not already exist. This also ensures that as a shared installtion scales, the adminsitrator has a supported (and friendly) method of simply staging the entire legacy %cmderroot%\config one time - be it for a shared UNC install of 5000 users or a home user who wants to set up CMDer one time in a cloud sync folder and either way once the single config folder (which BTW the beauty is that it is still fully usable for initial setup and testing) and know that ANY newly created profiles with /c will now inherit. Again - not my scenario think any network admin wanting to deploy CMDer in a corp env on UNC distribution points and/or DFS as it is it appears to me that as it is right now, you would need to pre-stage and pre-create every single profile folder yourself and then copy those config files which would be quite inefficient if CMDer could simply inherit upon 1st launch.

Also, as a secondary, I have not gone through all of the new code so I'll just ask to verify that all those profile.d files (and ANYTHING else in the PROFILE\config*) under the /c use ONLY that new location's copy of XYZ and will NOT utilize the old legacy shared root for anything in that config or bin path(s), correct?

And lastly, does this open up any caveats where even paths relative to %cmderroot% are being written into any config files that either 1. now break functions in general if running from this new profile location, and 2. prevent other means (scripting, etc.) of maintaining profile config files based off a single master copy? Just a thought I believe the answer is no and I know you already thought about it once, but now that it's moving forward wanted to bounce it off of you before large implementations begin cropping up. :)

Otherwise, overall this looks awesome! Some of this could just be a matter of having to have solid documentation so any legacy users moving to profiles knows exactly what does NOT come over by default, and exactly what they are responsible for moving where (assuming you don't whip up the magic code to do it for them) :). One of the nicest things was to see the separate history (clink) working properly for the first time ever! That itself will excite many. Again, nice work! Let me know what you think about the above and I'll be happy to continue any further testing!

LOL and per your comment it is admittedly nice to interact with someone that is as detailed in their explanations as I am because I don't know about you but for me there is nothing worse than taking a bunch of time to write-up a ton of detail, even if in the form of a question, to then have the responder with whom you are interacting reply with all of a few words!

daxgames · 2018-11-18T00:51:23Z

@CollinChaffin - Answers/Responses

This is the default Clink Settings file it is located where the --profile [path] puts the Clink profile, in your case it is the /c [path] folder. There is only one Clink profile and only one Settings file that gets processed so the shared Clink settings are ignored when using /c [path], this is out of our control because we do not maintain Clink. You might be able to use your shared user_profile.cmd to copy down the shared Settings file and *.lua to each user config folder on initial run, not sure how that would work though since Clink runs before the user_profile.cmd.
The functionality should first process the shared user_profile.ps1 then the profile.d\*.ps1 folder then the user user_profile.ps1 then the user profile.d\*.ps1 folder so something is not right.

I noticed in the Powershell profile.ps1 it is doing:

    foreach ($x in Get-ChildItem *.ps1) {
      # write-host write-host Sourcing $x
      Import-Module $x
    }

This is wrong and was done 3 months ago via a PR. The code that I know worked because I wrote it used to be:

    foreach ($x in Get-ChildItem *.ps1) {
      # write-host write-host Sourcing $x
      . $x
    }

I will be fixing it. Its already written and will be added to this PR:

Note: you can un-comment the write-host line to confirm these are being sourced.

Fixed code:

    foreach ($x in Get-ChildItem *.psm1) {
      # write-host write-host Sourcing $x
      Import-Module $x
    }

    foreach ($x in Get-ChildItem *.ps1) {
      # write-host write-host Sourcing $x
      . $x
    }

Expected behavior. This is designed to source the shared scripts from where they are on the shared media and not to copy them into into the user config. That's the point of a central shared install, not to mention its difficult to maintain updates if every user gets a copy of the shared files the first time they run Cmder and never get updates again. If they are processed correctly in the shared location any update an admin makes will apply to all users the next time anyone starts a Cmder session.

If you want to copy them down you have a user_profile.* in the shared config folder but if all is working properly they should be processed from the shared config location. If you take that approach I recommend you move the files out of the shared profile.d to avoid processing the files twice. We will be leaving them where they are and not copying them to each user config folder.

Also, as a secondary, I have not gone through all of the new code...

No if using /c [path] the shared user_profile.* and profile.d\* is processed first then the user path of the same files are processed. As I said earlier Clink Settings and *.lua come ONLY from the /c [path].

And lastly ...

None that I see, but I have spent a lot of time fixing things I didn't expect to see - :-)

daxgames · 2018-11-18T01:04:27Z

@CollinChaffin - Fixed profile.ps1 not properly sourcing *.ps1 files:

Tested as follows:

Created config\user_aliases.ps1 . sourced from config\user_profile.ps1:

new-alias ssh $env:cmder_root\vendor\git-for-windows\usr\bin\ssh.exe -erroraction silentlycontinue

function va {
  vi "$ENV:CMDER_ROOT\config\user-aliases.ps1"
}

function gs {
  git status
}

function ga($git_args) {
  if ([string]::IsNullorEmpty($git_args)) {
    $git_args = "."
  } else {
    $git_args = $args -join ' '
  }

  git add $git_args
}

Created config\profile.d\user_aliases.ps1:

function cmderr {
  cd $ENV:CMDER_ROOT
}

Launched new sessions with and without /c [path] all aliases/functions work.

CollinChaffin · 2018-11-18T07:06:57Z

Ahh got it! I did not realize that both the shared and user profiles were both executing. I am testing more now but things are looking great we will just have to script some initial user profile setup but since the shared still does execute, it may not wind up being as necessary.

CollinChaffin · 2018-11-18T13:48:13Z

Sorry one quick question the only thing still not clear to me is that despite this message that mirrors what you said above:

Generating clink initial settings in "Z:\Programs\cmder\profiles\TESTUSER\config\settings"
Additional *.lua files in "Z:\Programs\cmder\profiles\TESTUSER\config" are loaded on startup.\
Creating initial user_aliases store in "Z:\Programs\cmder\profiles\TESTUSER\config\user_aliases.cmd"...
        1 file(s) copied.
Creating user startup file: "Z:\Programs\cmder\profiles\TESTUSER\config\user_profile.cmd"

Above you said be careful that BOTH shared then the new profile user profiles would be loaded so don't duplicate, so I am unclear then as to why it is copying/creating what are duplicates to what is in shared? I do init things usually in my tasks via separate scripts anyway so perhaps I'm premature in asking prior to just testing but is it that these appear as duplicates to my shared defaults simply because they ARE always vanilla defaults?

And just to re-confirm for testing, ALL lua and user profile/alias' first execute the shared and then also execute ALL of the same via profiles so for instance a ENV variable named "TESTVAR" set in both user_profile.cmd in shared to "ONE" and then the same var set to "TWO" in profiles winds up after init being set to "TWO", correct?

daxgames · 2018-11-18T14:04:18Z

The files created in the user config folder are initial vanilla defaults that do very little. Above I recommended if you want every user to have the same profile.d scripts to not duplicate them in both profile.d folders.

Users still need their own user_profile.* and user_aliases.* so they can add their own config customization after the shared profile runs.

EDIT:
Clink Settings is in the Clink profile folder. I just reconfirmed and was initially wrong about where lua runs.

Lua does indeed run first from shared config folder then the profiles config folder. Your env var assumption is correct. Profile config overrides shared config.

daxgames · 2018-11-22T22:20:37Z

@CollinChaffin We good to go on this one? I know all has been positive so far but wanted to check since you have used this more than anyone.

…-user

CollinChaffin · 2018-11-24T13:40:29Z

Hey sorry absolutely testing looks great on this! In fact I missed your message above and just checked hoping to find this enhancement merged into master seeing these last few commits. Nobody knows about it but I guarantee once they do that I won't be the only one using this feature especially if they see how it can be combined with cloud storage as a careful fully portable install which is what I've been testing and this is the piece that's been missing. Commit away!

EDIT: And FYI when introduced your recommendation of using: <PATH TO CLOUD STORAGE>\cmder\cmder.exe /c <PATH TO CLOUD STORAGE>\cmder\profiles\%computername%-%username% is what I've been actively using now (so what you might want to use as a recommended example) with zero issues on multiple systems, all syncing the (now separate) inits, configs, and clink histories real-time to all other systems all while maintaining a single master shared set of configs, and then all to the cloud for backup/distribution to all other systems.

daxgames · 2018-11-24T16:06:04Z

@Stanzilla you want to look at this before it's merged? I was going to merge it and release 1.3.9. I'd like to start releasing more frequently rather than waiting months.

Stanzilla · 2018-11-24T23:09:45Z

I'm completely out of the loop, I trust your judgement :)

daxgames · 2018-11-29T01:24:33Z

@CollinChaffin - Merged and Released.

daxgames added 2 commits November 10, 2018 17:26

use user_conemu.xml or conemu-%computername%.xml directly if '-c [pat…

e904ebc

…h]' is used to start cmder.

cleanup

e17b04c

daxgames added the Work In Progress Work in Progress DO NOT MERGE! label Nov 10, 2018

daxgames added 2 commits November 11, 2018 07:55

added /c [path] use vendored conemu.xml as a default starting point i…

8c08179

…f it exists

cleanup

0efeaa9

daxgames added 2 commits November 12, 2018 07:56

add /m command line argument to use machine config rather than user c…

d8e8fc8

…onfig for conemu.

better command line error handling

b16aa7a

make /register work with /c

787ac37

daxgames requested a review from Stanzilla November 15, 2018 13:01

daxgames removed the Work In Progress Work in Progress DO NOT MERGE! label Nov 15, 2018

fix powershell profile.d

7203671

Merge branch 'master' of https://github.com/cmderdev/cmder into multi…

eb6a332

…-user

daxgames merged commit 22aa59b into cmderdev:master Nov 29, 2018

This was referenced Dec 2, 2018

Interface language setting is not saved #1920

Closed

Can't save configuration properly #1981

Closed

daxgames mentioned this pull request Dec 14, 2018

Use default files for default user profiles #1987

Merged

daxgames deleted the multi-user branch March 13, 2019 01:10

CollinChaffin mentioned this pull request Sep 16, 2019

Replace Lambda in Powershell Durably #2146

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use user_conemu.xml or conemu-%computername%.xml directly if '-c [path]' is used to start cmder. #1949

Use user_conemu.xml or conemu-%computername%.xml directly if '-c [path]' is used to start cmder. #1949

daxgames commented Nov 10, 2018 •

edited

Loading

daxgames commented Nov 11, 2018 •

edited

Loading

CollinChaffin commented Nov 11, 2018

daxgames commented Nov 11, 2018 •

edited

Loading

daxgames commented Nov 11, 2018 •

edited

Loading

daxgames commented Nov 12, 2018

daxgames commented Nov 12, 2018 •

edited

Loading

CollinChaffin commented Nov 12, 2018

daxgames commented Nov 13, 2018 •

edited

Loading

CollinChaffin commented Nov 15, 2018

daxgames commented Nov 15, 2018 •

edited

Loading

CollinChaffin commented Nov 17, 2018

daxgames commented Nov 18, 2018

daxgames commented Nov 18, 2018 •

edited

Loading

CollinChaffin commented Nov 18, 2018

CollinChaffin commented Nov 18, 2018

daxgames commented Nov 18, 2018 •

edited

Loading

daxgames commented Nov 22, 2018

CollinChaffin commented Nov 24, 2018 •

edited

Loading

daxgames commented Nov 24, 2018

Stanzilla commented Nov 24, 2018

daxgames commented Nov 29, 2018

Use user_conemu.xml or conemu-%computername%.xml directly if '-c [path]' is used to start cmder. #1949

Use user_conemu.xml or conemu-%computername%.xml directly if '-c [path]' is used to start cmder. #1949

Conversation

daxgames commented Nov 10, 2018 • edited Loading

Cmder Shared Install Multi User Enhancement

Current Behavior

The Problem when you use /c [path] command line argument.

The Difference in this PR.

daxgames commented Nov 11, 2018 • edited Loading

CollinChaffin commented Nov 11, 2018

daxgames commented Nov 11, 2018 • edited Loading

daxgames commented Nov 11, 2018 • edited Loading

daxgames commented Nov 12, 2018

daxgames commented Nov 12, 2018 • edited Loading

CollinChaffin commented Nov 12, 2018

daxgames commented Nov 13, 2018 • edited Loading

EDIT: You asked for thoughts and I had so many I could not type them all on my phone last night before heading to bed. So here they are!

First an explanation of the original features:

Feature Enhancements in this PR

How this affects your use case

Usage as designed

Responses to your statements:

CollinChaffin commented Nov 15, 2018

daxgames commented Nov 15, 2018 • edited Loading

CollinChaffin commented Nov 17, 2018

Testing

Observations / Issues / Questions

daxgames commented Nov 18, 2018

daxgames commented Nov 18, 2018 • edited Loading

CollinChaffin commented Nov 18, 2018

CollinChaffin commented Nov 18, 2018

daxgames commented Nov 18, 2018 • edited Loading

daxgames commented Nov 22, 2018

CollinChaffin commented Nov 24, 2018 • edited Loading

daxgames commented Nov 24, 2018

Stanzilla commented Nov 24, 2018

daxgames commented Nov 29, 2018

daxgames commented Nov 10, 2018 •

edited

Loading

The Problem when you use `/c [path]` command line argument.

daxgames commented Nov 11, 2018 •

edited

Loading

daxgames commented Nov 11, 2018 •

edited

Loading

daxgames commented Nov 11, 2018 •

edited

Loading

daxgames commented Nov 12, 2018 •

edited

Loading

daxgames commented Nov 13, 2018 •

edited

Loading

daxgames commented Nov 15, 2018 •

edited

Loading

daxgames commented Nov 18, 2018 •

edited

Loading

daxgames commented Nov 18, 2018 •

edited

Loading

CollinChaffin commented Nov 24, 2018 •

edited

Loading