cmder starts with wrong conemu.xml file?

[jankatins]

I update cmder to the latest prerelease (v1.2.9, d6b54ee -> renamed aliases and history to get them back, deleted all other previous installed files, and then unziped the archive to the old location) and the settings window shows that the xml file is in C:\Users\jschulz\Dropbox\Programme\cmder\vendor\conemu-maximus5\ConEmu.xml

Under info, the current command line is shown as /Icon "C:\Users\jschulz\Dropbox\Programme\cmder\icons\cmder.ico" /Title Cmder. Thats the same commandline as shown in procexplorer for the cmder window.

[jankatins]

If I use the launcher (cmder.exe + dlls from cmder_mini -> https://github.com/cmderdev/cmder/releases/download/v1.2/cmder_mini.zip) from 1.2, it shows the right config file.

[Stanzilla]

You mean what happened here? https://github.com/cmderdev/cmder/pull/600

[jankatins]

yep... seems I forgot to look at the dev branch and master still has the old behaviour... sorry...

why is there still a https://github.com/cmderdev/cmder/blob/development/config/ConEmu.xml ?

[Stanzilla]

What happens is that the launcher copies that file into the correct place so it does not get overwritten.

[jankatins]

ok, but this is missleading: the file in config is still around after copying, so I assume that this is the file which is used. Would it be possible to add a link to the new config file and remove the old one? Also, shouldn't the initial file be in vendor and not in config as it is now only used to populate the intial state (see also https://github.com/cmderdev/cmder/issues/694)?

[Stanzilla]

No idea but it works fine as is, why change it?

[jankatins]

but it will get you of bugreports ala this one or:

• why is my manual change in the conemu config file not applied (changed in config, but the one in vendor/conemu already existed so not updated) -> config is the place where I look for the user customisations.
• I lost my conemu changes when I updates (deleted vendor subdirs, got old/obsolete file from config again (if config was not overwritten) or the new default file (if config got overwritten) -> #694)

[centur]

:) I'll be another one who will report this issue - spent some time editing and aligning my config\ConEmu.xml (moving all my customizations from original ConEmu setup I had on my machine but want to preserve Cmder features and coloring) just to discover it's not being used... Can anyone explain the structure and relationship between all ConEmu configs, I have at least 3 of them:

Cmder\config\ConEmu.xml
Cmder\config\ConEmu-setup.xml
Cmder\vendor\conemu-maximus5\ConEmu.xml

Not talking about other ConEmu own samples...

Update: Checked PR #600 and now I understand that Cmder config will overwrite ConEmu config if the latter one doesn't exist. I think this behaviour can be changed - so Cmder\vendor\conemu-maximus5\ConEmu.xml will be always overwritten with a copy from the config folder or at least if Cmder\config\ConEmu.xml version is newer\different than vendor one. This gives user an option to edit only one file in config folder and be sure that it'll be copied to the right place for vendor's conemu. Right now I has to manually delete vendor's config to trigger that copy behaviour.

[centur]

Can you give us any comment on why this is closed ? Would be nice to hear which approach is considered final

[Stanzilla]

Guess this should still be open, sorry was on a closing spree :)

[centur]

PR #600 looks good to be "closer" for this issue, in terms of behaviour, except that config files expected to be in Cmder/config folder. If someone will implement missing behaviour (to keep Cmder and Vendor configs in sync) - that would be enough to close this issue. It might be as simple as config's size+date check, to avoid start time increase (or fastest possible hash - md5 or something like it)

[jinzi9800]

I don't know why it happened, but I can deal with it in this way: remove or rename all the documents with the initial word of "user-" in the config folder of the cmder‘ s root, then run "cmder.exe". It worked again, my pleasure, dears

[CollinChaffin]

@Stanzilla This is absurd that this issue after years is not only closed, but apparently was simply ignored. It's backwards as stated above. CMDer should ALWAYS be dealing with the USER'S CONFIG DIR copy of conemu.xml. That is simple best practice and why there is a CONFIG folder to begin with. If you want to copy it all over the planet, that's fine (but also makes zero sense because if the initial config is changed to CONFIG folder no copy ever has to happen) but on all my machines with the latest version YEARS after this issue was opened, closed, re-opened, etc., my conemu.xml in my USER folder is there, yes. However, it is old and vanilla, unchanged with any of my changes, and conemu is configured (as it apparently has been for years) to still look in cmder\vendor\conemu-maximus5\ConEmu.xml.

So, when I go to edit what I THINK should be my config (in the config folder) with an editor....not only does it not impact ANYTHING, but now it's DATA LOSS on upgrade - my customized one that gets changed with GUI config is wrongfully sitting in the vendor folder, BY ITSELF, just waiting TO BE LOST on next upgrade. I know, because for me, this has now happened. For me, no "copy" ever takes place. I have only ONE xml file that is not default and it is in the vendor folder. So, is this a side-effect of being a long-time user and being bitten by one of the above bugs, continued to upgrade, and just never had that magic "copy back" begin?

When I open the GUI, IMO I should see my USER folder path xml in the "Storage:" bar and it's that's all everyone above has been asking for now for years. If I change it myself now, how is that impacted by all this copying back and forth I've read occurs (sometimes) above?

[daxgames]

@CollinChaffin see #1109 for an explanation for how it actually works today in current cmder versions, it may also be explained in the readme.md. Your user conemu config is actually stored in config\user_conemu.xml or config\conemu_%computername%.xml if you specify you want computer specific config via cmder.exe command line options. It may be a - and not an _, I can't remember since we tried to remove all dashes at your request , to try and get Tcc.exe working and I don't know if we did this file, I am on my cell phone and can't look right now.

So if you must edit the xml file to make config changes edit either the config\conemu_%computername%.xml or the default config\user_conemu.xml

I believe it was recommended at one time, EDIT: #600, by maximus5, that the conemu.xml file used by conemu exe be in the conemu folder so that's where we put it. We, however, need a cmder specific starting point so we have cmder specific session tasks in the conemu gui. That is what the 'default' conemu.xml file is for. I don't like the location either, it should be in vendor since it is literally used one time in a fresh install of cmder.

The backup of the settings on cmder start is not a perfect solution but it's the only solution we have since cmder.exe is a launcher and not a wrapper. It launches conemu and exits so we cannot backup the settings when conemu closes. We are following the conemu authors recomendation on where the file should be and that will probably not change.

I have been using cmder for years and have not had data loss since this feature was implemeted, that is why I added the functionality in the first place.

I am sorry you had some data loss but I must ask, what version are you running. Cmder.exe even posts an error message if it is unable to backup the file on start.

If you want to change the config storage path that is up to you just don't use one of the above mentioned filenames.

Hope this helps.

[centur]

A bit offtopic about potential data loss - the most efficient way I found is to use portable Cmder from Dropbox (or any other disk sync) - you have some file versioning and an easy way to "go back" in history. No hassle auto-magical basic git ;)

[CollinChaffin]

@daxgames Hey Dax so sorry I didn't get back to this quicker I have confirmed everything seems good now however the one last piece I never did much with that I am trying to possibly work into my workflow with different machines is the use of the config\conemu_%COMPUTERNAME%.xml vs the default user xml. I'm sure it's just me missing it but where can I find more info and details specific to ensuring the %COMPUTER% version of Conemu's xml is always used specific to CMDer usage? Thanks!

EDIT: I did catch up on PR#1109 for the basic info but if there is any additional info/docs you know of specific to it otherwise I'll just assume nothing much has changed since that PR merge.

EDIT2: Also, as relates to the new PR#1109 behavior of %COMPUTERNAME%, I see cases where history file seems to be getting duplicated with "-%COMPUTERNAME%.history" vs ".history"....is the history per machine log now handled correctly and what is that order of preference is is similar to the xml?

EDIT3: Ok so I've gone through much of the CPP code and confirmed the xml behavior but still have not been able to confirm where in the code the history is handled and what that logic looks like for multi-user.

[daxgames]

I am not where I can look at it right now but I am not aware of the "-%COMPUTERNAME%.history" duplication. This is not a feature I have never tried to use more do I know much more about it than what you have seen in the cpp. The cpp has nothing to do with history.

It could just be an 'undocumented feature' or as I call them a bugs. Clink handles the history. Maybe look in vendor/clink.lua

[CollinChaffin]

Thanks but I was specifically referring to the Conemu cmdhistory:

https://github.com/Maximus5/ConEmu/blob/master/src/ConEmu/CmdHistory.cpp

In addition to yes the clink history LOL I'm trying to determine how folks are really running CMDer in a shared multi-system environment and not clobbering their console history in addition to the config XML, which I did find/confirm in the CPP as to the order of preference when loading.

When I've shared, I not only have found a ".history" in the CMDer/conemu folder with my conemu history, but also a "-SYSTEM.history" and I'm trying to determine exactly which piece might be responsible it was not in the clink.lua but I have not yet checked the actual clink code. Thanks!

EDIT: Note the TWO history files I have are in the CMDer\Config folder which is why I asked if you happened to know. From CONFIG\Readme.md:

.history: the current commandline history; autoupdated on close.

EDIT2: If you can just help shorten my code search to tell me how your app moves .history into the CMDer\config folder (I assume CMDer does, cannot think of any other app that knows about that folder unless buried in a LUA I missed). Clink does denote two flavors of history depending on the console type flag shown here:

https://github.com/mridgers/clink/blob/0e9734982dc5869d14c7b8f176cf966951674e39/readline/readline/histfile.c#L142

So I wonder if through backup a duplicated got flagged and renamed to -.history.....but for sake of multi-system sharing the cmd history really should be per system just like the config XML to avoid it being continually clobbered and/or appended to by multiple systems with shared folder access that renders the command history file junk as it's a mish-mosh of several systems history inter-mixed.

[daxgames]

Yeah when you said cpp I thought you meant the cmder launcher cpp code. Honestly I have never even considered looking at clink or conemu code, never had a reason.

Shared folder access for Cmder is a relatively new and probably under used feature.

I assume you have seen the -c cmder.exe command line argument? This separates the user config folder from the cmder binaries but uses config from both locations. It allows a shared cmder config with user customization and individuality I have not tested it personally with regard to .history storage. I have not done a lot of looking at how history is handled, again never had a need to. I will see what I can find but my guess it is still clink and it has to do with the clink profile location specified when clink is started from init.bat. I doubt it would know any thing about system specific history files as this is a truly cmder unique feature.

[CollinChaffin]

Okay so I think I've traced it all which does start obviously in CmderLauncher.cpp when initially it is determined whether operator is running under a "CMDER_USER_CONFIG" or not....from there it's all buried in those environment variables and the various init.bat/clink.lua/etc. and then yes, Clink does it's thing with it's hard-coded normal behavior once that location is passed in which is how it winds up there and also why it's getting clobbered and appended to with multi-use. It almost seems like (unless I'm missing something) that there are actually more protections that would apply to a PER MACHINE shared usage when forcing CMDer/Conemu to use the "CMDER_USER_CONFIG" vs the machine-specific fallback config scenario where Conemu-%computername%.xml are used and one would think would be best suited for it. However, IMO other than the XML config file, not much else sits in that config scenario as far as code to separate things like history, whereas forcing a "user" PER MACHINE run instead, has some additional unintentional safeguards in place due to the entire "user" profile path being passed to Clink and conemu via CMDER_USER_CONFIG, which then allows those 3rd party apps to keep the separate history.

Or, is there a better way currently using the much more intuitive Conemu-%COMPUTERNAME%.xml` "profile" to ensure more than just that one XML remains unique per machine run?

[CollinChaffin]

Hey @daxgames sorry our last messages crossed I didn't even see yours until now. I've been monitoring these last few commits to ignore the config folder and really appreciate you looking at this. I wonder if it's really not as under-utilized a thing as you think, and maybe just not really under-reported/discussed. The reason I say that is that remember, there really is no immediate "issue" here - no error, nothing truly broken from operations perspective. The reason I was asking/reporting is that despite me having run CMDer in a shared cloud-sync folder between many different machines for quite some time now, I never had an issue - UNTIL recently when I desperately needed one specific set of command history from one specific session and in addition to finding the multiple named XML's and thinking cloud was just being annoying and duping them with "-%computername%" inserted (since it can do this), I also only then stumbled upon this history issue which is really just me trying to be proactive when I found all my sessions (at least clink) except one for some reason blended together which is obviously NOT a desired situation.

And thanks I actually have gotten away with not having to run with any special switches but will look now more at the "-c" which I think I have seen and perhaps should have been using all along to ensure history desperation. From reading the conemu and clink code (interesting) I certainly think regarding clink there is and will never be anything in place to prevent collision issues unless the user specifically takes action to ensure each clink session is in a separate profile space (which perhaps your "-c" can help address).

Is the "-c" a switch you typically use? I will tell you if you don't you should give it a shot this way since it allows having only a single fully portable copy of CMDer/conemu to configure/maintain all the tasks and code tweaks, patch/update, and backup not only to multiple local but the cloud giving separate full versioning history of each script/lua/xml. On one hand right now without the "-c" is a double-edge sword because on the other hand right now, a cool side-effect is I can literally launch CMDer an hour later on a totally different machine, and hit up-arrow and run the same command I just ran on the first PC which I have gotten used enjoy so I'll have to test the "-c" but once I have the config/tasks in the XML updated on one, I still do like the idea of still having the ability to have unique XML config per machine, if necessary, so thanks!

[daxgames]

@collinchaffin the -c is something I added to cmder because users had requested a way to use cmder in a multi user use case and I had my own reasons.

The ignore config pr is related to your question only in that it gave me a reason to look at the cmder launcher cpp. I am a strong believer that everything in config is user data and should not be touched by us. We have been slowly moving things we own from there to vendor.

I have played some with the computer specific config and I have not see ths -%computername% phenomena you mentioned. I guess I don't fully understand what you are doing if not using the -c because without it I would fully expect all users to share everything in the %cmder_root% where launch launched cmder.exe from.

Just thinking about this tells me that -c needs some work for your use case. Multi user cmder is not really for your use case because cmder.exe puts the conemu.xml where conemu recommends which requires write access to cmder/vendor/conemu and varying config depending on who launched it last.

A better approach would be if using -c use the user-conemu.xml or the conemu-%computername%.xml preferring the latter from %cmder_root%\config to start conemu. All user settings set in conemu are truly user settings at that point.

If that file doesn't exist the copy it from the shared cmder/vendor/conemu install to config then use it from there.

Hopefully this makes sense?

[daxgames]

@collinchaffin I just made a cmder version that does exactly what I suggested above if you are interested. I will do a pr after some additional testing.