src/usr.bin/window/wwspawn.c, branch main

Remove window(1) from the base system.

2009-06-02T13:44:36Z

Some time ago Tom Rhodes sent me an email that he was willing to perform various cleanups to the window(1) source code. After some discussion, we both decided the best thing to do, was to move window(1) to the ports tree. The application isn't used a lot nowadays, mainly because it has been superseeded by screen, tmux, etc. A couple of hours ago Tom committed window(1) to ports (misc/window), so I'm removing it from the tree. I don't think people will really miss it, but I'm describing the change in UPDATING anyway. Discussed with: trhodes, pav, kib Approved by: re

Include proper header files for system functions that are used and

2009-02-19T20:07:59Z

that gcc complains about this code changing from the built-in versions.

Fix the rcsid's.

2001-05-17T09:38:49Z

While I'm here and got caught by it, add FreeBSD IDs so the next guy

2000-10-26T10:07:20Z

won't have trouble committing his bits.

Make window(1) actually work again. It has been broken for quite some

1999-03-02T19:08:09Z

time now. For whatever reason, the kernel seems to have generated SIGIOs previously without an initial fcntl(...,F_SETOWN), but does no longer. This caused window(1) to wait indefinitely for input. Also, undo rev 1.3 of wwspawn.c, it was not well-thought, and apparently not even tested at all. The blindly (even in a nonsensical place like the comment on top of the function) applied replacement of vfork() by fork() totally ignored that window(1) *does* abuse the feature of vfork() where a modification of the parent's address space is possible (in this case, to notify the parent of an erred exec*). Also, with vfork(), it is guaranteed that the parent is only woken up after the exec*() happened, where the replacement by fork() made the parent to almost always become runnable again before the child, in which case the parent simply told `subprocess died'. Unfortunately, working around _this_ seems to be a lot more of redesign work compared to little gained value, so i think relying on the specifics of vfork() is the simpler way. Submitted by: Philipp Mergenthaler

One vfork() changed to fork(); one execl() changed to execv(). The

1998-10-13T15:14:37Z

latter isn't actually called as far as I can see since FreeBSD uses termcap and not terminfo.

Use instead of .

1998-08-05T09:01:29Z

BSD 4.4 Lite Usr.bin Sources

1994-05-27T12:33:43Z