What do you think about only doing this if the .cow file is really a perl script (i.e., we removed a perl variable declaration near line 53)? Then we wouldn't need the cube.test changes, and defining new .cow artfiles would be easier.

On the one hand, this is a problem of my own making by parsing a flat .cow file format that I made up.

But having the .cow format be "a perl script that declares a variable named $the_cow" was almost certainly just the easiest thing to implement, not a carefully considered architectural decision, and letting users define .cow files as flat ASCII art without escaping seems nice?

do you prefer that all work happens in a separate branch or is it not a large concern

Doesn't matter from my perspective, whatever's easiest on your end is good. (In Git, I'm normally never affected by how your working copy is organized and all my workflows are the same whether you're on a local branch or not.)

In D14170#156887, @epriestley wrote:

What do you think about only doing this if the .cow file is really a perl script

So always do variable-replacement, and only do "unescaping" if $the_cow was found/removed? It sounds like a new day for .cow makers.

So always do variable-replacement, and only do "unescaping" if $the_cow was found/removed? It sounds like a new day for .cow makers.

Yeah, I think this gives us the best behavior. If you're writing a new .cow you just put the art in the file without worrying about anything. I'm sure a .cow renaissance is close at hand now that it will be slightly easier to create new .cow files.