Simple spelling fixes

src/frontend/stmclient.cc

@@ -53,7 +53,7 @@ void STMClient::init( void )
     string native_charset( locale_charset() );
 
     fprintf( stderr, "mosh-client needs a UTF-8 native locale to run.\n\n" );
-    fprintf( stderr, "Unfortunately, the client's environemnt (%s) specifies\nthe character set \"%s\".\n\n", native_ctype.str().c_str(), native_charset.c_str() );
+    fprintf( stderr, "Unfortunately, the client's environment (%s) specifies\nthe character set \"%s\".\n\n", native_ctype.str().c_str(), native_charset.c_str() );
     int unused __attribute((unused)) = system( "locale" );
     exit( 1 );
   }

src/terminal/terminalframebuffer.cc

@@ -479,7 +479,7 @@ std::string Renditions::sgr( void ) const
 /* Reduce 256 "standard" colors to the 8 ANSI colors. */
 
 /* Terminal emulators generally agree on the (R',G',B') values of the
-   "standard" 256-color pallette beyond #15, but for the first 16
+   "standard" 256-color palette beyond #15, but for the first 16
    colors there is disagreement. Most terminal emulators are roughly
    self-consistent, except on Ubuntu's gnome-terminal where "ANSI
    blue" (#4) has been replaced with the aubergine system-wide
@@ -488,7 +488,7 @@ std::string Renditions::sgr( void ) const
 
    Terminal emulators that advertise "xterm" are inconsistent on the
    handling of initc to change the contents of a cell in the color
-   pallette. On RIS (reset to initial state) or choosing reset from
+   palette. On RIS (reset to initial state) or choosing reset from
    the user interface, xterm resets all entries, but gnome-terminal
    only resets entries beyond 16. (rxvt doesn't reset any entries,
    and Terminal.app ignores initc.) On initc, xterm applies changes