Y a-t-il un avantage à spécifier './' dans une boucle for en utilisant un glob?

J'avais l'impression qu'il pourrait être plus sûr à utiliser ./*.fastqlors de la recherche de fichiers se terminant par .fastq. Par exemple, ./empêcherait la capture du fichier .fastq. C'est évidemment faux, comme le montre l'exemple ci-dessous:

TMP_DIR=$(mktemp --directory)
mkdir -p ${TMP_DIR}
(cd ${TMP_DIR}
 touch {a,b,c,}.fastq
 ls -a
 echo ""

 echo "# match all:"
 for f in *.fastq ; do
     echo "${f}"
 done
 echo ""

 echo "# with ./:"
 for f in ./*.fastq ; do
     echo "${f}"
 done
)
rm -rf ${TMP_DIR}

.
..
a.fastq
b.fastq
c.fastq
.fastq

# match all:
a.fastq
b.fastq
c.fastq

# with ./:
./a.fastq
./b.fastq
./c.fastq

Ni , *.fastqni ./*.fastqcorrespondre au fichier .fastq. Je me demande donc maintenant, est-il utile d'utiliser ./*.fastqici, ou ./*en général?

C'est initialement un comportement générique surprenant, car la description du *caractère générique dit:

Correspond à n'importe quelle chaîne, y compris la chaîne nulle.

... jusqu'à ce que vous vous rendiez compte que cette période est légèrement spéciale lorsqu'il s'agit du premier caractère d'un nom de fichier. Le texte d'introduction le 3.5.8 Filename Expansiondit:

Lorsqu'un modèle est utilisé pour l'expansion du nom de fichier, le caractère '.' au début d'un nom de fichier ou immédiatement après une barre oblique doit correspondre explicitement, sauf si l'option shell dotglob est définie.

Le "modèle d'utilisation" consistant à préfixer les caractères génériques avec ./est utile pour gérer les noms avec un tiret en tête dans le shell bash , comme l'a expliqué Steeldriver. Cela n'a aucun effet sur l'expansion du caractère générique / nom de fichier, mais rend plus sûr / plus facile de gérer les noms de fichiers lorsque vous vous y référez, s'ils commencent par des caractères que ces programmes pourraient mal interpréter comme des options. Par exemple:

# I want a file named `-n`
$ touch -n
touch: invalid option -- 'n'
Try 'touch --help' for more information.
$ touch -- -n
### ok
$ touch ./-n
### ok

... et maintenant que j'ai un fichier nommé -n, si j'arrive en boucle sur elle avec un caractère générique:

for file in *n
do
  echo "$file"
done

... je n'ai pas de sortie!

Mais si je préfixe le caractère générique avec ./,

for file in ./*n
do
  echo "$file"
done
./-n

... Je vois le nom du fichier.

Ceci est un exemple simple à des fins de démonstration; voir aussi Pourquoi printf est meilleur qu'echo? pour cette raison et d'autres. D'autres utilitaires seront déclenchés par d'autres options, il est donc préférable de présenter les noms de fichiers aux utilitaires de la manière la plus sûre possible. Si vous ne préfixez pas le caractère générique pour "échapper" les noms de fichiers, vous devrez "protéger" vos utilitaires par d'autres moyens; l'une des plus courantes consiste à signaler la fin des options avec --, par exemple:

for file in *n
do
  mv -- "$file" backup/"$file"
done

... qui passera le -nnom de fichier en toute sécurité mv(comme vu ci-dessous set -x):

mv -- -n backup/-n