GNOME Bugzilla – Bug 330176
check for "locate -i" is broken
Last modified: 2006-03-02 19:21:27 UTC
gsearchtool checks for "-i" option to locate /* check locate command for -i argument compatibility */ g_spawn_command_line_sync ("locate -i [/]", &cmd_stdout, &cmd_stderr, NULL, NULL); on some systems it works ... on some others, it just dumps the whole locate database. This just freezes the dialog for ages where this obviously a quick test :) I'm using locate --version Secure Locate 3.0 beta r3 - Released January 6, 2006 maybe the test should be a simple "locate -i" ? benoit@ibook >>> locate -i; echo $? 0 benoit@ibook >>> locate -X; echo $? locate: invalid option -- X 0
/* run locate again to check if it can find the root directory */ g_spawn_command_line_sync ("locate [/]", &cmd_stdout, &cmd_stderr, NULL, NULL); this other is also broken
Maybe the bug is in secure locate 3.0 beta r3? Why is locate returning the entire database? The command is "locate [/]" not "locate /*".
"The command is "locate [/]" not "locate /*"." what the purpose of "locate [/]" ? is that meant to be "locate -r '^/$'" ? locate by default does not uses regex AFAIK
"is that meant to be "locate -r '^/$'" ?" Yes. This might be a good alternative, but I need to verify that the other flavors of locate can handle the '-r' argument.
Btw, slocate seems slower than locate on my computers. On my fastest machine (P4 3GHZ) i get : benoit@damn:~$ time locate.notslocate -i [/] / real 0m0.084s user 0m0.082s sys 0m0.003s benoit@damn:~$ time slocate -i -r '^/$' / real 0m0.200s user 0m0.184s sys 0m0.004s but on my ppc 1GHZ benoit@ibook >>> time locate.notslocate -i [/] / real 0m0.353s user 0m0.341s sys 0m0.006s benoit@ibook >>> time slocate -i -r '^/$' / real 0m2.474s user 0m2.328s sys 0m0.044s So this blocking test make the UI hang :/
So, what is the best/fastest way to determine if the installed locate command supports the '-i' argument? $ locate --help | grep "\-\-ignore-case"; echo $? The above is fast, but probably not accurate. I'd like to see the man pages for the various flavors of locate. Specifically, the man pages for Solaris, HP, and AIX.
locate --help | grep "\-\-ignore-case"; echo $? doesn't work with slocate :) Is there any locate/slocate that does not have -i ?
Ubuntu bug about that: https://launchpad.net/products/gnome-utils/+bug/30313
"Is there any locate/slocate that does not have -i ?" I would like to see the man pages for the AIX, Solaris, and HP versions of locate, but I believe the answer is yes.
I don't have locate on my AIX 4.3 and 5.2 :)
Rising priority. It basically means the search tool can not be used on some systems.
I have a work-in-progress patch that I need to cleanup. I want to check it into HEAD sometime this weekend.
Created attachment 59666 [details] [review] Proposed patch Benoît, I changed the calls to the locate command to be asynchronous. Can you apply the attached patch and see if this helps?
Created attachment 59677 [details] [review] Updated Proposed Patch
Seems to work for me.
Thanks Vincent. I applied the patch to CVS.
I'll test this tonight. But AFAICS, it doesn't fix anything as you read everything from locate stdout, which takes a very long time ...
else if (string->len > 0) { + if (string->str[0] == '/') { + gsearch->is_locate_database_available = TRUE; + } + broken_pipe = TRUE; + break; + } ok, i was wrong, you're reading only the first line. all right then ?
Right, the idea was to read the first line of output and then kill the locate process.
do you really need to kill it ? closing the pipe should be enough no ?
Yes, I really need to kill it; otherwise, the command could continue to run in the background and eat up CPU time.
slocate -i / | head i don't think head is killing slocate, isn't it ?
i mean that slocate receive a broken pipe signal and dies/handles it like a charm
I just do not know if the behavior you are describing is guaranteed when using glib's IO channels. I did not find documentation in glib's docs to verify it. http://developer.gnome.org/doc/API/2.0/glib/glib-IO-Channels.html
well, just close(2) the reader end of the pipe, and the writer receives a SIGPIPE. That's not related to IO channels. That's the way pipes works.
Feel free to attach a patch. Thanks.
Created attachment 60071 [details] [review] here it is I'm not sure the wait is needed at all, but that's no harm. Btw, when i do a simple search for "AUTHORS", i see that '/usr/bin/locate -i /home/luc/**AUTHORS*' is spawned. Are these '**' OK ?
ping ?
Oops. Your patch was applied to cvs about a week ago. I am not worried about the '**' since it is really the same thing as a single '*'. ;-)