Ygthkb

Is it possible to rotate the Isolines on a Surface Using `MeshFunction`?

Illustrator to chemdraw

How do I avoid the "chosen hero" feeling?

Critique vs nitpicking

How is this property called for mod?

Is there any way to make an Apex method parameter lazy?

If angels and devils are the same species, why would their mortal offspring appear physically different?

I have trouble understanding this fallacy: "If A, then B. Therefore if not-B, then not-A."

Why did Mr. Elliot have to decide whose boots were thickest in "Persuasion"?

Is there a file that always exists and a 'normal' user can't lstat it?

Sharepoint metadata URL

"Starve to death" Vs. "Starve to the point of death"

Renting a 2CV in France

hrule into tikz circle node

Can you determine if focus is sharp without diopter adjustment if your sight is imperfect?

Are all power cords made equal?

Why is Shelob considered evil?

Why is 'diphthong' not pronounced otherwise?

What to do with threats of blacklisting?

Equivalent of "illegal" for violating civil law

The No-Straight Maze

Where does documentation like business and software requirement spec docs fit in an agile project?

How to not let the Identify spell spoil everything?

Crack the bank account's password!

Is there any advantage in specifying './' in a for loop using a glob?

Why is printf better than echo?Handling names with leading dash in bash shellExecuting a shell command from PHP with shell_execConcatenate files in multiple matching subdirectoriesIs there any advantage on using ksh over zsh?Shell glob expansion after loop variable substitutionScrabble helper in bashfor loop glob mishapsGlob for matching everything but . andBash pattern to match directories whose names begin with a dot (period), by being “explicit”, instead of using “shopt -s dotglob”?When do we use single and when double square brackets […] vs [[…]]?Running multiple command against files matching a brace+glob pattern without repeating it

5

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?

bash shell wildcards

share|improve this question

edited 31 mins ago

terdon♦

131k32257436

asked 1 hour ago

Frédéric MahéFrédéric Mahé

263

New contributor

Frédéric Mahé is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  The ./ prefix is useful for Handling names with leading dash in bash shell
  
  – steeldriver
  1 hour ago
  

  
  
  
  

add a comment | 

5

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?

bash shell wildcards

share|improve this question

edited 31 mins ago

terdon♦

131k32257436

asked 1 hour ago

Frédéric MahéFrédéric Mahé

263

New contributor

Frédéric Mahé is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  The ./ prefix is useful for Handling names with leading dash in bash shell
  
  – steeldriver
  1 hour ago
  

  
  
  
  

add a comment | 

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?

bash shell wildcards

share|improve this question

edited 31 mins ago

terdon♦

131k32257436

asked 1 hour ago

Frédéric MahéFrédéric Mahé

263

New contributor

Frédéric Mahé is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

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

share|improve this question

edited 31 mins ago

terdon♦

131k32257436

asked 1 hour ago

Frédéric MahéFrédéric Mahé

263

New contributor

Frédéric Mahé is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

share|improve this question

edited 31 mins ago

terdon♦

131k32257436

asked 1 hour ago

Frédéric MahéFrédéric Mahé

263

New contributor

Frédéric Mahé is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

edited 31 mins ago

terdon♦

131k32257436

edited 31 mins ago

terdon♦

131k32257436

asked 1 hour ago

Frédéric MahéFrédéric Mahé

263

New contributor

Frédéric Mahé is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

asked 1 hour ago

Frédéric MahéFrédéric Mahé

263

1 Answer
1

active

oldest

votes

8

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

share|improve this answer

edited 58 mins ago

answered 1 hour ago

Jeff SchallerJeff Schaller

42.1k1156133

add a comment | 

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});

Frédéric Mahé is a new contributor. Be nice, and check out our Code of Conduct.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502884%2fis-there-any-advantage-in-specifying-in-a-for-loop-using-a-glob%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

8

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

share|improve this answer

edited 58 mins ago

answered 1 hour ago

Jeff SchallerJeff Schaller

42.1k1156133

add a comment | 

8

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

share|improve this answer

edited 58 mins ago

answered 1 hour ago

Jeff SchallerJeff Schaller

42.1k1156133

add a comment | 

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

share|improve this answer

edited 58 mins ago

answered 1 hour ago

Jeff SchallerJeff Schaller

42.1k1156133

# I want a file named `-n`

$ touch -n

touch: invalid option -- 'n'

Try 'touch --help' for more information.

$ touch -- -n

### ok

$ touch ./-n

### ok

for file in *n

do

  echo "$file"

done

for file in ./*n

do

  echo "$file"

done

./-n

for file in *n

do

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

done

mv -- -n backup/-n

share|improve this answer

edited 58 mins ago

answered 1 hour ago

Jeff SchallerJeff Schaller

42.1k1156133

answered 1 hour ago

Jeff SchallerJeff Schaller

42.1k1156133

answered 1 hour ago

Jeff SchallerJeff Schaller

42.1k1156133