doc: fix up various typos and trailing whitespace

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>

doc/authentication.dox

@@ -127,7 +127,7 @@ The keyboard-interactive method is, as its name tells, interactive. The
 server will issue one or more challenges that the user has to answer,
 until the server takes an authentication decision.
 
-ssh_userauth_kbdint() is the the main keyboard-interactive function. 
+ssh_userauth_kbdint() is the the main keyboard-interactive function.
 It will return SSH_AUTH_SUCCESS,SSH_AUTH_DENIED, SSH_AUTH_PARTIAL,
 SSH_AUTH_ERROR, or SSH_AUTH_INFO, depending on the result of the request.
 
@@ -154,9 +154,9 @@ Here are a few remarks:
  - Even the first call can return SSH_AUTH_DENIED or SSH_AUTH_SUCCESS.
  - The server can send an empty question set (this is the default behavior
    on my system) after you have sent the answers to the first questions.
-   You must still parse the answer, it might contain some 
+   You must still parse the answer, it might contain some
    message from the server saying hello or such things. Just call
-   ssh_userauth_kbdint() until needed. 
+   ssh_userauth_kbdint() until needed.
  - The meaning of "name", "prompt", "instruction" may be a little
    confusing. An explanation is given in the RFC section that follows.
 
@@ -187,7 +187,7 @@ keyboard-interactive authentication, coming from the RFC itself (rfc4256):
   the name and prompts. If the server presents names or prompts longer than 30
   characters, the client MAY truncate these fields to the length it can
   display. If the client does truncate any fields, there MUST be an obvious
-  indication that such truncation has occured.
+  indication that such truncation has occurred.
 
   The instruction field SHOULD NOT be truncated. Clients SHOULD use control
   character filtering as discussed in [SSH-ARCH] to avoid attacks by

doc/forwarding.dox

@@ -4,7 +4,7 @@
 
 Port forwarding comes in SSH protocol in two different flavours:
 direct or reverse port forwarding. Direct port forwarding is also
-named local port forwardind, and reverse port forwarding is also called
+named local port forwarding, and reverse port forwarding is also called
 remote port forwarding. SSH also allows X11 tunnels.
 
 
@@ -23,15 +23,15 @@ Mail client application   Google Mail
      5555 (arbitrary)         |
          |                143 (IMAP2)
          V                    |
-    SSH client   =====>   SSH server 
+    SSH client   =====>   SSH server
 
 Legend:
---P-->: port connexion through port P
+--P-->: port connections through port P
 =====>: SSH tunnel
 @endverbatim
 A mail client connects to port 5555 of a client. An encrypted tunnel is
 established to the server. The server connects to port 143 of Google Mail (the
-end point). Now the local mail client can retreive mail.
+end point). Now the local mail client can retrieve mail.
 
 
 @subsection forwarding_reverse Reverse port forwarding
@@ -51,7 +51,7 @@ Example of use of reverse port forwarding:
     SSH client   <=====   SSH server
 
 Legend:
---P-->: port connexion through port P
+--P-->: port connections through port P
 =====>: SSH tunnel
 @endverbatim
 In this example, the SSH client establishes the tunnel,
@@ -148,9 +148,9 @@ To do reverse port forwarding, call ssh_channel_listen_forward(),
 then ssh_channel_accept_forward().
 
 When you call ssh_channel_listen_forward(), you can let the remote server
-chose the non-priviledged port it should listen to. Otherwise, you can chose
+chose the non-privileged port it should listen to. Otherwise, you can chose
-your own priviledged or non-priviledged port. Beware that you should have
+your own privileged or non-privileged port. Beware that you should have
-administrative priviledges on the remote server to open a priviledged port
+administrative privileges on the remote server to open a privileged port
 (port number < 1024).
 
 Below is an example of a very rough web server waiting for connections on port

doc/guided_tour.dox

@@ -31,20 +31,20 @@ A SSH session goes through the following steps:
    - Invoke your own subsystem. This is outside the scope of this document,
      but can be done.
 
- - When everything is finished, just close the channels, and then the connection. 
+ - When everything is finished, just close the channels, and then the connection.
 
 The sftp and scp subsystems use channels, but libssh hides them to
 the programmer. If you want to use those subsystems, instead of a channel,
 you'll usually open a "sftp session" or a "scp session".
- 
+
 
 @subsection setup Creating the session and setting options
 
 The most important object in a SSH connection is the SSH session. In order
 to allocate a new SSH session, you use ssh_new(). Don't forget to
-always verify that the allocation successed.
+always verify that the allocation succeeded.
 @code
-#include <libssh/libssh.h> 
+#include <libssh/libssh.h>
 #include <stdlib.h>
 
 int main()
@@ -69,12 +69,12 @@ The ssh_options_set() function sets the options of the session. The most importa
 
 The complete list of options can be found in the documentation of ssh_options_set().
 The only mandatory option is SSH_OPTIONS_HOST. If you don't use SSH_OPTIONS_USER,
-the local username of your account will be used. 
+the local username of your account will be used.
 
 Here is a small example of how to use it:
 
 @code
-#include <libssh/libssh.h> 
+#include <libssh/libssh.h>
 #include <stdlib.h>
 
 int main()
@@ -122,7 +122,7 @@ Here's an example:
 @code
 #include <libssh/libssh.h>
 #include <stdlib.h>
-#include <stdio.h> 
+#include <stdio.h>
 
 int main()
 {
@@ -285,9 +285,9 @@ int verify_knownhost(ssh_session session)
 
 The authentication process is the way a service provider can identify a
 user and verify his/her identity. The authorization process is about enabling
-the authenticated user the access to ressources. In SSH, the two concepts
+the authenticated user the access to resources. In SSH, the two concepts
 are linked. After authentication, the server can grant the user access to
-several ressources such as port forwarding, shell, sftp subsystem, and so on.
+several resources such as port forwarding, shell, sftp subsystem, and so on.
 
 libssh supports several methods of authentication:
  - "none" method. This method allows to get the available authentications
@@ -313,7 +313,7 @@ The example below shows an authentication with password:
 @code
 #include <libssh/libssh.h>
 #include <stdlib.h>
-#include <stdio.h> 
+#include <stdio.h>
 
 int main()
 {
@@ -338,7 +338,7 @@ int main()
   }
 
   // Verify the server's identity
-  // For the source code of verify_knowhost(), check previous example
+  // For the source code of verify_knownhost(), check previous example
   if (verify_knownhost(my_ssh_session) < 0)
   {
     ssh_disconnect(my_ssh_session);
@@ -415,7 +415,7 @@ int show_remote_processes(ssh_session session)
     }
     nbytes = ssh_channel_read(channel, buffer, sizeof(buffer), 0);
   }
-    
+
   if (nbytes < 0)
   {
     ssh_channel_close(channel);
@@ -456,7 +456,7 @@ might be recoverable. SSH_FATAL means the connection has an important
 problem and isn't probably recoverable.
 
 Most of time, the error returned are SSH_FATAL, but some functions
-(generaly the ssh_request_xxx ones) may fail because of server denying request.
+(generally the ssh_request_xxx ones) may fail because of server denying request.
 In these cases, SSH_REQUEST_DENIED is returned.
 
 For thread safety, errors are bound to ssh_session objects.

doc/introduction.dox

@@ -12,13 +12,13 @@ mean that you should not try to know about and understand these details.
 
 libssh is a Free Software / Open Source project. The libssh library
 is distributed under LGPL license. The libssh project has nothing to do with
-"libssh2", which is a completly different and independant project.
+"libssh2", which is a completely different and independent project.
 
 libssh can run on top of either libgcrypt or libcrypto,
 two general-purpose cryptographic libraries.
 
 This tutorial concentrates for its main part on the "client" side of libssh.
-To learn how to accept incoming SSH connexions (how to write a SSH server),
+To learn how to accept incoming SSH connections (how to write a SSH server),
 you'll have to jump to the end of this document.
 
 This tutorial describes libssh version 0.5.0. This version is a little different

doc/scp.dox

@@ -2,7 +2,7 @@
 @page libssh_tutor_scp Chapter 6: The SCP subsystem
 @section scp_subsystem The SCP subsystem
 
-The SCP subsystem has far less functionnality than the SFTP subsystem.
+The SCP subsystem has far less functionality than the SFTP subsystem.
 However, if you only need to copy files from and to the remote system,
 it does its job.
 
@@ -158,7 +158,7 @@ Let's say you want to copy the following tree of files to the remote site:
                +-- file1
        +-- B --+
        |       +-- file2
--- A --+ 
+-- A --+
        |       +-- file3
        +-- C --+
                +-- file4
@@ -210,7 +210,7 @@ int scp_receive(ssh_session session, ssh_scp scp)
   size = ssh_scp_request_get_size(scp);
   filename = strdup(ssh_scp_request_get_filename(scp));
   mode = ssh_scp_request_get_permissions(scp);
-  printf("Receiving file %s, size %d, permisssions 0%o\n",
+  printf("Receiving file %s, size %d, permissions 0%o\n",
           filename, size, mode);
   free(filename);
 

doc/sftp.dox

@@ -100,7 +100,7 @@ Possible errors are:
 
 @subsection sftp_mkdir Creating a directory
 
-The function sftp_mkdir() tahes the "SFTP session" we juste created as
+The function sftp_mkdir() takes the "SFTP session" we just created as
 its first argument. It also needs the name of the file to create, and the
 desired permissions. The permissions are the same as for the usual mkdir()
 function. To get a comprehensive list of the available permissions, use the
@@ -358,19 +358,19 @@ int sftp_read_async(ssh_session session, sftp_session sftp)
 @subsection sftp_ls Listing the contents of a directory
 
 The functions sftp_opendir(), sftp_readdir(), sftp_dir_eof(),
-and sftp_closedir() enable to list the contents of a directory. 
+and sftp_closedir() enable to list the contents of a directory.
 They use a new handle_type, "sftp_dir", which gives access to the
 directory being read.
 
 In addition, sftp_readdir() returns a "sftp_attributes" which is a pointer
-to a structure with informations about a directory entry:
+to a structure with information about a directory entry:
   - name: the name of the file or directory
   - size: its size in bytes
   - etc.
 
 sftp_readdir() might return NULL under two conditions:
   - when the end of the directory has been met
-  - when an error occured
+  - when an error occurred
 
 To tell the difference, call sftp_dir_eof().
 

doc/shell.dox

@@ -209,7 +209,7 @@ int interactive_shell_session(ssh_channel channel)
 
 Of course, this is a poor terminal emulator, since the echo from the keys
 pressed should not be done locally, but should be done by the remote side.
-Also, user's input should not be sent once "Enter" key is pressed, but 
+Also, user's input should not be sent once "Enter" key is pressed, but
 immediately after each key is pressed. This can be accomplished
 by setting the local terminal to "raw" mode with the cfmakeraw(3) function.
 cfmakeraw() is a standard function under Linux, on other systems you can
@@ -245,13 +245,13 @@ provide a more elegant way to wait for data coming from many sources.
 
 The functions ssh_select() and ssh_channel_select() remind of the standard
 UNIX select(2) function. The idea is to wait for "something" to happen:
-incoming data to be read, outcoming data to block, or an exception to
+incoming data to be read, outgoing data to block, or an exception to
 occur. Both these functions do a "passive wait", i.e. you can safely use
 them repeatedly in a loop, it will not consume exaggerate processor time
 and make your computer unresponsive. It is quite common to use these
 functions in your application's main loop.
 
-The difference between ssh_select() and ssh_channel_select() is that 
+The difference between ssh_select() and ssh_channel_select() is that
 ssh_channel_select() is simpler, but allows you only to watch SSH channels.
 ssh_select() is more complete and enables watching regular file descriptors
 as well, in the same function call.

doc/threading.dox

@@ -11,10 +11,10 @@ libssh may be used in multithreaded applications, but under several conditions :
  - If libssh is statically linked, threading must be initialized by calling
    ssh_init() before using any of libssh provided functions. This initialization
    must be done outside of any threading context. Don't forget to call
-   ssh_finalize() to avoid memory leak 
+   ssh_finalize() to avoid memory leak
  - At all times, you may use different sessions inside threads, make parallel
    connections, read/write on different sessions and so on. You *cannot* use a
-   single session (or channels for a single session) in several threads at the same 
+   single session (or channels for a single session) in several threads at the same
    time. This will most likely lead to internal state corruption. This limitation is
    being worked out and will maybe disappear later.