Discussion :

[nthl.roche]

Bonjour
Je ne saisis pas les subtilités de la commande ls.

Qu'est ce qui fait que ls *.*

n'affiche pas les fichiers cachés en .xxxx

merci d'avance de vos éclaircissements.

[N_BaH]

Bonjour,

parce que c'est le shell qui réalise le développement.
en bash, tu peux aussi activer l'option dotglob avec shopt.

[frp31]

bon là... j'ai pas le choix ... RTFM (pour toute question sur une commande "basique" du système c'est le reflexe à avoir pour cette fois ... on dira que tu savais pas...

ls -a

[N_BaH]

en bash, tu peux aussi activer l'option dotglob avec shopt.

je me reprend pour préciser qu'alors ls est inutile !

[nthl.roche]

En fait, si, j'ai bien commencé par lire le manuel.
Mais c'est pas toujours évident de comprendre ce qu'il dit. Il y a des moments où on le comprend...que lorsqu'on a déjà compris :-)

Je précise ce qui me chagrine et dont je ne comprends pas la logique (et la réponse est sûrement que je ne regarde pas au bon endroit sur le man !)

Dans un répertoire, j'ai les fichiers f, fa, fb, f.c, .ghe

ls f* trouve f et trouve f.c
j'en déduisais que * peut désigner une chaîne vide ou une chaîne commençant par le symbole .

mais ceci semble être contredit par
ls *.* ou par ls * qui ne retournent pas le fichier .ghe

A quel niveau mon raisonnement est à corriger ?

merci

[N_BaH]

la norme POSIX définit ce comportement :

si un nom de fichier commence par un point ('.'), le point doit être utilisé en tant que premier caractère du motif[...]
le point ne pourra être remplacé par un astérisque, un point d'interrogation, ou une plage de non-correspondance[...]

cf. Patterns Used for Filename Expansion

et, je le redis, ce n'est pas le fait de ls, mais du shell.

[chrtophe]

ls *.*, c'est le réflexe Windows ...
Je fais pas mal de linux en ce moment, et je me retrouve à taper : ls dans la ligne de commande windows

[nthl.roche]

la norme POSIX définit ce comportement : cf. Patterns Used for Filename Expansion

et, je le redis, ce n'est pas le fait de ls, mais du shell.

merci, voilà qui m'éclaire.

Je voyais un contre-exemple à mon interprétation là où il fallait plutôt voir une exception utile pour les fichiers .xxx

[Obsidian]

J'en profite pour préciser que « *.* » est un motif typiquement DOS (et Windows par extension), parce que DOS utilisait le format 8.3, dans laquelle l'extension du nom de fichier était un champ à part entière. Si l'on saisit cela sous Unix, on n'obtiendra que les fichiers dont le nom contient au moins un point (et pas au début, bien sûr).

[Flodelarab]

Bonjour,

pardon, mais j'ai l'impression que personne ne répond à la question.

Qu'est ce qui fait que ls *.*

n'affiche pas les fichiers cachés en .xxxx

La réponse est dans la question: car ils sont cachés

A quel niveau mon raisonnement est à corriger ?

L'erreur est que la convention est de dire que les fichiers qui commencent par un point son cachés. Sous windows, c'est une propriété supplémentaire du fichier; sous linux, c'est un format de nom qui provoque le caractère caché.

Un problème de développement de commande shell qui n'arrive pas si tu utilises "find" plutôt que "ls":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ find -maxdepth 1 -name '.*'
.
./.vide.txt

[Obsidian]

La réponse est dans la question: car ils sont cachés

Oui mais justement, ce n'est pas sa question. Il sait très bien qu'il s'agit de fichiers cachés. Mais comme on peut explicitement les sélectionner avec « .* » , il se demandait pourquoi le motif « *.* » ne les sélectionne pas également, et d'une manière générale, qu'est-ce qui fait que « * » ne les sélectionne pas comme des fichiers ordinaires, fussent-ils cachés. Ça a du sens parce qu'on aurait pu penser qu'un « ls » seul, sans motif explicite, aurait choisi de faire lui-même cette distinction.

En ce sens, la réponse de N_baH est la meilleure puisqu'elle met en évidence que le comportement à adopter a été normalisé et que cette norme décrit en détail l'attitude à adopter.

La justification est que ces fichiers étant cachés, l'utilisateur peut en ignorer l'existence (ils sont même faits pour) et que dans ce cas, les fichiers cachés ne doivent pas être impliqués à son insu dans un traitement ordinaire.

Un problème de développement de commande shell qui n'arrive pas si tu utilises "find" plutôt que "ls":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ find -maxdepth 1 -name '.*'

C'est le mauvais exemple : tu as écrit « .* » dans ton motif de recherche. Ce qui donnera le même résultat qu'un « ls .* » ou même un « echo .* ».