## WeBWorK Main Forum

### special characters to be avoided?

Number of replies: 0

No, I'm not writing about myself before my morning routine.

I've long known, and tell our instructors, not to use periods in the names of their problem sets or problems.  It (at least it used to) lead to problems generating hardcopy, at least if there were associated images.

I also tell them not to use underscores, but I don't remember why, and I don't know if that is really (or is still) a problem.

I recently discovered that there is a good reason not to use hyphens that is related to mysql.  Hyphens are normally interpreted as operators in msyql, so if you have a table with a hyphen in its name and try to use the msyql CLI to get data out of that table, you'll have trouble.  There is a fix:  use backticks to enclose the table name.  The problem with that fix is that if you are writing a perl script (as one does) to grab data out of the webwork mysql database, and you enclose something in backticks, this tells perl to evaluate the enclosed expression in the shell.  This is not what you want to have happen if the only reason you enclosed the argument in backticks was to pass to the mysql CLI.

So the questions:

(1) Does anyone know a good way around my current problem.  Adapting a script of Nandor Sieben's, I have the line:

mysql(qq[select user_id, timestamp from "$table"]); where$table is a table name in mysql that contains a hyphen.  This fails as mysql interprets that hyphen as an operator  (_All_ our mysql tables have hyphens as every single course name on our system currently contains a hyphen).  If I use backticks instead of quotes, it fails because $table gets evaluated at the system level. (2) Besides avoiding hyphens in the future, are periods a problem in course names or homework set names? Are underscores a problem in course names or homework set names? And what other special characters ought one to stay away from as separators in course, homework and problem names (space, \ and / presumably. Also "#" and "$" I'd guess.  What about ":"?).

I have to confess having ruled out . and _, if I have to rule out - as well, I feel that only leaves me with : as a separator that seems clear and easy to type.  But I honestly don't remember why we are avoiding _, and maybe that is an error on my part.  And my avoidance of . is based on experience, but probably experience in WeBWorK 2.1 or 2.2, not in 2.7 which we are currently using.

Thoughts and experiences appreciated.

thanks,  Hal