foot/slave.h

#pragma once
#include <stdbool.h>

#include <sys/types.h>

#include "config.h"
#include "user-notification.h"

pid_t slave_spawn(
    int ptmx, int argc, const char *cwd, char *const *argv, const char *const *envp,
    const env_var_list_t *extra_env_vars, const char *term_env,
    const char *conf_shell, bool login_shell,
    const user_notifications_t *notifications);
Set up pseudo terminal and fork slave 2019-06-13 15:19:10 +02:00			`#pragma once`
			`#include <stdbool.h>`

term: move client startup to a new function, slave_spawn() 2019-10-30 18:05:03 +01:00			`#include <sys/types.h>`

config: add a new ‘environment’ section This section allows the user to define custom environment variables to be set in the child process: [environment] name=value 2022-05-28 19:27:29 +02:00			`#include "config.h"`
user-notification: 'productify' the user-warning system * Rename user_warning to user_notification * Add warning and error types (in addition to the existing deprecated) * Simplify logic when emitting a user notification after forking; we don't need to copy the notification data since we're in a new process and have total control over that memory. 2020-07-30 18:57:21 +02:00			`#include "user-notification.h"`
term: add capability to print warnings inside the terminal This is intended to be used to print e.g. deprecation warnings inside the terminal, before the shell is started. 2020-07-29 19:42:12 +02:00
term: move client startup to a new function, slave_spawn() 2019-10-30 18:05:03 +01:00			`pid_t slave_spawn(`
slave: don't skip setting environment variables when using a custom environment When launching footclient with -E,--client-environment the environment variables that should be set by foot, wasn't. Those variables are: * TERM * COLORTERM * PWD * SHELL and all variables defined by the user in the [environment] section in foot.ini. In the same way, we did not unset TERM_PROGRAM and TERM_PROGRAM_VERSION. This patch fixes it by "cloning" the custom environment, making it mutable, and then adding/removing the variables above from it. Instead of calling setenv()/unsetenv() directly, we add the wrapper functions add_to_env() and del_from_env(). When not using a custom environment, they simply call setenv()/unsetenv(). When we are using a custom environment, add_to_env() first loops all existing variables, looking for a match. If a match is found, it's updated with the new value. If it's not found, a new entry is added. del_from_env() loops all entries, and removes it when a match is found. If no match is found, nothing is done. The mutable environment is allocated on the heap, but never free:d. We don't need to free it, since it's only allocated after forking, in the child process. Closes #1568 2024-01-09 16:50:47 +01:00			`int ptmx, int argc, const char cwd, char const argv, const char const *envp,`
config: add a new ‘environment’ section This section allows the user to define custom environment variables to be set in the child process: [environment] name=value 2022-05-28 19:27:29 +02:00			`const env_var_list_t extra_env_vars, const char term_env,`
			`const char *conf_shell, bool login_shell,`
user-notification: 'productify' the user-warning system * Rename user_warning to user_notification * Add warning and error types (in addition to the existing deprecated) * Simplify logic when emitting a user notification after forking; we don't need to copy the notification data since we're in a new process and have total control over that memory. 2020-07-30 18:57:21 +02:00			`const user_notifications_t *notifications);`