user10236: I am recently seeing strange behavior in my Arduino Yun.
Just using the microcontroller, I enter the following:
#include <stdlib.h>
#include <string.h> // For string operations.
#include "Keyboard.h"
#include "Mouse.h"

void setup() {
  Keyboard.begin();
  Keyboard.println("Hello world.");
  Keyboard.print("Hello world.");
}

Rather than getting two lines as expected, I get Hello world.Hello world..
It is a very strange error because println (docs) is so 'core' to Keyboard function. I've never had this issue before and I've been playing with it for months. I am running IDE 1.6.11.
A possibly relevant detail
I had this working on my Yun months ago without the #include "Keyboard.h" and #include "Mouse.h". I opened the IDE again just recently and, upon compiling, it failed saying I needed to add those lines. So I did, and it now println doesn't work.

user10794: 
Please test: Keyboard.print("Hello world.\n");

...

That works. println still doesn't.

I'm going to guess here that println is doing something odd in the Yun libraries. I note that the Keyboard.cpp file in my release has this in it:
#define SHIFT 0x80
const uint8_t _asciimap[128] =
{
    0x00,             // NUL
    0x00,             // SOH
    0x00,             // STX
    0x00,             // ETX
    0x00,             // EOT
    0x00,             // ENQ
    0x00,             // ACK  
    0x00,             // BEL
    0x2a,           // BS   Backspace
    0x2b,           // TAB  Tab
    0x28,           // LF   Enter
    0x00,             // VT 
    0x00,             // FF 
    0x00,             // CR    <---------- note!

Notice that linefeed has a code mapped (0x28) but carriage return (CR) does not (unless you call 0x00 a mapping).
I think you'll find that when you hit Enter on a keyboard it is sending a CR (after all, it used to be labelled the "return" key) and not a LF.
However I thought that the Print class outputted both:
size_t Print::println(void)
{
  return write("\r\n");
}

Maybe yours doesn't. I'm not certain which exact println will be pulled in for a Yun. The fact that it used to work, and now doesn't, suggests a change there somewhere.

10236: <p>I am recently seeing strange behavior in my Arduino Yun.</p>

<p>Just using the microcontroller, I enter the following:</p>

<pre><code>#include &lt;stdlib.h&gt;
#include &lt;string.h&gt; // For string operations.
#include "Keyboard.h"
#include "Mouse.h"

void setup() {
  Keyboard.begin();
  Keyboard.println("Hello world.");
  Keyboard.print("Hello world.");
}
</code></pre>

<p>Rather than getting two lines as expected, I get <code>Hello world.Hello world.</code>.</p>

<p>It is a very strange error because <a href="http://www.arduino.org/learning/reference/keyboard-println" rel="nofollow">println (docs)</a> is so 'core' to Keyboard function. I've never had this issue before and I've been playing with it for months. I am running IDE 1.6.11.</p>

<h3>A possibly relevant detail</h3>

<p>I had this working on my Yun months ago <strong>without</strong> the <code>#include "Keyboard.h"</code> and <code>#include "Mouse.h"</code>. I opened the IDE again just recently and, upon compiling, it failed saying I needed to add those lines. So I did, and it now <code>println</code> doesn't work.</p>
 10794: <blockquote>
  <p>Please test: Keyboard.print("Hello world.\n");</p>
</blockquote>

<p>...</p>

<blockquote>
  <p>That works. println still doesn't.</p>
</blockquote>

<p>I'm going to guess here that println is doing something odd in the Yun libraries. I note that the Keyboard.cpp file in my release has this in it:</p>

<pre class="lang-c++ prettyprint-override"><code>#define SHIFT 0x80
const uint8_t _asciimap[128] =
{
    0x00,             // NUL
    0x00,             // SOH
    0x00,             // STX
    0x00,             // ETX
    0x00,             // EOT
    0x00,             // ENQ
    0x00,             // ACK  
    0x00,             // BEL
    0x2a,           // BS   Backspace
    0x2b,           // TAB  Tab
    0x28,           // LF   Enter
    0x00,             // VT 
    0x00,             // FF 
    0x00,             // CR    &lt;---------- note!
</code></pre>

<p>Notice that linefeed has a code mapped (0x28) but carriage return (CR) does not (unless you call 0x00 a mapping).</p>

<p>I <em>think</em> you'll find that when you hit Enter on a keyboard it is sending a CR (after all, it used to be labelled the "return" key) and not a LF.</p>

<p>However I thought that the Print class outputted both:</p>

<pre><code>size_t Print::println(void)
{
  return write("\r\n");
}
</code></pre>

<p>Maybe yours doesn't. I'm not certain which exact <code>println</code> will be pulled in for a Yun. The fact that it used to work, and now doesn't, suggests a change there somewhere.</p>
