[Condor-devel] Is string quoting for custom job attributes broken in 7.4.x?

[Ian Chesal <ichesal@xxxxxxxxxxxxxxxxxx>]

I'm having some trouble wrapping my head around Condor, specifically condor_submit, string quoting for custom job attributes.

Can someone help explain the behaviour here? It seems inconsistent at best and perhaps even broken.

The docs for string attributes in 7.4 say this:

 String
 A double quote character, followed by an list of characters terminated by a double
 quote character. A backslash character inside the string causes the following character
 to be considered as part of the string, irrespective of what that character is.
 See: http://www.cs.wisc.edu/condor/manual/v7.4/4_1Condor_s_ClassAd.html#SECTION00511100000000000000

That's a vague bit of description so I was doing some testing to see what it amounts to. The following examples highlight some of the confusion, all are in the context of a custom attribute added to a job via the submit file, submitted with condor_submit.

The first bit of weird is how literal \ is treated in the string. For example:

 +submission_dir = "\\foo\bar"

 $ condor_q -l | grep submission_dir
 submission_dir = "\\foo\bar"

 $ condor_q -f "%s\n" submission_dir
 \\foo\bar

That's a bit odd based on the description given in the docs. I would have expected \\ to be a literal \ character and \b to be a bell character. This might seem okay until you realize that it removes your ability to encode a tab or newline character in to the string value of an attribute. For example:

 +submission_dir = "\\foo\tab"

I would expect that \t would be a tab character, but it isn't:

 $ condor_q -l | grep submission_dir
 submission_dir = "\\foo\tab"

 $ condor_q -f "%s\n" submission_dir
 \\foo\tab

I would have expect that \t was the tab character and \\f was a f character preceded by a \ character. But that doesn't seem to be the case.

How can I encode non-alphanumerics in string values? \n, \t, \b type stuff?

And for the final bit of weird: what if we want a " in a string? It can be done, using the \ to escape it. That seems okay until you see how Condor handles the formatting for the output:

 +submission_dir = "\\foo\"bar"

 $ condor_q -l | grep submission_dir
 submission_dir = "\\foo\"bar"

 $ condor_q -f "%s\n" submission_dir
 \\foo"bar

Interesting -- the string formatted version of that attribute's value *removed* the \ character in front of the " -- why in this case, but not in the other cases? I would have expected "\\foo\bar" in the first example to yield "\foobar" when printed with string formatting if the \ was being handled consistently for all strings. But \ appears to have special meaning depending on which character it precedes.

Can someone clear up the rules for me?

Thanks!

- Ian 
-- 
Ian Chesal
ichesal@xxxxxxxxxxxxxxxxxx