I use ´screen /dev/ttyACM0´ to connect to the arduino.
Works fine to read output from the arduino.
My sketch expects input line by line.
How do I tell screen not to send each character but entire lines?
It should echo the typing on the monitor but send it when the line is complete.
How do I tell screen not to send each character but entire lines?
You don't. You fix your sketch so that it simply reads and stores the data until the end-of-line marker arrives.
PaulS:
How do I tell screen not to send each character but entire lines?
You don't. You fix your sketch so that it simply reads and stores the data until the end-of-line marker arrives.
Yes, but maybe not in all cases...
I use a kind of menu over serial line.
A simplified context would be GitHub - reppr/softboard: arduino software breadboard
This type of sketch gains essential functionality by assuming the terminal sends line by line as the arduino GUI serial monitor does. Let me explain:
The serial menu works on a couple of one letter commands and numbers. In the case of softboard (a type of software breadboard used to run tests on hardware while building a project) ´a´ shows numeric and bar graph representation of all analog input readings. ´P13´ selects pin 13, ´O´ configures it as output, ´H´ switches it on, and similar. So ´P13OH´ would switch the led on and tell the user it did, ´L´ switches it off again.
´P9OW123 P0v´ runs the heater on pin 9 with pwm value 123 and lets you continuously watch temperature readings from the sensor at A0.
To be useful to beginners the menu tries to be self explanatory. So if the user omits the pin number and sends a bare ´P´ it would inform the user that she must enter a number for the pin to select.
I do use the same approach for much more complex things than softboard, like generating polyphonic pulses on piezzos to produce rhythms, notes and chords (lower audio spectrum only).
I would not want my sketch to stop playing while making up my mind what keys to press next before entering a line. And then RAM (for buffering) is precious too. So I do have my reasons not wanting to change the fundamental design of these sketches 
Works well an the arduino GUI serial monitor, but I prefer text console wherever possible and would like to run it on a headless raspberry pi where arduino gui is sloooow. Screen would be
handy (I use it on the raspi anyway) if i knew how to configure it to send line by line as the arduino gui does.
Comments?
There is nothing in that code that understands where a packet starts and ends. You need to send some kind of "Hey, this is the end of a packet; you can use the data now" marker. That whole sketch is based on the erroneous assumptions that all the data that is a packet will arrive very quickly, and that there will be a significant pause between packets.
Not robust code at all.
PaulS:
That whole sketch is based on the erroneous assumptions that all the data that is a packet will arrive very quickly, and that there will be a significant pause between packets.Not robust code at all.
but, but...
It worked reliably in all my use cases over years
But yes, I do see your point:
this was always from the Arduino GUI serial monitor, keyboard input.
I was not aware of this dependency. Thanks for pointing that out.
I made up my mind to use a (ring)buffer and an ´end of data package´ code.
I´m inclined to use linefeed as end token, but must check first if this is not asking for trouble again...
Talking about LF: I´m thinking about dropping any CR. Hope that would eliminate another dependency.
Not sure about that, though.
Thanks for sound advice.
I´m inclined to use linefeed as end token
Linefeed or carriage return are quite often used - as long as whatever is sending the data sends (or or both of) them.
I popped up here
to ask
how to configure my terminal program to work together with my sketches,
realized by the given answer that my serial menu was highly dependent on
my former use cases with the Arduino GUI Serial Monitor window
but did not work well in situations like running 'screen' on the Raspberry Pi by design,
so
started to rewrite code,
adapted the other parts to fit,
deleted this and added that,
run tests over and over again,
and ended up with code that seems to work well for me now
but needs much more testing...
I like the way it went 
thanks for the given feedback so far.
If someone feels like testing the result, please do so GitHub - reppr/softboard: arduino software breadboard
It´s an example using a serial menu to access Arduino pins, a kind of 'software breadboard'.
It can be useful in development for testing hardware units, or calling your own code from the menu, before you fit it all together.
Defaults to 115200 baud.
Before I might try to implement serial menu as library I would appreciate user feedback...