fish-shell/exec.h
ridiculousfish 4899086b3c Big fat refactoring of how redirections work. In fish 1.x and 2.0.0, the redirections for a process were flattened into a big list associated with the job, so there was no way to tell which redirections applied to each process. Each process therefore got all the redirections associated with the job. See https://github.com/fish-shell/fish-shell/issues/877 for how this could manifest.
With this change, jobs only track their block-level redirections. Process level redirections are correctly associated with the process, and at exec time we stitch them together (block, pipe, and process redirects).

This fixes the weird issues where redirects bleed across pipelines (like #877), and also allows us to play with the order in which redirections are applied, since the final list is constructed right before it's needed.  This lets us put pipes after block level redirections but before process level redirections, so that a 2>&1-type redirection gets picked up after the pipe, i.e. it should fix https://github.com/fish-shell/fish-shell/issues/110

This is a significant change. The tests all pass. Cross your fingers.
2013-08-19 18:06:24 -07:00

82 lines
2.5 KiB
C++

/** \file exec.h
Prototypes for functions for executing a program
*/
#ifndef FISH_EXEC_H
/**
Header guard
*/
#define FISH_EXEC_H
#include <wchar.h>
#include <vector>
#include "proc.h"
#include "util.h"
#include "common.h"
/**
pipe redirection error message
*/
#define PIPE_ERROR _(L"An error occurred while setting up pipe")
/**
Execute the processes specified by j.
I've put a fair bit of work into making builtins behave like other
programs as far as pipes are concerned. Unlike i.e. bash, builtins
can pipe to other builtins with arbitrary amounts of data, and so
on. To do this, after a builtin is run in the real process, it
forks and a dummy process is created, responsible for writing the
output of the builtin. This is surprisingly cheap on my computer,
probably because of the marvels of copy on write forking.
This rule is short circuited in the case where a builtin does not
output to a pipe and does in fact not output anything. The speed
improvement from this optimization is not noticable on a normal
computer/OS in regular use, but the promiscous amounts of forking
that resulted was responsible for a huge slowdown when using
Valgrind as well as when doing complex command-specific
completions.
*/
class parser_t;
void exec_job(parser_t &parser, job_t *j);
/**
Evaluate the expression cmd in a subshell, add the outputs into the
list l. On return, the status flag as returned bu \c
proc_gfet_last_status will not be changed.
\param cmd the command to execute
\param outputs The list to insert output into.
\return the status of the last job to exit, or -1 if en error was encountered.
*/
int exec_subshell(const wcstring &cmd, std::vector<wcstring> &outputs, bool preserve_exit_status);
int exec_subshell(const wcstring &cmd, bool preserve_exit_status);
/**
Loops over close until the syscall was run without being
interrupted. Then removes the fd from the open_fds list.
*/
void exec_close(int fd);
/**
Call pipe(), and add resulting fds to open_fds, the list of opend
file descriptors for pipes.
*/
int exec_pipe(int fd[2]);
/* Close all fds in open_fds. This is called from postfork.cpp */
void close_unused_internal_pipes(const io_chain_t &io);
/* Gets all unused internal pipes into fds */
void get_unused_internal_pipes(std::vector<int> &fds, const io_chain_t &io);
/** Gets the interpreter for a given command */
char *get_interpreter(const char *command, char *interpreter, size_t buff_size);
#endif