If the plugin configuration was specified as a closure, the engine will evaluate that closure and return the result, which may cause an [error response](#error-engine-call-response).
Example:
```json
{
"EngineCall": {
"context": 3,
"id": 8,
"call": "GetPluginConfig"
}
}
```
#### `GetEnvVar` engine call
Get an environment variable from the caller's scope. Returns a [`PipelineData` response](#pipelinedata-engine-call-response) if successful, which will contain either a [`Value`](#value-header-variant) or be [`Empty`](#empty-header-variant) if the environment variable is not present.
Example:
```json
{
"EngineCall": {
"context": 7,
"id": 41,
"call": {
"GetEnvVar": "PATH"
}
}
}
```
#### `GetEnvVars` engine call
Get all environment variables from the caller's scope. Returns a [`ValueMap` response](#valuemap-engine-call-response) if successful, with all of the environment variables in the scope.
Example:
```json
{
"EngineCall": {
"context": 9,
"id": 72,
"call": "GetEnvVars"
}
}
```
#### `GetCurrentDir` engine call
Get the current directory path in the caller's scope. This always returns an absolute path as a string [`Value` pipeline data](#value-header-variant) response if successful. The span contained within the value response is unlikely to be useful, and may be zero.
Example:
```json
{
"EngineCall": {
"context": 7,
"id": 40,
"call": "GetCurrentDir"
}
}
```
#### `AddEnvVar` engine call
Set an environment variable in the caller's scope. The environment variable can only be propagated to the caller's scope if called before the plugin call response is sent. Either way, it is propagated to other engine calls made within the same context. The argument is a 2-tuple: (`name`, `value`). The response type is [`Empty` pipeline data](#empty-header-variant) when successful.
Example:
```json
{
"EngineCall": {
"context": 7,
"id": 42,
"call": {
"AddEnvVar": [
"FOO",
{
"String": {
"val": "bar",
"span": {
"start": 2020,
"end": 2024
}
}
}
]
}
}
}
```
#### `GetHelp` engine call
Get fully formatted help text for the current command. This can help with implementing top-level commands that just list their subcommands, rather than implementing any specific functionality. The response on success is [`Value` pipeline data](#value-header-variant) that always contains a string.
Example:
```json
{
"EngineCall": {
"context": 1,
"id": 2,
"call": "GetHelp"
}
}
```
#### `EnterForeground` engine call
Moves the plugin to the foreground group for direct terminal access, in an operating system-defined manner. This should be called when the plugin is going to drive the terminal in raw mode, for example to implement a terminal UI. It will likely be necessary for the plugin to also be running in [local socket mode](#localsocket-feature) in that case.
This call responds with [`Empty` pipeline data](#empty-header-variant) on success when no action is required by the plugin. On Unix-like operating systems, if the response is [`Value` pipeline data](#value-header-variant), it contains an [`Int`](#int) which is the process group ID the plugin must join using `setpgid()` in order to be in the foreground.
This call will fail with an error if the plugin is already in the foreground.
The plugin **should** call [`LeaveForeground`](#leaveforeground-engine-call) when it no longer needs to be in the foreground. Note that the plugin will also automatically be removed from the foreground when the plugin call response is received, even if the plugin call returns a stream.
Example:
```json
{
"EngineCall": {
"context": 0,
"id": 0,
"call": "EnterForeground"
}
}
```
#### `LeaveForeground` engine call
Resets the state set by [`EnterForeground`](#enterforeground-engine-call).
If the plugin had been requested to change process groups by the response of `EnterForeground`, it should also reset that state by calling `setpgid(0)`, since plugins are normally in their own process group.