Re: [cssed-devel] cssed-findinfiles-plugin: some problems

[<mic...@ea...>]

Le 13 sept. 2004, =E0 15:08, Iago Rubio a =E9crit :
> On Mon, 2004-09-13 at 00:57, Mich=E8le Garoche wrote:
>> Le 12 sept. 2004, =E0 21:42, Iago Rubio a =E9crit :
>>>> When using the popup menu in the editor window to search for terms=20=

>>>> and
>>>> if no term is selected in the current file, there is no refresh of=20=

>>>> the
>>>> base directory in the plugin. This only occurs when a search term =
is
>>>> selected in the active file.  A bit confusing for me here.
>>> What pop menu entry, "In current base dir" or "In file's base dir" ?
>> I think the problem does not even raise as far as the current base =
dir
>> is concerned, or maybe I don't understand what is the current base=20
>> dir.
>
> Yes, this is completly confusing.
>
> The "Current base dir" speaks about the current base directory in the
> "Base dir" entry. Not the file's base directory nor the application's
> current directory.
OK, but in the test I've made, it was the same, so that's why I said=20
the problem did not araise.

> The behaviour will be (?):
>
> 	1.- if no text selection, when clicked "In file's base dir", =
change
> just the base directory and avoid to start the search.
>
> 	2.- if no text selection, when clicked "In file's base dir", =
change=20
> the
> base directory and search for the current search term.
2 is better since it allows the user to search for a term in the active=20=

document without the need to first either type the word in the file and=20=

select it or search for the word and select (which is kind of weird=20
when the plugin claims precisely to be a search plugin :-).

Besides, it will be a nice plus: you can search by selecting a word or=20=

by entering a word in the search field, very useful when you want to be=20=

sure that a term does not exist in a file for example.

>>>> When the search process encounters a special file, the search takes
>>>> ages to end and there is a you can have the same error message as =
in
>>>> filebrowser plugin, just to reassure the user.
>>> Hmmm! It should not search into special file (mean character devices
>>> and
>>> such) as we are passing find the "-type -f" parameter.
>>> Could you tell me how to reproduce it ? or, What kind of special =
file
>>> is
>>> opened by the proccess ?
>> Actually I thought that was a special file encountered, because the
>> result does not give all the strings in a row, and I know I have more
>> reference to the search term later in a subdirectory of the base
>> directory. But the problem may not be this one, it seems that there =
is
>> a limit to the number of lines or maybe the buffer size, so that all
>> results are not displayed in a row.
> It seems to be a bug.
>> There is a long time when it seems
>> to do nothing then some other strings are shown, then search, but
>> definitively not all strings are shown. So either, there is a problem
>> of size or some character in a file which is interpreted as command =
or
>> something else which confuses the program. I get those warnings in
>> console:
>>
>> This is the last line shown in cssed (same on the command line, so=20
>> it's
>> not inherent to cssed):
>> ./html/user_interface.html:15: <a class=3D"el"
>> href=3D"index.html#index">Main Page</a> <hr size=3D"1"><address
>> style=3D"align: right;"><small>Generated on Wed Aug 11 22:33:33 2004 =
for
>> cssed plugable interface by
>>
>> Then the warnings in console (fully false since those files exist).
>> grep: ./Pictures/Portraits: No such file or directory
>> grep: choisis.pnpCatalog: No such file or directory
>>
>> grep: ./WasonDesktop/Sans: No such file or directory
>> grep: titre: No such file or directory
>> grep: 3.rtf: No such file or directory
>>
>> grep: ./WasonDesktop/Sans: No such file or directory
>> grep: titre.txt: No such file or directory
>
>> And precisely in WasonDesktop, there are a bunch of files containing
>> "cssed", which was the search term.
>> After investigating more, the problem raises when encountering a file
>> with a space in it, very frequent on Mac.
>
> Ah! I see now. It can be easily solved. I will test an approach.
>
> Could you please try this command line to test if it correnctly =
handles
> file names with embeded spaces ?
>
> find /path/to/find -print0 -type f | xargs -0 grep -n search_term
I have to cancel the find, it does not end.
Plus it searches in all files, all depth.

>
> Quick explaination: 'find -print0' will null terminate the file names,
> 'xargs -0' will search for the null character to get the end of file's
> name.
> I think it should work even with carriage return embeded file names.
That's not a carriage return (it is not an authorized character), it is=20=

a space (code 32).

> Test fix in CVS.
> Patch attached.
I've not integrated it since it freezes completely find on the command=20=

line.

Mich=E8le
<http://micmacfr.homeunix.org>