I *can* use syscall.Exec (really unix.Exec), and I am right now. The
question was about avoiding all the boilerplate syscalls that go along
with it that {os,syscall}.StartProcess take care of.Perhaps it would indeed be rarely used. I've wanted it at least twice, personally. It seems like the main problem is that exec isn't exactly a well-defined cross-platform concept. Aram suggested that instead of os it should be in syscall, though I suppose x/sys/unix is more appropriate these days. I'll try implementing this function in my own package first. Thanks for the feedback. On Tue, Aug 21, 2018 at 3:15 PM Ian Lance Taylor <i...@golang.org> wrote: > > On Tue, Aug 21, 2018 at 12:49 AM, Caleb Spare <cesp...@gmail.com> wrote: > > > > I was recently trying to write a Go program that's something like chpst or > > setpriv: it execs another program with an altered process state by changing > > the user ID or modifying the ambient capabilities. (My program is > > Linux-specific.) > > > > In Go, when you want to spawn another process (fork+exec in Posix-land) you > > have the option of a very high-level API in os/exec or a lower-level API in > > the form of os.StartProcess. But os.StartProcess still does a lot of work. > > In my program where I need to exec without forking, I did not have the > > benefit of either os/exec or os.StartProcess, and I ended up having to copy > > Linux-specific code from the syscall package here: > > > > https://github.com/golang/go/blob/187a41dbf730117bd52f871009466a9679d6b718/src/syscall/exec_linux.go#L104 > > > > If I wanted to fork+exec, then I could've implemented my features easily by > > using the fields in the platform-specific syscall.SysProcAttr. However, > > because I wanted to exec only, no easy options were available to me, and my > > code ended up doing about a dozen raw syscalls, using runtime.LockOSThread, > > using unsafe, and being generally unpleasant. > > > > My question is: would it make sense to add an API similar to os.StartProcess > > for exec-without-fork? For now I'm just wondering if there is any > > showstopper that makes this unreasonable; if there isn't then I'll file a > > proposal with more details. > > > > Here are two potential problems that I considered: > > > > 1. Is exec-without-fork fundamentally at odds with Go and its runtime > > somehow, like fork-without-exec is? I don't see why that would be the case. > > 2. Is the concept of exec-without-fork incoherent on non-Posix systems? I > > mainly worry about Windows; after some brief googling it did seem like you > > can exec on Windows, though I admit the situation isn't at all clear to me. > > > > So am I missing any reason why an os.StartProcess-like API for exec-ing > > would be untenable? > > I think that API would be very rarely used. The number of programs > that need to exec-without-fork, and that can not simply use > syscall.Exec, is very small. Those programs tend to be highly > system-specific. I don't think such an API would be appropriate for > the os package. > > Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
