Commit fa93c35

docs(daemon): copy tweaks to comment

 1@@ -122,10 +122,9 @@ pub fn spawnPty(sesh_name: []const u8, cmd: Cmd) !PtyInfo {
 2 ///
 3 /// When launching a daemon, you normally set the child process of the fork to
 4 /// be the session leader via setsid() which creates a new session that removes
 5-/// the current controlling terminal but creates the authority to grab a new
 6-/// one. This is important because we don't want a controlling terminal for our
 7-/// daemon or else our daemon could receive signals to shutdown when the
 8-/// controlling terminal closes.
 9+/// the current controlling terminal. This is important because we don't want a
10+/// controlling terminal for our daemon or else it could receive signals to
11+/// shutdown when the controlling terminal closes.
12 ///
13 /// However, if the first fork's child process is also the daemon process, then
14 /// it's technically possible for the daemon to open a terminal device (e.g.
15@@ -134,14 +133,12 @@ pub fn spawnPty(sesh_name: []const u8, cmd: Cmd) !PtyInfo {
16 /// terminal-generated signals (e.g. SIGINT) or SIGHUP from terminal disconnect
17 /// which could kill the daemon.
18 ///
19-/// The first fork isn't arbitrary either: setsid() fails with EPERM if the
20-/// caller is already a process group leader, which a process launched directly
21-/// from a shell typically is. The first fork produces a child guaranteed not
22-/// to be a group leader, so setsid() will succeed.  By forking a second time,
23-/// the grandchild process (the daemon) is not the session leader. Per POSIX,
24-/// only a process that is the session leader can acquire a controlling terminal.
25+/// The first fork produces a child guaranteed not to be a group leader, so
26+/// setsid() will succeed.  By forking a second time, the grandchild process
27+/// (the daemon) is not the session leader. Per POSIX, only a process that is
28+/// the session leader can acquire a controlling terminal.
29 ///
30-/// Apparently this is "a bit paranoid," and on Linux it is arguable since a
31+/// Apparently this is "a bit paranoid" and on Linux it is arguable since a
32 /// session leader only acquires a controlling terminal under
33 /// implementation-defined conditions. But the double-fork is the portable way
34 /// to guarantee the daemon can never acquire one, regardless of how a given