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.

1 files changed, 6 insertions, 1 deletions

diff --git a/io.cpp b/io.cpp
index 2882a59a..1ee36e72 100644
--- a/io.cpp
+++ b/io.cpp
@@ -128,7 +128,7 @@ io_buffer_t *io_buffer_t::create(bool is_input, int fd)
     bool success = true;
     if (fd == -1)
     {
-        fd = is_input ? 0 : 1;
+        fd = is_input ? STDIN_FILENO : STDOUT_FILENO;
     }
     io_buffer_t *buffer_redirect = new io_buffer_t(fd, is_input);
 
@@ -208,6 +208,11 @@ void io_chain_t::push_front(const shared_ptr<io_data_t> &element)
     this->insert(this->begin(), element);
 }
 
+void io_chain_t::append(const io_chain_t &chain)
+{
+    this->insert(this->end(), chain.begin(), chain.end());
+}
+
 void io_remove(io_chain_t &list, const shared_ptr<const io_data_t> &element)
 {
     list.remove(element);