interp: consider some support for PIDs

@andreynering

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!

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.

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

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.

@rhd

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

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

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.

@Ckarles

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?

Running into this again today, any new insights?

This is implemented as of master:

$ bash -c '{ sleep 0.01; false; } & echo $!; wait $!; echo $?'
167991
1
$ gosh -c '{ sleep 0.01; false; } & echo $!; wait $!; echo $?'
g1
1

Note that I went for a "g" prefix to differentiate these virtual PIDs, representing a goroutine in memory, from the real PIDs representing processes on the host system.

interp: initial support for $! and wait PID

merge: Rust handles and callback bridge with isolated context and status

interp: reserve persistent stream workers in pipeline process groups

interp: verify stream job terminal ownership and Ctrl-C lifecycle

interp+polyglot: stream Python and Rust iterators on persistent workers

lower: align foreign-error assertions with accepted worker and callba…

lower: keep standalone runtime declarations independent of worker pac…

lower: make native parity and runtime-plan fixtures executable on Win…

polyglot+interp: preserve Python and toolchain behavior on Windows

fix: isolate live process output locks from foreground consumers

interp: review authenticated Windows Go 1.27.1 toolchains

interp: scope Windows toolchain review to runtime execution

polyglot: preserve Windows callback protocol during output capture

fix: synchronize foreign iterator output with shell diagnostics

polyglot: report native worker exits on Windows

Can we revisit this? I've run into this and am using your project as a shell in a custom linux os called GoNix and this behaviour is currently a bit of a bug for me.

Navigation Menu

Repository navigation

interp: consider some support for PIDs #221

33 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

interp: consider some support for PIDs #221

Description

Activity

mvdan commented on Mar 13, 2018

rhd commented on Mar 14, 2018

mvdan commented on Mar 16, 2018

mvdan commented on Mar 23, 2018

mvdan commented on Apr 22, 2018

Ckarles commented on May 29, 2021

mvdan commented on May 29, 2021

jubr commented on Mar 5, 2025

mvdan commented on Mar 29, 2025

33 remaining items

prologic commented on Oct 18, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions