<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Hi Erik,</div><div><br></div><div>On 27 Sep 2012, at 03:20, Erik Søe Sørensen wrote:</div><blockquote type="cite"><p>It is the responsibility of the port program to shut down when stdin reaches EOF.<br>
This behaviour/expectation confused me too at some point, but it probably has its merits: not all software is designed for "let it crash", so simply killing the port program might be too crude in some circumstances.</p>
</blockquote>Well that's fine, but it should be documented a bit more clearly IMHO. Also the port program, in this instance, is another beam emulator, so it's clearly *not* going to behave that way! Currently the connected process for the port has 3 shutdown modes:</div><div><br></div><div>1. rpc:call(Node, custom_app, stop, [])</div><div>2. close_port(Port)</div><div>3. open_port({spawn, "kill -9 " ++ OsPid, Opts)</div><div><br></div><div>Item 3 is the least preferable as it is not portable (relies on 'kill' being a shell built-in, etc) and requires that the os process id is known. It sounds like (2) is not a workable solution unless the external program is hand written to deal with 'stdin reaches EOF'. This is less than ideal, as it means that open_port/2 is not much use for spawning (and monitoring thereafter) arbitrary programs unless you're willing to live with the fact that you're not able to shut them down by closing the port. </div><div><br></div><div><br></div><div><br></div><br></body></html>