expose libuv windows verbatim and hidden process spawning #13780
Conversation
| `cmd` will normally create a new console window to display its output. | ||
| The `windows_hide` function suppresses that console window. | ||
| """ | ||
| windows_hide(cmd::Cmd) = Cmd(cmd; flags = cmd.flags | UV_PROCESS_WINDOWS_HIDE) |
There was a problem hiding this comment.
rather than exposing this as a new function, I was considering making this an official API for Cmd:
Cmd(cmd; detach = false, windows_hide = true)thoughts?
There was a problem hiding this comment.
Sounds reasonable. Deprecate the old detach API, or keep it around since detaching is pretty common?
stevengj
force-pushed
the
windows_cmd_flags
branch
from
8ebb802
to
992219b
Compare
|
Okay, updated so that you now do Do we want to deprecate |
| @@ -1316,6 +1316,8 @@ export | |||
| setenv, | |||
| spawn, | |||
| success, | |||
| windows_hide, | |||
There was a problem hiding this comment.
no longer a function so shouldn't be exported?
stevengj
force-pushed
the
windows_cmd_flags
branch
3 times, most recently
from
43f24c3
to
1806690
Compare
| immutable Cmd <: AbstractCmd | ||
| exec::Vector{ByteString} | ||
| ignorestatus::Bool | ||
| detach::Bool | ||
| flags::UInt8 # libuv process flags |
There was a problem hiding this comment.
why UInt8, when it's int in jl_uv.c?
There was a problem hiding this comment.
Because there are < 8 bits of flags, why store more?
There was a problem hiding this comment.
today. will there always be < 8 bits of flags? not very future proof to pick the smallest possible number
There was a problem hiding this comment.
If we change it to support additional flags at some distant future time when libuv uses more than 8 bits of flags, we can always change the flags variable type.
Unless there is some reason that we don't want sizeof(Cmd) to ever change?
This is not like a C library where there is an ABI stability issue, no?
There was a problem hiding this comment.
It is potentially subtly breaking to change sizes of internal fields. People generally shouldn't be messing with internal fields, but I still lean towards being a bit more future proof than worrying about conserving 3 bytes.
There was a problem hiding this comment.
Okay, I changed it. I think it's a bit pointless to worry about ABI stability in this context, but 3 bytes are not worth arguing about.
stevengj
force-pushed
the
windows_cmd_flags
branch
from
1806690
to
f5063de
Compare
|
Okay to merge? |
| new console window is displayed when the `Cmd` is executed. This has | ||
| no effect if a console is already open or on non-Windows systems. | ||
| * `env`: Set environment variables to use when running the `Cmd`. `env` | ||
| is either a dictionary mapping strings to strings, an array |
There was a problem hiding this comment.
spacing's a little odd here
looks ok otherwise
stevengj
force-pushed
the
windows_cmd_flags
branch
from
f5063de
to
300a868
Compare
expose libuv windows verbatim and hidden process spawning
|
it should be good to have this exposed. we can develop it further on master if anyone runs into problems. |
This fixes #13776 by exporting a
windows_verbatimoption toCmd(cmd; keywords...)to enable verbatim arguments when spawning windows commands, for processes that don't parse embedded quotes.I also noticed another potentially useful libuv process flag on windows, which I exported as a
windows_hideflag inCmd. This allows you to spawn Windows processes without popping up a console window, which is obviously useful for GUI programs etc.