Command line argument to start up using a specified configuration file #9284

@DHowett commented on GitHub (Jun 26, 2020):

You may also want to follow #2933 😄

@DHowett commented on GitHub (Jun 26, 2020): You may also want to follow #2933 😄

claunia commented

@rwv37 commented on GitHub (Jun 26, 2020):

I might be misunderstanding something here, but it doesn't seem to me like #5465 is what I'm asking for.

That looks like it's asking for a better way to specify startup commands (like split-pane and such). I think that's a good idea too, but it's not what I'm asking for.

What I'm asking for is a way to specify, on the command line, the location of the startup configuration file -- i.e. the file where you define things like the profiles and the key bindings.

The issue that DHowett linked to, #2933, looks to me like it's more similar to what I'm asking for, and it too seems like a good idea to me, but it doesn't seem to be exactly what I'm asking for either. I don't want a way to use Roaming, which I'm totally uninterested in. And I also don't want a way (like a symlink) to trick the single hardcoded location of the settings.json file into being a different file. I want a way to get rid of the assumption that there is a single hardcoded location of the settings.json file in the first place.

It seems to me like a command line parameter would be a great way to do this. Just a simple "-c MySettings.json". If the option is not specified, default to what is currently the single hardcoded location of the settings.json file. That seems to me like it would be clean, flexible, usable, and maintainable.

And to be clear, I don't mean to imply that this should be done instead of the other suggestions. I think it should be done in addition to them.

@rwv37 commented on GitHub (Jun 26, 2020): I might be misunderstanding something here, but it doesn't seem to me like #5465 is what I'm asking for. That looks like it's asking for a better way to specify startup commands (like ``split-pane`` and such). I think that's a good idea too, but it's not what I'm asking for. What I'm asking for is a way to specify, on the command line, the location of the startup configuration file -- i.e. the file where you define things like the profiles and the key bindings. The issue that DHowett linked to, #2933, looks to me like it's more similar to what I'm asking for, and it too seems like a good idea to me, but it doesn't seem to be exactly what I'm asking for either. I don't want a way to use Roaming, which I'm totally uninterested in. And I also don't want a way (like a symlink) to trick the single hardcoded location of the settings.json file into being a different file. I want a way to *get rid of the assumption that there is a single hardcoded location of the settings.json file in the first place*. It seems to me like a command line parameter would be a great way to do this. Just a simple "-c MySettings.json". If the option is not specified, default to what is currently the single hardcoded location of the settings.json file. That seems to me like it would be clean, flexible, usable, and maintainable. And to be clear, I don't mean to imply that this should be done *instead of* the other suggestions. I think it should be done *in addition* to them.

claunia commented

@zadjii-msft commented on GitHub (Jun 26, 2020):

Okay that's what I get for reading issues before coffee. That's a great explanation, and I'm gonna toss this on the backlog. Thanks for following up!

@zadjii-msft commented on GitHub (Jun 26, 2020): Okay that's what I get for reading issues before coffee. That's a great explanation, and I'm gonna toss this on the backlog. Thanks for following up!

claunia commented

@DHowett commented on GitHub (Jun 26, 2020):

This is subject to the same problems outlined in https://github.com/microsoft/terminal/issues/4566#issuecomment-613102437 -- except with a -c instead of an environment variable. Until we have good answers to those questions, this feature cannot make forward progress.

In addition to the list in there, I have to add:

How do you control which config file the shell extension uses to populate its list of profiles, when it inevitably does that?
How about the taskbar jump list (#576)?

@DHowett commented on GitHub (Jun 26, 2020): This is subject to the same problems outlined in https://github.com/microsoft/terminal/issues/4566#issuecomment-613102437 -- except with a `-c` instead of an environment variable. Until we have good answers to those questions, this feature cannot make forward progress. In addition to the list in there, I have to add: * How do you control which config file the shell extension uses to populate its list of profiles, when it inevitably does that? * How about the taskbar jump list (#576)?

claunia commented

2026-01-31 01:50:44 +00:00

@rwv37 commented on GitHub (Jun 26, 2020):

I don't understand the issues being referred to, so I have no comment on them. However, I do want to say that this proposal is not (in effect) the same as supporting an environment variable, as a command line option would allow you to easily have different profiles for different purposes -- which you may even want to use simultaneously -- without the need to keep reconfiguring things. For example, you can make one shortcut with "wt -c MyHomeSettings.json" and another shortcut with "wt -c MyWorkSettings.json".

To be clear, I don't mean to imply that you were claiming that; I just wanted to be explicit about this difference.

@rwv37 commented on GitHub (Jun 26, 2020): I don't understand the issues being referred to, so I have no comment on them. However, I do want to say that this proposal is not (in effect) the same as supporting an environment variable, as a command line option would allow you to easily have different profiles for different purposes -- which you may even want to use simultaneously -- without the need to keep reconfiguring things. For example, you can make one shortcut with "wt -c MyHomeSettings.json" and another shortcut with "wt -c MyWorkSettings.json". To be clear, I don't mean to imply that you were claiming that; I just wanted to be explicit about this difference.

claunia commented

@DHowett commented on GitHub (Jun 26, 2020):

No, I understand. I'm trying to figure out how this works with other features we have planned:

Terminal will automatically manage the jump list (the thing that shows up when you right-click the icon in the taskbar) (#576).
- If you can launch it with an alternate config file, we need to figure out which config file's profiles end up in the jump list.
There's a shell extension that adds "open in windows terminal" to the right-click menu in File Explorer. We have plans to add a list of profiles to a flyout menu there.
- If you can prefer an alternate config file, we need to figure out which config file's profiles end up in the shell extension.
We're planning on allowing one instance of wt.exe to control another one, so you can open a new tab or split a new pane in a preexisting window or launch a new tab from the background into an existing window.
- If you launch a new instance (wt -n or whatever) from an instance that was started with -c, but without -c on the new instance, which config file does it use? The one from the instance that spawned it?
- If you launch two instances with different config files, we need to make sure they're completely isolated (because you can't open one config file's profiles in a WT instance that is not hosting that config file.)

We had another request for setting the config file path with an environment variable. The same questions need to be answered regardless of where the config file path comes from.

@DHowett commented on GitHub (Jun 26, 2020): No, I understand. I'm trying to figure out how this works with other features we have planned: * Terminal will automatically manage the jump list (the thing that shows up when you right-click the icon in the taskbar) (#576). * If you can launch it with an alternate config file, we need to figure out _which config file's profiles end up in the jump list_. * There's a shell extension that adds "open in windows terminal" to the right-click menu in File Explorer. We have plans to add a list of profiles to a flyout menu there. * If you can prefer an alternate config file, we need to figure out _which config file's profiles end up in the shell extension_. * We're planning on allowing one instance of `wt.exe` to control another one, so you can open a new tab or split a new pane in a preexisting window or launch a new tab from the background into an existing window. * If you launch a new instance (`wt -n` or whatever) from an instance that was started with `-c`, but without `-c` on the new instance, which config file does it use? The one from the instance that spawned it? * If you launch two instances with different config files, we need to make sure they're completely isolated (because you can't open one config file's profiles in a WT instance that is not hosting that config file.) We had another request for setting the config file path with an environment variable. The same questions need to be answered regardless of where the config file path comes from.

claunia commented

2026-01-31 01:50:44 +00:00

@rwv37 commented on GitHub (Jun 26, 2020):

I obviously don't have a good grasp on the overall plans, so take this with a grain of salt, but for what it's worth, here are some suggestions:

(1) For starting wt from an instance of wt, I don't see why it wouldn't just obey the command you type, exactly as it would if you had instead typed it via a Run prompt, via cmd, or whatever. So, like, if I started up with wt -c x, and in that window I type wt, it should start the new one up with the default. If I type wt -c x, it should start the new one with x. And if I type wt -c y, it should start the new one up with y. How I started the one that I'm typing in doesn't really seem to me like it should be involved at all.

(2) For the jump list/shell extension stuff, when right-clicking, I guess you're saying something like this menu would pop open:

Powershell
cmd
Azure

Maybe instead:

Powershell
cmd
Azure
-----
Config files ➡️

And "Config files" flies out to a submenu, which is initially:

☑️ (Default) ➡️
-----
Add or remove config files

After you add a couple config files, that submenu would now be:

☑️ (Default) ➡️
Personal.json ➡️
Work.json ➡️
-----
Add or remove config files

Each of the items in that submenu would fly out to a list of profiles from that particular config file.

And if you change that submenu so that something other than "(Default)" is checked...

(Default) ➡️
☑️ Personal.json ➡️
Work.json ➡️
-----
Add or remove config files

... then the top menu changes to list the profiles in that particular config file instead of those in the default config file:

Home Powershell
Home VS2019
Home ssh blah.com
-----
Config files ➡️

@rwv37 commented on GitHub (Jun 26, 2020): I obviously don't have a good grasp on the overall plans, so take this with a grain of salt, but for what it's worth, here are some suggestions: (1) For starting wt from an instance of wt, I don't see why it wouldn't just obey the command you type, exactly as it would if you had instead typed it via a Run prompt, via cmd, or whatever. So, like, if I started up with ``wt -c x``, and in that window I type ``wt``, it should start the new one up with the default. If I type ``wt -c x``, it should start the new one with x. And if I type ``wt -c y``, it should start the new one up with y. How I started the one that I'm typing in doesn't really seem to me like it should be involved at all. (2) For the jump list/shell extension stuff, when right-clicking, I guess you're saying something like this menu would pop open: - Powershell - cmd - Azure Maybe instead: - Powershell - cmd - Azure - \----- - Config files ➡️ And "Config files" flies out to a submenu, which is initially: - ☑️ (Default) ➡️ - \----- - Add or remove config files After you add a couple config files, that submenu would now be: - ☑️ (Default) ➡️ - Personal.json ➡️ - Work.json ➡️ - \----- - Add or remove config files Each of the items in that submenu would fly out to a list of profiles from that particular config file. And if you change that submenu so that something other than "(Default)" is checked... - (Default) ➡️ - ☑️ Personal.json ➡️ - Work.json ➡️ - \----- - Add or remove config files ... then the top menu changes to list the profiles in that particular config file instead of those in the default config file: - Home Powershell - Home VS2019 - Home ssh blah.com - \----- - Config files ➡️

claunia commented

2026-01-31 01:50:44 +00:00

@DHowett commented on GitHub (Jun 26, 2020):

How I started the one that I'm typing in doesn't really seem to me like it should be involved at all.

A significant portion of our userbase would beg to differ 😄

A lot of folks want wt new-tab or wt split-pane to open a new tab or split a new pane in the same window they're currently using. That's a totally valid use case that we'll need to address if we want to offer a -c option.

@DHowett commented on GitHub (Jun 26, 2020): > How I started the one that I'm typing in doesn't really seem to me like it should be involved at all. A significant portion of our userbase would beg to differ :smile: A lot of folks want `wt new-tab` or `wt split-pane` to open a new tab or split a new pane _in the same window they're currently using._ That's a totally valid use case that we'll need to address if we want to offer a `-c` option.

claunia commented

@DHowett commented on GitHub (Jun 26, 2020):

Just so it's clear: i'm not asking you to answer these questions and justify your feature. They're just things that we'll need to have an answer for to go ahead with it. This is, as always, an open forum for the community!

@DHowett commented on GitHub (Jun 26, 2020): Just so it's clear: i'm not asking you to answer these questions and justify your feature. They're just things that we'll _need to have an answer for_ to go ahead with it. This is, as always, an open forum for the community!

claunia commented

@Gram-1 commented on GitHub (Jul 14, 2020):

Hello, the ability do use different 'settings.json' is absolutely necessary for me too ! We need to be able to list different profile entries or different default initial rows/cols for different usages.
I fully support a new command line parameter as well as the ability to change the default json file location/name.
Rgds

@Gram-1 commented on GitHub (Jul 14, 2020): Hello, the ability do use different 'settings.json' is absolutely necessary for me too ! We need to be able to list different profile entries or different default initial rows/cols for different usages. I fully support a new command line parameter as well as the ability to change the default json file location/name. Rgds

claunia commented

@Guiorgy commented on GitHub (Aug 18, 2020):

An interesting proposal, but what happens in those cases:

wt ; -c othersettings.json
wt -c othersettings.json ; -c otherothersettings.json
wt ; split-pane -c othersettings.json ; split-pane -c otherothersettings.json

would you be able to have different settings for individual tabs/panes?

@Guiorgy commented on GitHub (Aug 18, 2020): An interesting proposal, but what happens in those cases: - `wt ; -c othersettings.json` - `wt -c othersettings.json ; -c otherothersettings.json` - `wt ; split-pane -c othersettings.json ; split-pane -c otherothersettings.json` would you be able to have different settings for individual tabs/panes?

claunia commented

@Gram-1 commented on GitHub (Aug 18, 2020):

Hello, thanks for your interest in my proposal !
My idea was initially just to be able to start two (or more) different
instances of wt.exe with different settings.
Regarding the behavior of wt with multiple tabs/panes, we could either use
a lazy approach using the provided settings as they come, only the last
being active in the end, like it's the case when you modify the settings
file while the terminal runs, causing the new version to be dynamically
reloaded and used for all panes.
A less lazy approach would be to allow different settings for tabs/panes
but it would suppose a much larger development effort I guess, and it's not
really compatible with the current behavior where you chose a new tab from
a list defined in the settings file itself !
I thank you again and stays open for any help I can provide
Regards
Olivier

@Gram-1 commented on GitHub (Aug 18, 2020): Hello, thanks for your interest in my proposal ! My idea was initially just to be able to start two (or more) different instances of wt.exe with different settings. Regarding the behavior of wt with multiple tabs/panes, we could either use a lazy approach using the provided settings as they come, only the last being active in the end, like it's the case when you modify the settings file while the terminal runs, causing the new version to be dynamically reloaded and used for all panes. A less lazy approach would be to allow different settings for tabs/panes but it would suppose a much larger development effort I guess, and it's not really compatible with the current behavior where you chose a new tab from a list defined in the settings file itself ! I thank you again and stays open for any help I can provide Regards Olivier

claunia commented

@Guiorgy commented on GitHub (Aug 18, 2020):

it's not really compatible with the current behavior where you chose a new tab from a list defined in the settings file itself

This is basically my concern too. So in the end either all -c argument would have to be ignored except for one, or -c should only be allowed after wt and not after the ;?

@Guiorgy commented on GitHub (Aug 18, 2020): > it's not really compatible with the current behavior where you chose a new tab from a list defined in the settings file itself This is basically my concern too. So in the end either all `-c` argument would have to be ignored except for one, or `-c` should only be allowed after `wt` and not after the `;`?

claunia commented

@Gram-1 commented on GitHub (Aug 18, 2020):

Yes, that's what I was thinking of, only allowed after wt would suffice.
Olivier

@Gram-1 commented on GitHub (Aug 18, 2020): Yes, that's what I was thinking of, only allowed after wt would suffice. Olivier

claunia commented

@red55 commented on GitHub (Oct 4, 2020):

Hi everyone,
My 5 cents on this issue. I have about 20 PCs and VMs where I'm using Windows Terminal. For me it's a headache to synchronize the things like font face, font size and so on. Giving me a -c option will solve my problem. More over if I could synchronize settings.json via Microsoft's or Company account like it happens with Edge's settings or VS code settings, it would be really great

@red55 commented on GitHub (Oct 4, 2020): Hi everyone, My 5 cents on this issue. I have about 20 PCs and VMs where I'm using Windows Terminal. For me it's a headache to synchronize the things like font face, font size and so on. Giving me a -c option will solve my problem. More over if I could synchronize settings.json via Microsoft's or Company account like it happens with Edge's settings or VS code settings, it would be really great

claunia commented

@jmlucjav commented on GitHub (Feb 13, 2021):

I have now realized there is an ever bigger reason for me to need a custom settings.json when I am going to use wt just to host neovim, as I have C-v etc for normal terminal usage, that combination is handled by wt instead of neovim, where it would be the visual block mode (which I was wondering why it was not working). This makes using wt to host neovim quite a big issue.

@jmlucjav commented on GitHub (Feb 13, 2021): I have now realized there is an ever bigger reason for me to need a custom settings.json when I am going to use wt just to host neovim, as I have C-v etc for normal terminal usage, that combination is handled by wt instead of neovim, where it would be the visual block mode (which I was wondering why it was not working). This makes using wt to host neovim quite a big issue.

claunia commented

@DanielLaberge commented on GitHub (Feb 9, 2022):

Please consider making this issue higher priority.

I suspect a lot of users are suffering from this pain point: they work on multiple machines and currently have no means of loading profiles from one shared location like OneDrive or Dropbox, etc. Having to manually copy and paste profiles across all our machines, everything something is added or changed is frustrating and shouldn't be required in this day and age.

The amount of comments and duplicated issues in this and #2933 should be a good indication of the interest.

@DanielLaberge commented on GitHub (Feb 9, 2022): Please consider making this issue higher priority. I suspect a lot of users are suffering from this pain point: they work on multiple machines and currently have no means of loading profiles from one shared location like OneDrive or Dropbox, etc. Having to manually copy and paste profiles across all our machines, everything something is added or changed is frustrating and shouldn't be required in this day and age. The amount of comments and duplicated issues in this and #2933 should be a good indication of the interest.

claunia commented