eidheim / tiny-process-library

A small platform independent library making it simple to create and stop new processes in C++, as well as writing to stdin and reading from stdout and stderr of a new process

This project has moved to https://gitlab.com/eidheim/tiny-process-library.

tiny-process-library

A small platform independent library making it simple to create and stop new processes in C++, as well as writing to stdin and reading from stdout and stderr of a new process.

This library was created for, and is used by the C++ IDE project juCi++.

Features

• No external dependencies
• Simple to use
• Platform independent
  • Creating processes using executables is supported on all platforms
  • Creating processes using functions is only possible on Unix-like systems
• Read separately from stdout and stderr using anonymous functions
• Write to stdin
• Kill a running process (SIGTERM is supported on Unix-like systems)
• Correctly closes file descriptors/handles

Usage

See examples.cpp.

Get, compile and run

Unix-like systems

git clone http://gitlab.com/eidheim/tiny-process-library
cd tiny-process-library
mkdir build
cd build
cmake ..
make
./examples

Windows with MSYS2 (https://msys2.github.io/)

git clone http://gitlab.com/eidheim/tiny-process-library
cd tiny-process-library
mkdir build
cd build
cmake -G"MSYS Makefiles" ..
make
./examples

tiny-process-library's Issues

Specify Process Priority

Hi, I'd like to specify a priority when launching a process. For example, I want to launch a background process with a lower process priority than the main process. As of right now, new processes are spawned with the default priority class and tiny process library does not give us the ability to control that.

On Windows, we provide a priority class flag in the 'dwCreationFlags' parameter to CreateProcess as specified here:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx

I'm assuming *nix has a similar mechanism.

I could create a PR if you'd like; though the implementation seems fairly straight forward.

Thank you

Tom

Request minimum needed access rights in Process::kill() on Windows

Requesting PROCESS_ALL_ACCESS is excessive. Since you only call TerminateProcess() on the opened HANDLE, you should request PROCESS_TERMINATE.

program output not captured when program does not exist or didn't run "succesfully"

Tested on: Windows 7
Description: Cannot get process output when process cannot be created (or process didn't run "succesfully")
Code:

	Process process(options.Combine(), "", [](const char *bytes, size_t n) {
		std::cout << "xxyy" << std::string(bytes, n) << "yyxx" << std::endl;
	}, [](const char *bytes, size_t n) {
		std::cout << "xxyy" << std::string(bytes, n) << "yyxx" << std::endl;
	});

Identified cause in source code (process_win.cpp:106):

  ....
  BOOL bSuccess = CreateProcess(nullptr, process_command.empty()?nullptr:&process_command[0], nullptr, nullptr, TRUE, 0,
                                nullptr, path.empty()?nullptr:path.c_str(), &startup_info, &process_info);

  if(!bSuccess) {
    CloseHandle(process_info.hProcess);
    CloseHandle(process_info.hThread);
    return 0; // here it stops and doesn't proceed to fire the lambda's to capture output
  }
  else {
    CloseHandle(process_info.hThread);
  }

  if(stdin_fd) *stdin_fd=stdin_wr_p.detach();
  if(stdout_fd) *stdout_fd=stdout_rd_p.detach();
  if(stderr_fd) *stderr_fd=stderr_rd_p.detach();
  ....

Suggested fix:

Fire the lambda's with captured output either way (even if bSuccess == false). It's the callers responsibility to check the exit code anyway, and a separate "binary doesn't exist" code can be emitted.

Detach a process?

Can this lib be used to start a process and then let it run while the parent exits?

Exit on Process::write on linux

I have a problem not reliable getting outputs.
A workaround i found is, sending "\n" via Process::write

My Problem now is, that if the process exits write causes a crash. (my program just exits without any error message or exception). I added log messages before and after the actual write call and the after message is never printed.

I do a pid check before the actual write, but i still have the exit.
My code is loosely based on Example 8, but with output buffer.

Any idea how to avoid the program to exit. Also any idea why the output is not really reliable?

C++ namespace?

I just realized the Process class is in the global namespace. Maybe one should be added, to limit scope, since "Process" is fairly generic.

Won't build with MSYS using Ninja generator

The issue is here:
https://github.com/eidheim/tiny-process-library/blob/master/CMakeLists.txt#L12

It errors out trying to build process_unix.cpp

The CMake variable MSYS must presumably only be set under the MSYS makefile generator, and not under the ninja generator when used in the MSYS environment. (I don't recall seeing it before, so I don't know how standard/common/reliable of a variable it is to use)

If you assume that the user must use MSYS2 and cannot use MinGW on its own, then you could generalize the check to if(WIN32) - this is probably the simplest, best solution at least in the short term.

Passing Environment

Please consider adding optional support for setting the environment variables on process creation.
On Windows: lpEnvironment
On Linux: execle instead of execl

CloseHandle called on invalid handles

tiny-process-library/process_win.cpp

Lines 110 to 111 in a034812

	CloseHandle(process_info.hProcess);
	CloseHandle(process_info.hThread);

These handles are invalid here and should not be closed. This will overwrite "GetLastError" with 6 = "Invalid Handle", so reading the error value to see what went wrong becomes impossible.

Close handles in both overloads of Process::kill() on Windows

Specifically, the HANDLE returned by CreateToolhelp32Snapshot() and the HANDLEs returned.by OpenProcess().

how can i set enviroment var for process?

how can i set enviroment var for process?how can i set enviroment var for process?

`<windows.h>` should not be exposed to users

<windows.h> is included on Windows in the header file. This is problematic for users, as <windows.h> has a bad reputation - for example, your calls to std::min() will stop working if it's included. The specific problem of non-working std::min be fixed by defining NOMINMAX, but there are many more #defines in there. The general problem can be fixed by using PIMPL idiom and moving away the #include <windows.h> to the implementation file.

Not all file descriptors/handles are yet closed correctly

See https://www.reddit.com/r/cpp/comments/3vpjqg/a_new_platform_independent_process_library_for_c11/, posts by nexuapex and Jardik.