interp: consider some support for PIDs

[rhd]

Hi, I was playing around with go-task and I couldn't get this to work: sleep 10 & echo $!. It would only print a new line but not the PID of the sleep call. @andreynering suggested I post an issue here.

Any suggestions?

Thanks!

[mvdan]

This library is written in Go, so it can't spawn sub-processes. If I make $! work, it will always print the same as $$. That's part of the reason why I've been hesitant to add it.

I guess I could add it, but that behavior might confuse lots of people. I should add docs about these gotchas in the interpreter.

[rhd]

Yea, printing $$ is mostly useless. No way to use os/exec to spawn the process?

[mvdan]

How, exactly? os/exec executes programs. It does not allow forking alone, because it wouldn't work in Go. For example, see https://stackoverflow.com/questions/28370646/how-do-i-fork-a-go-process

The only portable and stable way to have multiple processes would be for the interpreter to run from a shell, say gosh, and then spawning subshells via exec.Command("gosh", ...). But the point of the interpreter is being embeddable into a binary, so you'd lose that. You'd also lose other features like controlling the interpreter via modules and the context.

There's also the question of why you'd need $$ and $! in the first place. If you want to write portable shell scripts, how can you safely use them for anything other than printing them?

All in all, I decided not to do it by default because it's too much hassle for little gain. However, I'm open to doing the option above - depending on its own shell executable - via an option like #171.

There's always the option of using virtual PIDs, to make it so that $$ and $! could be different among goroutines. But I presume that will open a can of worms.

[mvdan]

Ping, @rhd? Did you have an implementation idea in mind?

[mvdan]

Timed out after a month - still open to suggestions, but I see no clear way forward right now.

[Ckarles]

There's also the question of why you'd need $$ and $! in the first place. If you want to write portable shell scripts, how can you safely use them for anything other than printing them?

I'm not trying to reopen the issue, thought I can give you an answer regarding my current problem.

I would like to parallel build multiple things, and if one of them fail, exit !=0.
The only way I could think of as of now is to spawn subshells then wait, unfortunately wait is pretty basic, and if the return code of the subshell is needed (and it is in this case), wait has to be called with a the pid of the process which you want to return the pid from.

Therefore, without any indicator to point wait to, no return code can be gathered from a subshell.

[mvdan]

Thanks @Ckarles, that's a valid point. I'll reopen the issue for now.

One way we could possibly do this is by having "virtual" PIDs by default, where each PID just maps to one of the goroutines running an interpreter's subshell. Then, we could still have wait work for those.

We'd have to try to avoid conflicts between those per-goroutine PIDs and the real host system's PIDs, though. Maybe by making them start at a really big number, like 64k?