Why a string starting with 'cat….' outputs with a different color in Programiz?
Question:
I can’t figure out why when I print a string starting with ‘cat..’ (like category, cathedral, catch, …) in the Programiz Online Python Compiler it appears in green (or gray and italic in dark mode) instead of black (or white in dark mode).
print('cathedral')
print('car')
Anyone knows? Is there a joke or something I’m missing?
Tried in a different Programiz Online Compiler, like the C one, and it also happens there!
Answers:
After testing out various strings, I think the terminal emulator is lazy and is treating the word "cat" as the bash command cat. The color will only change if the first 3 letters are exactly "cat"; if anything separates them, or there is a space before them, nothing happens. Similarly, it does not at all care what comes after it. It is also interesting that by first three letters, it is looking at the terminal output and not the python string. for instance print("ncat") still produces the different color, just on a different line.
I attempted to test calling cat through python to see if I was right, but the compiler refuses to load os or subprocess. I can confirm it happens on my end though.
Ok, since this is client side, the easy way to know is to inspect javascript code (even if it is minified, that part is quite readable. Just search for cat in it)
And, indeed, there is explicit code to tread as "batch comment" some regexp in the output area.
Including ^cat.*. And many others.
For example
print("/tmp/bla")
print(">") # but with nothing else
print("node bla.js")
print("mono ouchNoPlease.cs")
print("javac monoWasNotThatBadAfterAll.java")
Why cat is among a series of regexp apparently for compiler commands, I don’t know. And why gcc or many other classical compilers aren’t, neither. Nor why, since cat is, no other unix/bash/batch command are.
But whatever the reason, it is no accident, and there are explicit code to color anything starting with cat
Edit: my (other) mistake, gcc is in the list. It was just before cat, and since I read this code by researching cat…
Here is the extract of the javascript code of programmiz:
[{token:["comment.line.colons.dosbatch"],regex:"(?:^|\b)gcc($|\s.*$)",caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:"^(/tmp).*$",caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:/^g++.*$/,caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:/^cat.*$/,caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:/^>/},
{token:["comment.line.colons.dosbatch"],regex:"^(javac).*$",caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:"^(csc|mono).*$",caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:"^(node).*$",caseInsensitive:!0}]
Wider context is that this is inserted into Ace (since programmiz use Ace editor) syntax coloring rules.
So, the only outliers in the list are > and /tmp/ for the non command strings. And for commands, well, it is precisely cat.
Maybe there is a language compiler/interpreter outside unix world that is called cat I am not aware of. Or maybe cat is considered to be a very raw interpreter (after all, it does execute a very simple language that prints all instructions :D)
I can’t figure out why when I print a string starting with ‘cat..’ (like category, cathedral, catch, …) in the Programiz Online Python Compiler it appears in green (or gray and italic in dark mode) instead of black (or white in dark mode).
print('cathedral')
print('car')
Anyone knows? Is there a joke or something I’m missing?
Tried in a different Programiz Online Compiler, like the C one, and it also happens there!
After testing out various strings, I think the terminal emulator is lazy and is treating the word "cat" as the bash command cat. The color will only change if the first 3 letters are exactly "cat"; if anything separates them, or there is a space before them, nothing happens. Similarly, it does not at all care what comes after it. It is also interesting that by first three letters, it is looking at the terminal output and not the python string. for instance print("ncat") still produces the different color, just on a different line.
I attempted to test calling cat through python to see if I was right, but the compiler refuses to load os or subprocess. I can confirm it happens on my end though.
Ok, since this is client side, the easy way to know is to inspect javascript code (even if it is minified, that part is quite readable. Just search for cat in it)
And, indeed, there is explicit code to tread as "batch comment" some regexp in the output area.
Including ^cat.*. And many others.
For example
print("/tmp/bla")
print(">") # but with nothing else
print("node bla.js")
print("mono ouchNoPlease.cs")
print("javac monoWasNotThatBadAfterAll.java")
Why cat is among a series of regexp apparently for compiler commands, I don’t know. And why gcc or many other classical compilers aren’t, neither. Nor why, since cat is, no other unix/bash/batch command are.
But whatever the reason, it is no accident, and there are explicit code to color anything starting with cat
Edit: my (other) mistake, gcc is in the list. It was just before cat, and since I read this code by researching cat…
Here is the extract of the javascript code of programmiz:
[{token:["comment.line.colons.dosbatch"],regex:"(?:^|\b)gcc($|\s.*$)",caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:"^(/tmp).*$",caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:/^g++.*$/,caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:/^cat.*$/,caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:/^>/},
{token:["comment.line.colons.dosbatch"],regex:"^(javac).*$",caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:"^(csc|mono).*$",caseInsensitive:!0},
{token:["comment.line.colons.dosbatch"],regex:"^(node).*$",caseInsensitive:!0}]
Wider context is that this is inserted into Ace (since programmiz use Ace editor) syntax coloring rules.
So, the only outliers in the list are > and /tmp/ for the non command strings. And for commands, well, it is precisely cat.
Maybe there is a language compiler/interpreter outside unix world that is called cat I am not aware of. Or maybe cat is considered to be a very raw interpreter (after all, it does execute a very simple language that prints all instructions :D)