Make this package work under NetBSD.

4 files changed, 14 insertions, 134 deletions

diff --git a/sysutils/socket/Makefile b/sysutils/socket/Makefile
index 583ecc6e114..8770ad2dfa3 100644
--- a/sysutils/socket/Makefile
+++ b/sysutils/socket/Makefile
@@ -3,6 +3,7 @@
 # Date created:         14 August 1996
 # Whom:                 wosch
 #
+# $NetBSD: Makefile,v 1.2 1998/02/24 00:44:24 tron Exp $
 # $FreeBSD Id: Makefile,v 1.7 1997/08/16 10:14:56 wosch Exp
 #
 
@@ -14,4 +15,6 @@ MAINTAINER=     wosch@FreeBSD.org
 
 MAN1=		socket.1
 
+MAKE_ENV+=	INSTALLBASE=${PREFIX}
+
 .include <bsd.port.mk>
diff --git a/sysutils/socket/patches/patch-aa b/sysutils/socket/patches/patch-aa
index 6b0cc1de704..e94289ce3b9 100644
--- a/sysutils/socket/patches/patch-aa
+++ b/sysutils/socket/patches/patch-aa
@@ -1,5 +1,14 @@
 --- Makefile.orig	Thu Sep 10 16:59:31 1992
-+++ Makefile	Wed Aug 14 16:57:57 1996
++++ Makefile	Tue Feb 24 01:36:50 1998
+@@ -8,7 +8,7 @@
+ ### socket.1 in /usr/local/man/man1/socket.1
+ ### Make sure the target directories exist before doing a "make install".
+ 
+-INSTALLBASE = /usr/local
++INSTALLBASE = ${PREFIX}
+ INSTALLBINPATH = $(INSTALLBASE)/bin
+ INSTALLBINMODE = 755
+ INSTALLMANPATH = $(INSTALLBASE)/man
 @@ -43,7 +43,8 @@
  ### CDC 4680 EP/IX: (I know it *has* setsid(2), but not with bsd43)
  # SWITCHES = -systype bsd43 -DNOSETSID
diff --git a/sysutils/socket/pkg/DESCR b/sysutils/socket/pkg/DESCR
index ba54719621b..27da2282aa6 100644
--- a/sysutils/socket/pkg/DESCR
+++ b/sysutils/socket/pkg/DESCR
@@ -8,139 +8,6 @@ to the socket interactively for testing purposes, it quickly evolved
 into a generic tool providing the socket interface for shell script
 and interactive use.
 
-
-Client mode
-
-In client mode (which is the default) it connects to a given port at a
-given host.  Data read from the socket is written to stdout, data read
-from stdin is written to the socket.  When the peer closes the
-connection or a signal is received, the program terminates.  An
-example for this is the following command:
-
-	% socket coma.cs.tu-berlin.de nntp
-
-This connects to the host coma.cs.tu-berlin.de at the nntp port
-(provided these two names can be resolved through gethostbyname(3) and
-getservbyname(3)).  The user can now issue commands to the NNTP
-server, any output from the server is written to the user's terminal.
-
-
-Server mode
-
-In server mode (indicated by the "-s" command line switch) it binds a
-server socket to the given port on the local host and accepts a
-connection.  When a client connects to this socket, all data read from
-the socket is written to stdout, data read from stdin is written to
-the socket.  For example, the command
-
-	% socket -s 3917
-
-accepts a connection on port 3917.  
-
-
-Restricting data flow
-
-It is not always desirable to have data flow in both directions, e.g.
-when the program is running in the background, it would be stopped if
-it tried to read from the terminal.  So the user can advise the program
-only to read from the socket ("-r") or only to write to the socket
-("-w").  Especially when Socket executes a program (see below), it is
-important *not* to write to the program's stdin if the program doesn't
-read it.  This is the main reason why I added this option.
-
-
-Closing connection on EOF
-
-For non-interactive use it is not always clear when to close the
-network connection; this is still an unsolved problem.  But often it
-will be enough to close the connection when some data has been written
-to the socket.  In this case the "quit" switch ("-q") can be used:
-when an end-of-file condition on stdin occurs, Socket closes the
-connection.
-
-
-Executing a program
-
-An interesting use of a server socket is to execute a program when a
-client connects to it.  This done with the "-p" switch.  Stdin,
-stdout, and stderr of the program are read from resp. written to the
-socket.  Since the server is usually expected to accept another
-connection after a connection has been closed, the "loop" switch
-("-l") makes it do exactly that.
-
-
-CRLF conversion
-
-The Internet protocols specify a CRLF sequence (Carriage Return
-Linefeed) to terminate a line, whereas UNIX uses only a single LF.  If
-the user specifies the "crlf" switch ("-c"), all CRLF sequences that
-are read from the socket are converted to a single LF on output.  All
-single LFs on input are converted to a CRLF sequence when written to
-the socket.
-
-
-Background mode
-
-It may be desirable for a server program to run in background. For
-that purpose the "background" switch ("-b") is provided.  If it is
-set, Socket runs in background, detaches itself from the controlling
-tty, closes the file descriptors associated with the tty, and changes
-it current directory to the root directory.  It is still possible to
-redirect the standard file descriptors to a file.
-
-
-Forking child to handle connection
-
-Often one wants the server to be able to respond to another client
-immediately, even before the connection to the previous client has
-been closed.  For this case, Socket can fork a client to handle a
-connection while the father process already accepts the next
-connection.  To get this behaviour, specify the "-f" option.
-
-
-With all these options, a typical server call would look like
-
-	% socket -bcfslqp program port
-
-Gee, I know that's a lot of options for the standard case, but I
-really want to make all these things *optional*.
-
-
-Verbose
-
-At last, there is also a "verbose" option ("-v"). If this option is
-specified, a message is given for each opening and closing of a
-connection.  This is convenient especially in interactive use, but can
-also provide some kind of logging.  See fingerd.sh for an example.
-
-
-WARNING
-
-Nothing prevents you from using Socket like this:
-
-	% socket -slqp sh 5678
-
-THIS IS DANGEROUS! If your machine is connected to the Internet,
-*anyone* on the Internet can connect to this server and issue shell
-commands to your shell.  These commands are executed with your user
-ID.  Some people may think of this program as a BAD THING, because it
-allows its user to open his machine for world-wide access to all kinds
-of malicious crackers, crashers, etc.  I don't know if I should
-consider this as a real security risk or not.  Anyway, it is not my
-program which is so dangerous -- anyone with moderate programming
-skill can write a something like this.
-
-Another problem is that any server program that uses Socket may not be
-secure.  I tried to avoid any holes -- especially that one that made
-fingerd vulnerable to the attack of Morris' Internet Worm, but I don't
-give any warranty.  Also the program run by Socket may have security
-holes.
-
-I would like to hear your opinion about this topic.  Do you consider it
-a security risk to have a program like Socket around?
-
-Comments
-
 Please send any comments, suggestions, bug reports etc. to me:
 
 Juergen Nickelsen <jn@berlin.snafu.de>
diff --git a/sysutils/socket/pkg/PLIST b/sysutils/socket/pkg/PLIST
index 1a28d36992e..86bf5aa784d 100644
--- a/sysutils/socket/pkg/PLIST
+++ b/sysutils/socket/pkg/PLIST
@@ -1,2 +1,3 @@
+@comment $NetBSD: PLIST,v 1.2 1998/02/24 00:44:25 tron Exp $
 bin/socket
 man/man1/socket.1.gz