This re-adds the close(source) call which already existed here before
commit caa7b2fcc8. pipe_out already closes the source fd when redirecting
stdout or stderr, it was just missing when redirecting both at once.
The pipe fds must be closed after redirecting to avoid keeping the pipe
open unnecessarily, for example the parent may want to close their end of
the pipe.
Closes: https://github.com/boostorg/process/issues/353
Signed-off-by: Daniel Klauer <daniel.klauer@gin.de>
_pipe_sink was assigned after call_on_setup(), after limit_fd_::on_setup(),
but this was too late. It must be assigned earlier so that
executor::get_used_handles() can see it and prevent limit_handles from
closing the internal pipe for passing exec() errors from child to parent.
Fixes: 1a1d677d
Closes: https://github.com/boostorg/process/issues/202
Signed-off-by: Daniel Klauer <daniel.klauer@gin.de>
On FreeBSD I would like to remove dependency on libprocstat completely, and replace it with libkvm to be more like the other *BSD platforms in terms of linker dependencies. This pull request is our first move in that direction.
Replace libprocstat with libkvm in cmd
In commit cbaa913e3d ("Merge branch 'develop' into limit_fd"), there
have been merge conflicts in two files. In pipe_out.hpp, a previous
commit from the "limit_fd" branch f8c0dd4da5 ("prototype for
limit_fd") had been eliminated during wrong conflict resolution.
The final result was, that file descriptors for stdout pipes were not
preserved when using limit_handles.
Example:
boost::asio::io_context io_context;
bp::async_pipe my_stdin(io_context);
bp::async_pipe my_stdout(io_context);
bp::child my_child("/usr/bin/echo", "Hello world",
bp::std_in < my_stdin, // preserved by limit_handles
bp::std_out > my_stdout, // closed by limit_handles
bp::std_err > stderr, // preserved by limit_handles
bp::limit_handles)
Fixes: cbaa913e3d ("Merge branch 'develop' into limit_fd")
* Fix V2::EXT::CWD [SunOS]
filesystem::canonical is basically the same thing as realpath on Unix-likes, which only resolves one symbolic link. If one symbolic link points to yet another symbolic link and so on and so forth, it will not resolve all symbolic links. It will only do one link for each call to canonical. On SunOS, unlike Linux, /proc/${pid}/cwd does not directly point to the literal current working directory of the given ${pid}. Instead, it will point to yet another symlink - /proc/${pid}/path/cwd which once you have followed that second link only then will you have the literal cwd path for the process id.
