diff --git a/man2/select_tut.2 b/man2/select_tut.2
index b33323c7d..2a97c5ea7 100644
--- a/man2/select_tut.2
+++ b/man2/select_tut.2
@@ -131,7 +131,7 @@ its file descriptors.
 After
 .BR select ()
 has returned, \fIreadfds\fP will be
-cleared of all file descriptors except for those file descriptors that
+cleared of all file descriptors except for those that
 are immediately available for reading with a
 .BR recv (2)
 (for sockets) or
@@ -144,7 +144,7 @@ its file descriptors.
 After
 .BR select ()
 has returned, \fIwritefds\fP will be
-cleared of all file descriptors except for those file descriptors that
+cleared of all file descriptors except for those that
 are immediately available for writing with a
 .BR send (2)
 (for sockets) or
@@ -169,7 +169,7 @@ After
 .BR select ()
 has returned,
 \fIexceptfds\fP will be cleared of all file descriptors except for those
-descriptors that are available for reading OOB data.
+that are available for reading OOB data.
 You can only ever
 read one byte of OOB data though (which is done with
 .BR recv (2)),
@@ -192,7 +192,7 @@ them, then increment this value by one, and then pass this as \fInfds\fP to
 \fIutimeout\fP
 This is the longest time
 .BR select ()
-must wait before returning, even
+may wait before returning, even
 if nothing interesting happened.
 If this value is passed as NULL,
 then
@@ -406,7 +406,7 @@ and
 .BR send (2)
 do \fInot\fP necessarily read/write the full amount of data
 that you have requested.
-If they do read/write the full amount, its
+If they do read/write the full amount, it's
 because you have a low traffic load and a fast stream.
 This is not
 always going to be the case.
@@ -414,7 +414,7 @@ You should cope with the case of your
 functions only managing to send or receive a single byte.
 .TP
 6.
-Never read/write only in single bytes at a time unless your are really
+Never read/write only in single bytes at a time unless you are really
 sure that you have a small amount of data to process.
 It is extremely
 inefficient not to read/write as much data as you can buffer each time.
@@ -438,7 +438,7 @@ or with
 set to \fBEAGAIN\fP (\fBEWOULDBLOCK\fP).
 These results must be properly managed (not done properly
 above).
-If your program is not going to receive any signals then
+If your program is not going to receive any signals, then
 it is unlikely you will get \fBEINTR\fP.
 If your program does not
 set non-blocking I/O, you will not get \fBEAGAIN\fP.
@@ -838,8 +838,8 @@ you might suspect.
 Another idea is to set non-blocking I/O using an
 .BR ioctl (2)
 call.
-This also has its problems because you end up having
-to have inefficient timeouts.
+This also has its problems because you end up using
+inefficient timeouts.
 
 The program does not handle more than one simultaneous connection at a
 time, although it could easily be extended to do this with a linked list