docker segment or command segment with current shell type

[GethDeeo]

Code of Conduct

• I agree to follow this project's Code of Conduct

What would you like to see changed/added?

I would like to have a docker segment to show current context, like this:
docker context show

Now I know the command segment can be configured easily for this, but I've a small problem with that.
I use the same configuration across different platforms (Windows, Linux), so I may not be able to come up with a single selected shell that works across these.
Right now, the default bash works on my Windows system, but only because I've WSL installed, and .docker configuration shared with it. But I may come across a different system, where WSL is not present.
Is there a way to use the current running shell or a new instance of it in case of command segment?

[GethDeeo]

Thanks for the quick segment impl :)
I have some odd problems though...

I've configured it on both Windows and Linux. On both systems I have Docker configuration (with active non-default context) in usual ~/.docker folder, and I do not use DOCKER_* environment variables.
I only get the (otherwise correct) docker segment enabled on Windows, if I change directory to one with a valid config.json in it. (I've realized that after I've copied that file from my .docker directory).
On Linux it's not enabled at all.
Both OS works correctly (segment enabled regardless of working directory) if I set DOCKER_CONTEXT.
Odd, huh?

(Btw, could the default context trigger the segment as well (maybe with configuration)? I don't mind the segment being always enabled on systems where I have Docker "configured".)

[JanDeDobbeleer]

@GethDeeo could you share the output of oh-my-posh debug for the broken case? I probably made a silly mistake.

[GethDeeo]

Here is an excerpt of it, I think that would be enough (version is of course 14.12.0):

[DEBUG] 20:27:14.365 shell.go:Getenv:381 → NO DATA
[TRACE] 20:27:14.365 shell.go:Getenv(DOCKER_MACHINE_NAME) - 0s
[DEBUG] 20:27:14.365 shell.go:Getenv:381 → NO DATA
[TRACE] 20:27:14.365 shell.go:Getenv(DOCKER_HOST) - 0s
[DEBUG] 20:27:14.365 shell.go:Getenv:381 → NO DATA
[TRACE] 20:27:14.365 shell.go:Getenv(DOCKER_CONTEXT) - 0s
[DEBUG] 20:27:14.365 shell_windows.go:56 → C:\Users\geth
[DEBUG] 20:27:14.365 shell.go:Getenv:381 → NO DATA
[TRACE] 20:27:14.365 shell.go:Getenv(DOCKER_CONFIG) - 0s
[DEBUG] 20:27:14.365 shell.go:Pwd:389 → C:\Users\geth
[TRACE] 20:27:14.365 shell.go:Pwd() - 0s
[TRACE] 20:27:14.365 shell.go:HasFiles(C:\Users\geth\.docker\config.json) - 0s
[DEBUG] 20:27:14.365 shell.go:Pwd:389 → C:\Users\geth
[TRACE] 20:27:14.365 shell.go:Pwd() - 0s
[TRACE] 20:27:14.366 shell.go:HasFiles(\config.json) - 551.1µs
[DEBUG] 20:27:14.366 shell.go:Pwd:389 → C:\Users\geth
[TRACE] 20:27:14.366 shell.go:Pwd() - 0s

Particularly this line is interesting:
[TRACE] 20:27:14.366 shell.go:HasFiles(\config.json) - 551.1µs

It's the same on Linux: first HasFiles call appears with path, second one does not.

[JanDeDobbeleer]

@GethDeeo did some check, we validate the presence of the DOCKER_CONFIG environment variable, as that doesn't have a value which results in the plain path. I'm going to adjust that. As far as I can see, there's no data that helps us identify the docker context.