Fog Creek Software
Discussion Board




Knowledge Base
Documentation
Terry's Tips
Darren's Tips

Debugging `Script Error: illegal token ...'

I am getting a `Script error: illegal token or identifier "<" in ...' and am `finding' it hard to find. It would be nice if you could tell me a bit more about where in the file this might have occurred, or give me some way of otherwise localizing the problem (temporary marks, for example)...

David Ness
Saturday, December 15, 2001

And I'm sad to report my problem is getting worse, not better. First, the number of times I get this error when attempting a preview seems to vary without me changing anything (!).

Worse, if I put a <!---  ... --> around my text, the problem _doesn't_ go away, so I am left completely without a clue as to what I have done to get into such trouble.

David Ness
Saturday, December 15, 2001

This happened to me a few times.  I would copy a script from another page.  It would work on the original page and not on the new page.  I never figured it out.  Seemed like the second page was jinxed.

I solved it without really knowing why or how by dumping the new page and starting it all over again.  I think in another case I deleted the whole script and typed it over again.

It was like CityDesk could find an "illegal token" that I couldn't actually see in the editor.  I could see it in the FrontPage editor either.

Terry Kearns
Saturday, December 15, 2001

Hmm... I guess that sounds _real_ serious to me. Whenever I end up in a situation where something just `goes wrong' and doesn't have traceable antecedents and consequences, I have found that all kinds of buried `treasure' (you know, the kind of `treasure' that dogs bury) is just a whiff away...

David Ness
Saturday, December 15, 2001

The most likely cause of this is that some HTML tags got into your CityScript.

For example if you write
{$ .headline $}
in normal mode, then make .headline bold, this will actually generate the following HTML:
{$ <STRONG>.headline</STRONG> $}

The first < inside the CityScript is tripping up the CityScript parser.

When you're having trouble finding what's causing a script error, don't forget to check in the template itself. Sometimes the template itself has the problem, not the article.

Another thing to check for with templates and HTML files (but not articles) -- look in HTML mode and make sure that there's no additional text after the first </HTML>.

Joel Spolsky
Saturday, December 15, 2001

This is a nasty one (for me, that is). I think I can, fairly conclusively, report a `bug' is the `Preview Error Displayer'---to wit, if you leave that panel open and re-Preview, the errors generated in the new run will be concatenated on to the end of the earlier report, thus making it look like you are getting more errors the second, third, ... pass. That has been distracting me for a while. Now I know to close the error panel before re-Previewing to get a `fresh' report.

So I am back to an error, and it is reported as being an error of use in a "<", perhaps the single worst character to have trouble with in an HTML file, as it is nearly impossible to find a `loose' <, if that's what it is, in a file that is so full of legitimate < characters.

I need some way to point at the root cause of the problem. I am (thankfully) still running in `tiny' mode with <50 pages. If I can't find a problem in such a small complex of information, I'm afraid that it would clearly be impossible for me to find it if 500 or 5000 files were involved.

I have passed my article file to Arachnophilia, and it doesn't report any problem with my HTML. Can anyone suggest a sane approach to (1) isolate the file likely causing the problem and (2) getting a pointer to somewhere near where the problem is being triggered within that file?

As it is, I'm afraid that the error report might just as well have been written in Redmond and say, as they usually do `You Lose, Idiot!'...

David Ness
Saturday, December 15, 2001

What file does it say it's in?

Open that file, switch to HTML mode, and look carefully inside all the {$...$} cityscript to make sure there are no HTML <tags> inside the {$...$}

Joel Spolsky
Saturday, December 15, 2001

It says it is in `\Current\Article Title (which, AFAIK isn't a `file name', but may most likely refer me to the main HTML file of the article (?). If so the article doesn't contaiin _any_ `City Script'. However, it may contain some dollar signs from some other context, so I'll write a piece of perl to translate $ into &dol; just in case that's it.

By the way, I appreciate your taking the trouble to help, this is one of those nice times that it _isn't_ an emergency for me, though I am very happy to make progress...

David Ness
Saturday, December 15, 2001

Can you email your CityDesk file to info@fogcreek.com ? I'll have a look.

Joel Spolsky
Saturday, December 15, 2001

... I suspect the error is probably in the template that this article is using...

Joel Spolsky
Saturday, December 15, 2001

I changed the program processing my file to write &dol; instead of $, and the problem disappeared. On thinking about it, there are probably perl, j or k fragments in the document, and in any one of these a {$ isn't such an unlikely construct. So although the article did not contain any `City Script' it might have contained something like this.

I'll be happy to send you my .CTY if you still want it, but I figure you probably have enough to keep you occupied. Tomorrow I'll look at my file in detail, and will probably be able to report definitively. Given what I've seen, though, I'd guess trying to differentiate `City Script' constructs from just plain `{$' occurrences, at least as a warning, might be useful in pointing the user to the true source of their difficulty.

David Ness
Sunday, December 16, 2001

I have verified my last preliminary diagnosis. The problem was buried in a fragment of perl code where the statement `URL{$_}' (a perfectly sensible bit of perl) must have looked like some `City Script' to the parser.

I guess the problem with this, from a user's viewpoint, was that the parser ended up reporting some kind of difficulty with a "<", which must have been a consequence of the parse, and this proved to be misleading, as no "<" was much in evidence in the vacinity of the thing that caused the error.

Anyway, as I said before, the replacement of $ with &dol; seemed to do the trick.

Thanks again for the support.

David Ness
Sunday, December 16, 2001

Another solution is to change
{$
to
{{$$}$

This is actually in the CityDesk online help somewhere in a topic that explains what to do when you need to have {$ in your output.

Joel Spolsky
Sunday, December 16, 2001

I'm using

  {<!-- ugh -->$

in HTML mode. That way, if I cut and paste to Word from normal mode I don't have to go back through and fix things.

Garth Kidd
Sunday, December 16, 2001

Those are OK ideas too. Is there any chance that it would be useful to have a City Desk `import' function which would behave a lot like Cut-and-Paste (the way I currently import content into my Articles) but which would assume that the `external text' didn't have `City Desk' constructs, and would impose appropriate escapes on the way in?

I can well see, of course, why you might want `City Script' commands inside an article, but it strikes me that it might be a help to prevent them from being inadvertantly imported.

David Ness
Sunday, December 16, 2001

Another way to solve this problem (I'm on a roll today). Suppose your file is a perl file, foo.pl.

Go into View|File Types, add pl to the list, and turn OFF the "contains CityDesk code" option.

This way .pl files will never be parsed by the CityScript compiler.

Joel Spolsky
Sunday, December 16, 2001

*  Recent Topics

*  Fog Creek Home