Is there now, or are there plans for, a mechanism to export code from the web editor to the PC?
I tried the normal linux method of highlighting and middle clicking but that didn't work at all; the highlighted text never goes to the clipboard.
I can use Ctrl-C/Ctrl-V and paste it into a GUI editor such as kwrite but I cannot paste it into vi or even pico/nano. Pasting it into kwrite or kedit results in pasting a single long line of text.
You can export the sketch by clicking on the 3 dots by the side of the BOARDS selection window and clicking on DOWNLOAD.
That will allow to to pull individual sketches or even share a link to one for others to use.
For MULTIPLE sketches that you simply tick the boxes in the sketchbook view and the download option will become available to you.
Currently there does not seem to be an option to download a whole folder but I may be wrong or they may be working on it.
They surprise me almost daily with a new feature of fix.
Okay, thanks! I overlooked that "..." thing.
Looks like I have to find or write a filter to convert the 0x0D line endings to 0x0A (or 0D0A). Not a big deal, but it's an annoyance.
Not sure what you mean ?
Care to expand a little.
If not for me then so the team can pick it up and answer it better than me.
Okay. Not sure how much detail I need to go into so bear with me please.
Back in the stone age computers often used a device called a Teletype Model 33 or ASR 33 Teletype machine for console I/O. This was often abbreviated to TTY, and we still use "tty" today but not to refer to ASR 33's. Anyhow, the ASR 33 was very much like a typewriter in operation; it pressed an inked ribbon against paper to produce printout. There was a moveable typebox that moved from left to right printing characters as it arrived. When it reached the rightmost limit, it would stay there overtyping whatever was typed in the last character position until it received a special character called a "carriage return". This would cause the print mechanism to move back to the left hand side of the paper.
It would then be in a position to overtype the line it had just printed, so another control character would be sent to the TTY called a "line feed". This would cause the platen to advance the paper one line.
The upshot of this is that after printing a line, you had to send a carriage return and a line feed, which came to be known as the "line ending characters". The ASCII codes for these special characters were 015 and 012 respectively in octal. We don't use octal any more so today we'd print them as 0x0D and 0x0A.
The ASR33's and similar devices such as the IBM 2741 (which used EBCDIC, not ASCII usually) were slow and noisy and eventually were phased out and replaced by devices with a CRT display instead of paper. These devices were commonly known as "glass TTYs". I'll leave it to the reader to figure out how "glass TTY" was often pronounced.
Around this time we had the introduction of the microprocessor and a number of operating systems developed to run on these systems. It was also realized that the carriage return and linefeed didn't cause physical movement on anything and merely designated the end of a printed line, so it wasn't strictly necessary to have both. The TRS-80 and Apple][e and, later, pre-Intel-based Macintoshes used carriage return (0x0D) only to signify the end of a line. Commodores (Amigas) used linefeeds (0x0A) only, as did Unix, Multics, and many other "big iron" OSes. MS-DOS and its derivative/successor continued to use the CR/LF 0D0A sequence.
The Create web IDE uses 0x0D as a line ending character. Linux uses 0A as a line ending character. It will recognize 0x0D as a carriage return, and that's exactly what it does -- returns the cursor to the beginning of the line without advancing to the next line. So when I export a sketch and attempt to display it on my terminal with a command such as "cat mysketch.ino", all I see is the last line and fragments of previous lines on the right if they were longer than the last line. If I load the sketch into an editor such as vim or nano or joe, it renders the carriage return characters as Ctrl-M or ^M characters and not as newlines.
So I have to filter the sketch before I can work with it to translate the CR's to LF's.
Thanks Bob..Am sure they will have something to add to that good info btw.
Hi Bob...quick update...there was a little "whoops" moment...So great catch.
They are now fully aware and will look at that.
I was also given this link to look at but I suspect you are either working on your own temp fix or know what to do anyway.
Okay, thanks for that link... I was going to work out the maze of shell escapes (backslash sequences) to do it with sed, but their tr example is pretty elegant.
I do have dos2unix and unix2dos already, but they're no help -- they translate to and from the two-char sequence 0x0D 0x0A that MS-Dos uses; they pretty much ignore 0x0D by itself.
It would be fairly trivial to write a filter for it, something like this should work:
#include <stdio.h>
int main( )
{
int c;
while ( ( c = getchar( ) ) != EOF )
putchar( c == 0x0D ? 0x0A : c );
return 0;
}
then invoke it with something like
crfilter <mysketch.ino > mysketch_fixed.ino
assuming the binary is named crfilter of course.
Anyway, I wasn't sure if it warranted a bug report or not.
Incidentally the Arduino IDE has no problem with the 0x0D line ending, and if I make a trivial change to the file and save it, it translates all the CR's to LF's anyway.
They have to do it on a web interface though and sometimes its not as simple as it seems.
Given the differing OS's, web filtering and so on.