Yes. Hence my "This is very dependant upon the correct and logical formatting of the input." caveat.

If there are any errors in the balancing of parens, it will fail horribly, but as the text is obviously source to some parser somewhere, it's a reasonable, pragmatic, economic ROI decision to say: This 'comment out timing checks script' is only usable on source that parses correctly using a.n.other tool. A pragmatic decision to save having to reverse engineer that a.n.other tool's parser from scratch and without the originial specs.

It will also fail in many cases that would (probably; no spec!) be successfully parsed by that other parser. For example, if the close parens placements are coalesed on a single line, rather than laid out in a logically structured way as per the OPs example:

(CELL
 (TIMINGCHECK
  (SETUP (posedge SI) (posedge CP) (0.14:0.23:0.41))
  (SETUP (negedge SI) (posedge CP) (0.09:0.16:0.30))
  ....(random lines)
  (HOLD (negedge SI) (posedge CP) (0.00:0.00:0.00))
  (HOLD (negedge D) (posedge CP) (0.00:0.00:0.00))
 ))
[download]

In this case, the close paren of the (CELL block will also be commented out and the result will fail to parse with that other tool.

In an ideal world one would go back to the authors of a.n.other tool, request a copy of their parser, or the specifications from which it was drawn, and produce a 'proper parser' script that understood all the rules of the input language and performed the required operation.

But this isn't an ideal world, and time is money, and performing ad-hoc text munging tasks like this are exactly what Perl was invented for. (Amongst other things. :)

But then again, it seems that the authors of a.n.other tool were either on-the-ball or responsive to in-use experience of using their tool, because it seems they already may have provided an option that make this entire thread redundant.

It's just a shame that post hasn't received the attention and votes it deserves. It's a non-perl solution, but, assuming the poster has correctly recognised the nature of the data and OP is using the correct a.n.other tool, by far the best solution to the OPs problem.

A number of additional points:

I added some keywords to the title of this node because it is quite relevant to my line of work, and I know I will want to refer back to it in the future. When I ran a SuperSearch on "Verilog" and/or "SDF", this node was not located. Of course, I linked to this node, but maybe others will be able to locate it more easily now.

The syntax of the code in the OP is specified in the IEEE Standard 1497-2001 document, titled:

IEEE Standard for Standard Delay Format (SDF)
for the Electronic Design Process
[download]

I'm mentioning this just in case anyone following this stream was wondering what this strange syntax was. It is used by digital IC hardware designers who use the Verilog language.

I like BrowserUK's solution. In the SDF syntax, to quote the spec: "White space is never significant except when used within quoted strings or to separate lexical tokens." So, end parentheses need not be on separate lines. We have had the need to hack an SDF file, similar to what the OP poster has done, but our solution is pretty nasty. At some point, I will probably give this a try.

I am one of those who upvoted shoness's node because that may well be the best solution for the OP. It is too bad the the OP has not responded to this node, because there may be additional solutions which could be offered if these few basic questions were answered.

That being said, we have decided that hacking our SDF file is the most cost-effective solution, given our circumstances. We do disable timing checks using simulator options, but we have other constraints which make it difficult to disable them for all cells. We should extend our own cell library to handle this case, but that takes more time and resources than hacking the SDF file.

Thanks to all for contributing to this very useful (at least to me) thread. I'm usually not this long-winded, so I'll shut up now.