Comment rechercher un modèle contenant des tirets dans les pages de manuel?


11

J'essaie de trouver une commande pour rechercher un modèle contenant des tirets dans toutes les pages de manuel.

J'ai regardé man manet trouvé ces 3 options:

-K, --global-apropos

Recherchez du texte dans toutes les pages de manuel. Il s'agit d'une recherche par force brute, et cela prendra probablement un certain temps; si vous le pouvez, vous devez spécifier une section pour réduire le nombre de pages à rechercher. Les termes de recherche peuvent être de simples chaînes (par défaut) ou des expressions régulières si l' --regexoption est utilisée.

-w, --where, --path,--location

N'affichez pas réellement les pages de manuel, mais imprimez les emplacements des fichiers source nroff qui seraient formatés.

-S list, -s list,t--sections=list

La liste est une liste séparée par deux-points ou virgule des sections manuelles spécifiques à l'ordre à rechercher. Cette option remplace la $MANSECTvariable d'environnement. (L' -sorthographe est pour la compatibilité avec le système V.)

J'ai essayé de les combiner pour rechercher le modèle mark-modified-linesqui est une option de ligne de lecture décrite dans man bash:

$ man -s1 -Kw mark-modified-lines

Mais il ne trouve aucune page:

No manual entry for mark-modified-lines

Et la commande se termine avec le code 16.
J'ai pensé que la syntaxe de la commande était peut-être erronée, mais cela ne semble pas le cas, car cette commande trouve correctement les 5 pages de manuel de mon système qui contiennent le mot guitar:

$ man -s1 -Kw guitar

  /usr/share/man/man1/ffmpeg-all.1.gz
  /usr/share/man/man1/ffserver-all.1.gz
  /usr/share/man/man1/ffplay-all.1.gz
  /usr/share/man/man1/ffmpeg-filters.1.gz
  /usr/share/man/man1/ffprobe-all.1.gz

J'ai pensé que peut-être les traits d'union dans le mot causaient un problème. Dans man bash, j'ai trouvé l' --regexoption qui est décrite comme suit:

--regex

Afficher toutes les pages avec une partie de leur nom ou de leur description correspondant à chaque argument de page comme une expression régulière, comme avec apropos(1). Puisqu'il n'y a généralement aucun moyen raisonnable de choisir une «meilleure» page lors de la recherche d'une expression régulière, cette option implique -a.

J'ai essayé d'utiliser cette option et de remplacer le mot mark-modified-linespar l'expression régulière mark.modified.lines, où les traits d'union sont eux-mêmes remplacés par le métacaractère .qui devrait correspondre à n'importe quel caractère:

$ man -s1 -Kw --regex 'mark.modified.lines'

Il n'imprime toujours aucune page, alors que je sais que le texte est écrit dans la bashpage de manuel.

Le métacaractère .dans l'expression régulière semble être analysé comme prévu, car cette commande:

$ man -s1 -Kw --regex 'mark.mo'

Tirages:

  /usr/share/man/man1/x11perfcomp.1.gz
  /usr/share/man/man1/xditview.1.gz

Et ces 2 pages de manuel ( x11perfcomp, xditview) correspondent toutes deux à l'expression régulière mark.mo. Plus précisément, man x11perfcompcontient cette ligne:

Mark Moraes wrote the original scripts to compare servers.
^^^^^^^

Et man xditviewcontient cette ligne:

    Mark Moraes (University of Toronto)
    ^^^^^^^

Cependant, man -s1 -Kw --regex 'mark.mo'n'imprime pas la page de manuel bash:

/usr/share/man/man1/bash.1.gz

Alors que je m'y attendais, car il contient cette ligne:

mark-modified-lines (Off)
^^^^^^^

Est-il possible de rechercher un motif contenant des tirets dans les pages de manuel?

Réponses:


15

man -Krecherche le code source des pages de manuel, pas leur forme rendue (comme affiché par man). Les tirets sont codés \-, vous devez donc rechercher cela:

man -s1 -Kw 'mark\-mo'

Oui, c'est assez obscur. La manpage de manuel mentionne, dans la description de l' -Koption, que

Notez que cela recherche les sources des pages de manuel, pas le texte rendu, et peut donc inclure des faux positifs en raison de choses comme les commentaires dans les fichiers source. La recherche du texte rendu serait beaucoup plus lente.

mais l'utiliser correctement implique de connaître la représentation source du texte que vous recherchez.


1
Obscur? Oui. C'est aussi un bug.
kubanczyk

@kubanczyk bien, cela correspond à la spécification, mais oui, je suis d'accord pour dire que la spécification est boguée ;-).
Stephen Kitt
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.