ignore errors in shell.var_expand

[minrk]

If an error is raised in the formatter, leave it untransformed. This means that var_expand("$foo") will return "$foo" if foo is undefined, but more importantly it will not raise when var_expand is used on literal code that doesn't expect to be expanded (e.g. %prun arguments).

A few tests included.

The real answer to this problem is to not call var_expand where it shouldn't be called, just as with the argument split. We really treat all magics as shell options, and we shouldn't, but until we get that whole logic cleaned up, this is a temporary solution. The only drawback is that ls $files will result in ls $files instead of NameError if files is undefined, which is the most logical behavior. But valid calls to %prun are more important than raising the right error in invalid calls to ls.

closes #1412

[takluyver]

Just to note: catching the exception there will mean that if any part can't be expanded, no part will be: if only a is defined, echo {a} {b} won't expand a or b. I think that's probably the behaviour we want, but it's worth mentioning.

I agree that we should in due course distinguish magics which take shell options from magics which take Python code.

Other than that, this seems fine to me.

[minrk]

Yes, good point. This is obviously not the optimal solution, but since the 'real' answer is that it should not be called in the first place, it seems like an acceptable band-aid until magic parsing is rewritten from scratch.

[minrk]

We should let this sit for a day or two, in case anyone thinks raising a NameError when you do !command {typo} is sufficiently important that we need a more careful fix right now.