Is there any advantage in specifying './' in a for loop using a glob?Why is printf better than echo?Handling...
Lightning Data Table inline edit
Can my friend and I spend the summer in Canada (6 weeks) at 16 years old without an adult?
Coworker asking me to not bring cakes due to self control issue. What should I do?
The No-Straight Maze
Why is it that Bernie Sanders is always called a "socialist"?
Why didn't Tom Riddle take the presence of Fawkes and the Sorting Hat as more of a threat?
Switch case implementation in Java for an integer pair combination
Sitecore 9.1 Installation - Skip to particular step
Website seeing my Facebook data?
How is this property called for mod?
Taking headphones when quitting job
Translation needed for 130 years old church document
Why do neural networks need so many examples to perform?
Why did Luke use his left hand to shoot?
How to completely remove a package in Ubuntu (like it never existed)
Subsurf on a crown. How can I smooth some edges and keep others sharp?
Why is 'diphthong' pronounced the way it is?
Need help with a circuit diagram where the motor does not seem to have any connection to ground. Error with diagram? Or am i missing something?
Concatenating two int[]
Charging phone battery with a lower voltage, coming from a bike charger?
What can I do to encourage my players to use their consumables?
Renting a 2CV in France
Are the positive and negative planes inner or outer planes in the Great Wheel cosmology model?
hrule into tikz circle node
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
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
edited 5 hours ago
terdon♦
131k32258436
asked 6 hours ago
Frédéric MahéFrédéric Mahé
413
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.
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
edited 5 hours ago
terdon♦
131k32258436
asked 6 hours ago
Frédéric MahéFrédéric Mahé
413
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.
The usual point to./*is that it ensures that names that start with-aren't treated as options.
– Charles Duffy
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
edited 5 hours ago
terdon♦
131k32258436
asked 6 hours ago
Frédéric MahéFrédéric Mahé
413
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.
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
bash shell wildcards
edited 5 hours ago
terdon♦
131k32258436
asked 6 hours ago
Frédéric MahéFrédéric Mahé
413
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 5 hours ago
terdon♦
131k32258436
asked 6 hours ago
Frédéric MahéFrédéric Mahé
413
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 5 hours ago
terdon♦
131k32258436
edited 5 hours ago
terdon♦
131k32258436
edited 5 hours ago
terdon♦
131k32258436
131k32258436
asked 6 hours ago
Frédéric MahéFrédéric Mahé
413
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 6 hours ago
Frédéric MahéFrédéric Mahé
413
asked 6 hours ago
Frédéric MahéFrédéric Mahé
413
413
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.
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.
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.
The usual point to./*is that it ensures that names that start with-aren't treated as options.
– Charles Duffy
1 hour ago
add a comment |
The usual point to./*is that it ensures that names that start with-aren't treated as options.
– Charles Duffy
1 hour ago
The usual point to
./* is that it ensures that names that start with - aren't treated as options.– Charles Duffy
1 hour ago
The usual point to
./* is that it ensures that names that start with - aren't treated as options.– Charles Duffy
1 hour ago
add a comment |
1 Answer
1
active
oldest
votes
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
answered 6 hours ago
Jeff SchallerJeff Schaller
42.2k1156134
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.
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
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
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
answered 6 hours ago
Jeff SchallerJeff Schaller
42.2k1156134
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
answered 6 hours ago
Jeff SchallerJeff Schaller
42.2k1156134
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
answered 6 hours ago
Jeff SchallerJeff Schaller
42.2k1156134
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
answered 6 hours ago
Jeff SchallerJeff Schaller
42.2k1156134
edited 6 hours ago
answered 6 hours ago
Jeff SchallerJeff Schaller
42.2k1156134
answered 6 hours ago
Jeff SchallerJeff Schaller
42.2k1156134
answered 6 hours ago
Jeff SchallerJeff Schaller
42.2k1156134
42.2k1156134
add a comment |
add a comment |
Frédéric Mahé is a new contributor. Be nice, and check out our Code of Conduct.
Frédéric Mahé is a new contributor. Be nice, and check out our Code of Conduct.
Frédéric Mahé is a new contributor. Be nice, and check out our Code of Conduct.
Frédéric Mahé is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
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
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The usual point to
./*is that it ensures that names that start with-aren't treated as options.– Charles Duffy
1 hour ago