Cfrgtkky

I was under the impression it could be safer to use ./*.fastq when searching for files ending with .fastq. For example, ./ would prevent capturing the file .fastq. This is obviously wrong, as shown in the example below:

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

Neither *.fastq nor ./*.fastq match the file .fastq. So I wonder now, is there any point using ./*.fastq here, or ./* in general?

That's initially surprising wildcard behavior, since the description for the * wildcard character says:

Matches any string, including the null string.

... until you realize that period is slightly special when it's the first character of a filename. The introductory text in 3.5.8 Filename Expansion says it:

When a pattern is used for filename expansion, the character ‘.’ at the start of a filename or immediately following a slash must be matched explicitly, unless the shell option dotglob is set.

The "usage pattern" of prefixing wildcards with ./ is useful for Handling names with leading dash in bash shell, as steeldriver commented. It has no effect on the wildcard / filename expansion, but makes it safer/easier to handle the filenames when you refer to them, if they begin with characters that those programs might misinterpret as options. For example:

# I want a file named `-n`

$ touch -n

touch: invalid option -- 'n'

Try 'touch --help' for more information.

$ touch -- -n

### ok

$ touch ./-n

### ok

... and now that I have a file named -n, if I happen to loop over it with a wildcard:

for file in *n

do

  echo "$file"

done

... I get no output!

But if I prefix the wildcard with ./,

for file in ./*n

do

  echo "$file"

done

./-n

... I see the filename.

This is a simple example for demonstration purposes; see also Why is printf better than echo? for this reason and others. Other utilities will get tripped up by other options, so it's better to present the filenames to the utilities as safely as possible. If you don't prefix the wildcard to "escape" filenames, you'd have to "protect" your utilities in other ways; one common one is to signal the end of options with --, for example:

for file in *n

do

  mv -- "$file" backup/"$file"

done

... which will safely pass the -n filename to mv (as seen under set -x):

mv -- -n backup/-n