On Tue, 17 Jun 2025, Corinna Vinschen wrote: > On May 29 10:57, Jeremy Drake via Cygwin-patches wrote: > > stdin and stdout were alreadly allowed for popen, but implementing > > posix_spawn in terms of spawn would require stderr as well. > > --- > > winsup/cygwin/dcrt0.cc | 2 ++ > > winsup/cygwin/local_includes/child_info.h | 6 +++--- > > winsup/cygwin/spawn.cc | 5 +++-- > > 3 files changed, 8 insertions(+), 5 deletions(-) > > LGTM > > Thanks, > Corinna
OK, I could push this one, since it stands alone and I'm sure that it works because I have used it in the subsequent patch. The reason I haven't is that I am still trying to figure out if an additional change to child_info.h might be needed for (f)chdir, and I am trying to avoid making multiple changes to the CHILD_INFO_MAGIC. Let me know if this is not really a concern. My current thinking is that yes, something would need to be in child_info_spawn or cygheap_exec_info. I'm leaning towards an int dirfd, because I would need that anyway to deal with open actions after a chdir (using openat). My sticking point is considering how to deal with spawning a non-Cygwin process. a) I would need a wide Windows path for CreateProcessW, but fhandler doesn't expose its path_conv or get_nt_native_path, only get_name (get_posix) and get_win32_name (get_win32) which is narrow. Adding another accessor to fhandler_base probably wouldn't be too controversial. b) I would need the same logic as in cwdstuff::set to determine whether the dir is "legal" to use for a non-Cygwin app's cwd, and the error to report if it's not (cwdstuff::get_error_desc). I'm not a fan of copy-pasting code, so it will take some consideration of how to refactor that in a way that the code could be called by both. Suggestions appreciated. Maybe next week I can get back to these patches and button up more and get it to a point where it can be merged (especially if it's OK to leave adding (f)chdir changes for later).
