Colon ":" interpreted as command separator, bug or feature?

[foosel]

Just noticed an unexpected behaviour by pure accident...

Including a colon in a command will cause the command to be split into two commands at the colon. So far, so interesting (not according to protocol though!). However, there is no way to escape this colon so it's impossible to use it in messages send from the host to the display.

Example:

>>> M117 Hello :)
<<< ok
<<< echo:Unknown command: ")"
<<< ok

Could we get some way to escape this? E.g. by tracking if last read character was a \ and if so not interpret this as a command separator? Also: this stuff needs to be documented!

Alternatively it might be that it is a simple typo, like already mentioned in #1035 and the : here should in fact be a ; (which would definitely make more sense given the following && comment_mode == false check and the spec for comments in GCODE):

void get_command()
{
  if(drain_queued_commands_P()) // priority is given to non-serial commands
    return;

  while( MYSERIAL.available() > 0  && buflen < BUFSIZE) {
    serial_char = MYSERIAL.read();
    if(serial_char == '\n' ||
       serial_char == '\r' ||
       (serial_char == ':' && comment_mode == false) ||
       serial_count >= (MAX_CMD_SIZE - 1) )
    {

(link to line in Marlin_main.cpp - specific version to make sure link stays valid)

[foosel]

On second, third, ..., n-th look, this is a bug causing comments, especially in-line comments, to not work at all. Push proposed by @C-o-r-E solves everything.

[daid]

I always thought this was some odd backwards compatibility thing. (I'm pretty sure I had a talk with someone about it a few years ago)

Anyhow, I think this indeed can go. None of the current generation GCode senders depend on this odd behaviour, and it's causing more problems then it's fixing.

[thinkyhead]

Good to see those weird assumptions getting scrubbed out. We recently fixed another one where the SD file reader was ignoring names beginning with underscore. The original author probably thought it was needed to filter OS X custom files, or something.

#1570 looks like a winner!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.