Bug 68272 - netcat does not install man page
Summary: netcat does not install man page
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Munechika Sumikawa
Depends on:
Reported: 2004-06-24 13:50 UTC by lee dilkie
Modified: 2004-07-06 11:31 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description lee dilkie 2004-06-24 13:50:27 UTC
the port net/netcat does not install man pages for nc(1). These do exist on other platforms
so there should be no reason not to install them as far as I can see.
As well, the port net/nc which *looks* like it might be netcat but isn't quite as it
installs ncat. ncat(1) refers to nc(1) i it's "see also".

How-To-Repeat: > man nc
Comment 1 Kirill Ponomarev freebsd_committer 2004-06-24 13:53:33 UTC
Responsible Changed
From-To: freebsd-ports-bugs->markp

Over to maintainer.
Comment 2 markp freebsd_committer 2004-07-05 13:03:28 UTC
Responsible Changed
From-To: markp->sumikawa

Changed to the real maintainer of net/netcat.
Comment 3 markp freebsd_committer 2004-07-05 13:10:43 UTC
The netcat package doesn't come with a man page. However, the port
does have a README file.

I've appended Debian's current nc.1 man page. It was originally based
on the README. Adding it to the port would make it quicker to read the

.TH NC 1 
nc \- TCP/IP swiss army knife
.B nc
.I "[-options] hostname port[s] [ports] ..."
.B nc
.I "-l -p port [-options] [hostname] [port]"
.B netcat
is a simple unix utility which reads and writes data across network
connections, using TCP or UDP protocol. It is designed to be a
reliable "back-end" tool that can be used directly or easily driven by
other programs and scripts.  At the same time, it is a feature-rich
network debugging and exploration tool, since it can create almost any
kind of connection you would need and has several interesting built-in
capabilities.  Netcat, or "nc" as the actual program is named, should
have been supplied long ago as another one of those cryptic but
standard Unix tools.
In the simplest usage, "nc host port" creates a TCP connection to the
given port on the given target host.  Your standard input is then sent
to the host, and anything that comes back across the connection is
sent to your standard output.  This continues indefinitely, until the
network side of the connection shuts down.  Note that this behavior is
different from most other applications which shut everything down and
exit after an end-of-file on the standard input.
Netcat can also function as a server, by listening for inbound
connections on arbitrary ports and then doing the same reading and
writing.  With minor limitations, netcat doesn't really care if it
runs in "client" or "server" mode -- it still shovels data back and
forth until there isn't any more left. In either mode, shutdown can be
forced after a configurable time of inactivity on the network side.
And it can do this via UDP too, so netcat is possibly the "udp
telnet-like" application you always wanted for testing your UDP-mode
servers.  UDP, as the "U" implies, gives less reliable data
transmission than TCP connections and some systems may have trouble
sending large amounts of data that way, but it's still a useful
capability to have.
You may be asking "why not just use telnet to connect to arbitrary
ports?" Valid question, and here are some reasons.  Telnet has the
"standard input EOF" problem, so one must introduce calculated delays
in driving scripts to allow network output to finish.  This is the
main reason netcat stays running until the *network* side closes.
Telnet also will not transfer arbitrary binary data, because certain
characters are interpreted as telnet options and are thus removed from
the data stream.  Telnet also emits some of its diagnostic messages to
standard output, where netcat keeps such things religiously separated
from its *output* and will never modify any of the real data in
transit unless you *really* want it to.  And of course telnet is
incapable of listening for inbound connections, or using UDP instead.
Netcat doesn't have any of these limitations, is much smaller and
faster than telnet, and has many other advantages.
.TP 13
.I \-g gateway
source-routing hop point[s], up to 8
.TP 13
.I \-G num
source-routing pointer: 4, 8, 12, ...
.TP 13
.I \-h
display help
.TP 13
.I \-i secs
delay interval for lines sent, ports scanned
.TP 13
.I \-l
listen mode, for inbound connects
.TP 13
.I \-n
numeric-only IP addresses, no DNS
.TP 13
.I \-o file
hex dump of traffic
.TP 13
.I \-p port
local port number (port numbers can be individual or ranges: lo-hi
.TP 13
.I \-q seconds
after EOF is detected, wait the specified number of seconds and then
.TP 13
.I \-b
allow UDP broadcasts
.TP 13
.I \-r
randomize local and remote ports
.TP 13
.I \-s addr
local source address
.TP 13
.I \-t
enable telnet negotiation
.TP 13
.I \-e prog
specify program to exec after connect (use with caution)
.TP 13
.I \-u
UDP mode
.TP 13
.I \-v
verbose [use twice to be more verbose]
.TP 13
.I \-w secs
timeout for connects and final net reads
.TP 13
.I \-z
zero-I/O mode [used for scanning]
Netcat is entirely my own creation, although plenty of other code was
used as examples.  It is freely given away to the Internet community
in the hope that it will be useful, with no restrictions except giving
credit where it is due.  No GPLs, Berkeley copyrights or any of that
nonsense.  The author assumes NO responsibility for how anyone uses
it.  If netcat makes you rich somehow and you're feeling generous,
mail me a check.  If you are affiliated in any way with Microsoft
Network, get a life.  Always ski in control.  Comments, questions, and
patches to hobbit@avian.org.
Efforts have been made to have netcat "do the right thing" in all its
various modes.  If you believe that it is doing the wrong thing under
whatever circumstances, please notify me and tell me how you think it
should behave.  If netcat is not able to do some task you think up,
minor tweaks to the code will probably fix that.  It provides a basic
and easily-modified template for writing other network applications,
and I certainly encourage people to make custom mods and send in any
improvements they make to it. Continued feedback from the Internet
community is always welcome!
Some port names in /etc/services contain hyphens -- netcat currently
will not correctly parse those, so specify ranges using numbers if you
This manual page was written by Joey Hess <joeyh@debian.org> and
Robert Woodcock <rcw@debian.org>, cribbing heavily from Netcat's
README file.
Netcat was written by a guy we know as the Hobbit <hobbit@avian.org>.
Comment 4 Munechika Sumikawa freebsd_committer 2004-07-06 11:31:18 UTC
State Changed
From-To: open->closed

Commited, thanks.