[linux] Linux Verzamelmail, Volume 46, Nummer 10

[Jan Paul Smit]

Beste Linux-mensen,

In een vorige mail schreef Daniel von Asmuth:

     https://wiki.debian.org/FullT <https://wiki.debian.org/FullTextSearch>
> >         https://www.linuxlinks.com/de
<https://www.linuxlinks.com/desktopsearchengines/>
> >         https://dtsearch.com/   (geen gratis software)
> >
> > https://www.linuxuprising.com/
<https://www.linuxuprising.com/2019/05/drill-new-desktop-file-search-utility.html>
> >         https://linuxhint.com/best-se


Ik heb de suggesties bekeken, maar dit is nog te moeilijk voor mij en ik
heb op dit moment niet de tijd om me er heel erg in te verdiepen.

Bovendien gaat het mij eigenlijk heel eenvoudig om zo nu en dan mijn –
voornamelijk Word 97 – documenten in mijn map Documenten op een bepaald
woord te doorzoeken, als ik er niet uit kom met zoeken op een woord(deel)
in de bestandsnaam.

In mijn onschuld dacht ik dat het om een eenvoudig stukje code zou gaan,
maar uit jullie reacties begrijp ik dat het ingewikkelder ligt.

Ook de suggestie van Daniel von Asmuth

“Probeer eens:
        grep -r -i -H -s fiets /home/jan-paul/Documenten”

heb ik uitgeprobeerd, maar werkte bij mij niet.

Ik gebruik de code ‘ | cut -d: -f1’ om een overschot aan tekst in rtf-,
txt- en html-bestanden kwijt te raken, maar wel het pad te behouden.

zgrep heb ik ook uitgeprobeerd in plaats van grep; geen resultaat.

Toch is het merkwaardige dat grep sommige Word-documenten met een een
bepaald zoekwoord wel op de lijst zet en andere Word-documenten met
hetzelfde zoekwoord niet.

Ik heb van alles uitgeprobeerd:

*Resultaten*

= Er zijn geen aanwijzingen te vinden in Ubuntu/Bestanden bij
‘Eigenschappen’ en ook niet in LibreOffice bij Bestand/Eigenschappen of bij
Extra/Opties die een verklaring kunnen geven. Bijvoorbeeld een andere
eigenaar, of andere naam/groep.

= Het heeft niet te maken met de grootte van het Word-document, niet met
hoe lang geleden het document aangemaakt is en ook niet met mijn vorige of
eervorige computer.

= Als ik een oud Word-document dat eerst wel reageerde op een bepaalde
zoekopdracht nu opnieuw bewerk in LibreOffice en opnieuw bewaar als
Word-document, pikt grep het daarna niet meer op met dezelfde zoekopdracht.

= Nieuwe Word-documenten die ik net aangemaakt heb in LibreOffice reageren
niet op zoekopdrachten.

= Als ik een Word-document dat niet reageert op een bepaalde
grep-zoekopdracht bewaar als txt-bestand of rtf-bestand of html-bestand
reageert dat wel op de betreffende grep-zoekopdracht.

*Mogelijke oplossing?*

Mijn vermoeden is nu dat in de onzichtbare tekst helemaal aan het begin van
een Word-document (meta data?) soms wel en soms niet een bepaalde code of
string staat die grep verhindert het document door te zoeken.

Als dat vermoeden klopt, zou het probleem opgelost kunnen worden als grep
de onzichtbare tekst overslaat. Is er misschien een parameter die ik aan
grep toe kan voegen die grep kan dwingen de onzichtbare tekst in
Word-documenten over te slaan?

Geert schreef: “Een reden om de manual van grep te raadplegen  `man grep  #
q voor Quit`”

Ik heb geprobeerd een overzicht te krijgen van de commando’s van grep te
krijgen door deze regel in het Terminalvenster te plaatsen, maar dat werkt
niet.

Op internet vond ik een grep-handleiding:
https://www.gnu.org/software/grep/manual/grep.html#Generic-Program-Information

Helaas is die ook te moeilijk voor mij. Ik heb *-a* , *-z* en *-R *toegevoegd
aan mijn grep opdrachten, maar zonder resultaat.

‘Hoofdstuk 2.1.6 File and Directory Selection’ is misschien de juiste plek
om verder te zoeken. Er staat bijvoorbeeld: “By default, type is ‘binary’,
and grep suppresses output after null input binary data is discovered, and
suppresses output lines that contain improperly encoded data. When some
output is suppressed, grep follows any output with a one-line message
saying that a binary file matches.”

Nu staat in mijn lijst van hits van een grep-zoekactie vóór de
doc-bestanden telkens: “Binair bestand”

Maar goed, ik kom niet verder, want ik heb te weinig achtergrondkennis.

Kan iemand mij verder helpen?

Met vriendelijke groeten, Jan Paul
------------- volgend deel ------------
Een HTML-bijlage is gescrubt...
URL: <https://lists.nllgg.nl/pipermail/linux/attachments/20200619/057923d5/attachment-0001.htm>