#25 Text search results invisible

[Mattis Fjallstrom]

Hi,

I'm using Cscope 15.7a in a gnome terminal window on Ubuntu 9.10. Cscope is an amazing tool; whenever I need to understand a larger codebase it's the first tool I go to.

However, there's one problem that I've seen for quite a while and I can't seem to find a solution.

When searching for a text string or an egrep pattern, many of the matches are invisible. They're there, I can move the cursor from line to line and select them and in Vi they display correctly, but the match line has no content. No text. Sometimes some of the matches show and others not.

While googling for a solution I found that other people have the same problem. I tried running in RXVT instead of gnome-term but got the exact same results.

Any clues?

Cheers,

Mattis

[Hans-Bernhard Broeker]

The most common reason by far for that kind of problem are source file with broken (wrong-platform) line-breaks. Compilers may accept them, but cscope doesn't.

[Mattis Fjallstrom]

broeker, thanks.

That might be the case. If that was the problem though, shouldn't it affect the other search methods as well? (C symbol, global definition, et.c.). Those work perfect every time for me, I never have the problems that I do with egrep and text.

Thanks,

Mattis

[Rich Coe]

# on sources that have '\r\n' in them, egrep produces no output
# strip the carriage return out of the output

[Rich Coe]

# cscope.egrep.out.patch
# on sources that have '\r\n' in them, egrep produces no output
# strip the carriage return out of the output
# rcoe@wi.rr.com
#
--- cscope-15.7a/src/egrep.y 2008-03-12 15:43:56.000000000 -0500
+++ cscope-15.7a.orig/src/egrep.y 2011-06-09 15:32:08.809669622 -0500
@@ -592,12 +592,22 @@ egrep(char *file, FILE *output, char *fo
succeed:
fprintf(output, format, file, lnum);
if (p <= nlp) {
- while (nlp < &buf[2*BUFSIZ])
+ while (nlp < &buf[2*BUFSIZ]) {
+ if ('\r' == *nlp) {
+ nlp++;
+ continue;
+ }
putc(*nlp++, output);
+ }
nlp = buf;
}
- while (nlp < p)
+ while (nlp < p) {
+ if ('\r' == *nlp) {
+ nlp++;
+ continue;
+ }
putc(*nlp++, output);
+ }
lnum++;
nlp = p;
if ((out[(cstat=istat)]) == 0)

[Hans-Bernhard Broeker]

A side note: next time you want to post a patch, please attach it as a file. Patches don't survive posting as free-form comments any better than text files survive being in entirely the wrong format for the platform they're on.

This is really a non-issue. Nobody has an actual need to keep text files in the wrong format. Fix your sources, and the problem will be gone. It's as simple as that.

[Rich Coe]

A properly formatted patch file can be found here:
https://bugzilla.novell.com/attachment.cgi?id=433854

I could not attach the file to this report, the feature was not available.

[Rich Coe]

The source files cannot be 'fixed', as I do not own them.
Fixing source files of a 10000+ file source project should not be required to fix
broken output of a tool.

[Mattis Fjallstrom]

Rich, thanks for the patch.

Hans-Bernard, I'm in the same situation as Rich. A code base of thousands of files, which I don't own and can't easily fix. Further, the product is cross-platform, both Linux and Windows, and development happens on both platforms as well - I guess this is why the MS style line endings have made their way into the code.

I wish I could make all the other developers use proper tools, but that's not going to happen. Instead I'd be told not to use Cscope.

So while there's not a "need" to keep files in multiple formats, there's no easy way around it, either.

[Hans-Bernhard Broeker]

> A code base of thousands of files, which I don't own and can't easily fix.

Owning or fixing those files has nothing to do with this. Using at least marginally competent tools for sharing source code bases across platforms with different line-ending conventions, OTOH, does. It's your version control system that screwed you over, not cscope. As they currently are, those files are not correctly formed C source code on the platform you're using them on. You may want to pretend otherwise, but you'ld be wrong.

> Fixing source files of a 10000+ file source project should not be required to fix
> broken output of a tool.

It's not. It's required because that source (or the revision control system used to manage it) is broken.

Nor is cscope's output actually broken. It precisely reflects the sorry state those source file are actually in. Modifying cscope to display different content than what's actually in those source files would add insult to injury.

[Mattis Fjallstrom]

In my case, the versioning system is SVN. We are using multiple compilers, but the main one is GCC. Editors? Emacs, Vi, Eclipse, Netbeans.

All of these seems to be working fine with our code-base as is. And now, thanks to Rich's patch, so does Cscope. Sure, you can argue that the world is broken and Cscope didn't need fixing, but the fact is that Cscope was less useful than it should or could be, and with the patch it is more useful.

I don't see how that's a bad thing. And it's definitely not insulting or injurious.

[Hans-Bernhard Broeker]

> In my case, the versioning system is SVN.

And that system is perfectly capable of handling the difference between text file formats for you, such that file wouldn't be broken in the first place.

> you can argue that the world is broken

No. But the way you're using your version control system obviously is.

Why compromise dozens of tools when you could just use one of them properly?