[Tim re popen on Windows] ... > the debugger -- it's hung inside an MS DLL. "dir" is not entirely arbitrary > here: for *some* cmds it works fine, for others not. The set of which work > appears to vary across Windows flavors. Sometimes you can worm around it by > wrapping "a bad" cmd in a .bat file, and popen'ing the latter instead; but > sometimes not. It doesn't work for commands builtin to whatever "shell" you're using. That's different between cmd and command, and the various flavors, versions and extensions thereof. FWIW, I gave up a long time ago. I use redirection and a tempfile. The few times I've wanted "interactive" control, I've used Win32Process, dup'ed, inherited handles... the whole 9 yards. Why? Look at all the questions about popen and child processes in general, on platforms where it *works*, (if it weren't for Donn Cave, nobody'd get it to work anywhere <wink>). To reiterate Tim's point: *none* of the c runtime routines for process control on Windows are adequate (beyond os.system and living with a DOS box popping up). The raw Win32 CreateProcess does everything you could possibly want, but takes a week or more to understand, (if this arg is a that, then that arg is a whatsit, and the next is limited to the values X and Z unless...). your-brain-on-Windows-ly y'rs - Gordon
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4