unix domain socket example:

photon@w520 ~> nc -U /tmp/.n/s/53BNMpXBtETx_5xqiZcwlQ
close
ACK connection closed
^-- should have been closed now, stays open as well..

socat and the 'original' netcat behave as expected in all those cases, example:

photon@w520 ~> socat - tcp:127.0.0.1:242
close
ACK connection closed
photon@w520 ~>
^-- closed as expected..

..greetinx and thanks for the great work! : )
--photon

It's hard to say what is "correct" in many of these cases, though we strive for compatibility with traditional and OpenBSD netcats. Here's some documentation of known cases that may help you out: Ncat/EOF behavior on SecWiki.

I'm not closing this yet, though: I want to investigate whether this really is a bug first, and at least be able to tell you exactly why Ncat acts this way.

I understand.. yet the current behavior is that it will exit with 'broken pipe' if you try to send further bytes on such a closed connection, but only then.
personally i would have to stop using it and switch to the old one or socat because for development i really need to see timeouts and stuff like that immediately, which i'd find sad because i really love ncat! ( cats in general >; ] )

greetings,
photon

btw, just to be clear on this: this is no half-open connection, i had changed my code to call shutdown(2) before the close, so that it is explicit.. in such a case writing to that remote would have been impossible, (beyond the IP stack discarding it after close()) ... so i think it really is an actual bug, even with the desire of half closed connections in mind, since there is nothing the cat could ever do from this point on than to exit..

Any updates on this?

I set up a new CentOS 7 (7.7.1908) VM, installed ncat 7.50, and this problem still persists.

Server side:
ncat -lp 411 -c ./script.sh

Client side:
ncat -w1 127.0.0.1 411

Server side will close connection, however client side will hang indefinitely unless the user presses the 'enter' key a minimum of 3 times to force the broken pipe error. Even with the -w flag, the connection doesn't terminate.

…hen remote sends EOF
Also implements a switch for backwards compatibility with the previous
behaviour, --no-terminate. Previously discussed at
https://seclists.org/nmap-dev/2017/q2/94
Fixes nmap#1779, nmap#894 and nmap#1413.