SquircleSpace / shcl

SHell in Common Lisp
Apache License 2.0
319 stars 17 forks source link

"SHCL doesn't fork" - discussion #13

Closed phmarek closed 6 years ago

phmarek commented 6 years ago

Hi,

I'm not sure whether the "SHCL doesn't fork" will work in practice. How would you get $$ and $PPID correct? A shell script that does

(echo $$ > logfile ; exec long-running-process ) &
...
kill $(cat logfile)

would kill the whole SHCL process, and not just the child. Even if $$ and $PPID got faked in a subshell, forking would be inevitable as soon as external commands are being called; and investigating the sub-shell command line to find out whether to fork or not feels quite unclean, too.

So I ask you to discuss for and against forking.

Thank you!

SquircleSpace commented 6 years ago

First off, thanks for the interest in my weird little project.

As for $$ and $PPID, I actually think non-forking is okay.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_02

$ Expands to the decimal process ID of the invoked shell. In a subshell (see Shell Execution Environment ), '$' shall expand to the same value as that of the current shell.

That's a bit unclear, but when you combine it with this

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03

PPID Set by the shell to the decimal value of its parent process ID during initialization of the shell. In a subshell (see Shell Execution Environment), PPID shall be set to the same value as that of the parent of the current shell. For example, echo $ PPID and (echo $ PPID) would produce the same value.

Its pretty clear that $$ and $PPID should be unchanged in subshells. Try it out in your favorite shell! Bash actually has a different variable where they store the real pid of the current process ($BASHPID).

[brad@Jobe:~]$ sh
sh-4.4$ echo $$ $PPID; (echo $$ $PPID)
31359 31344
31359 31344
sh-4.4$ exit
[brad@Jobe:~]$ echo $BASHPID; (echo $BASHPID)
31344
31438

I'm very concerned that there will eventually be some part of the standard that requires forking, but I haven't found it, yet. I'm especially nervous about signal handling. I haven't even looked at that part of the standard yet. I am almost positive its going to be problematic for a non-forking.

I wrote that "SHCL doesn't fork" bit to scare potential contributors away from mutating the process environment and explain why SHCL has so much complexity in some parts. SHCL may very well one day support running in a forking mode. I'm tempted to start investigating it once I finish up my work on the file descriptor table nonsense. The important thing is that I intend to maintain support for a non-forking mode. That will be a lot harder if people contribute code that assumes SHCL forks.

phmarek commented 6 years ago

Thanks for the quick reply! Okay, I think I understand you.

Interesting that a subshell behaves different than the explicit call. Yeah, it's specified that way... Interesting, I always thought it amounts to basically the same thing.

$ echo $$ $PPID; bash -c ' echo "$$ $PPID"'
20862 2634
20902 20862