From 6053d313ce3abe876c7d05574effab438ce5e410 Mon Sep 17 00:00:00 2001 From: Zhiming Wang Date: Fri, 8 Jan 2016 11:21:54 -0800 Subject: Markdown source files: Use ... to end YAML metadata block Also add a newline after the metadata block. ... is easier on markdown-mode; if --- is used, the line immediately above it will be treated as a setext header and highlighted, which isn't so easy on the eyes. --- ...015-05-19-bash-the-special-slash-character-in-filename-expansion.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'source/blog/2015-05-19-bash-the-special-slash-character-in-filename-expansion.md') diff --git a/source/blog/2015-05-19-bash-the-special-slash-character-in-filename-expansion.md b/source/blog/2015-05-19-bash-the-special-slash-character-in-filename-expansion.md index 143a5f36..a3a789f9 100644 --- a/source/blog/2015-05-19-bash-the-special-slash-character-in-filename-expansion.md +++ b/source/blog/2015-05-19-bash-the-special-slash-character-in-filename-expansion.md @@ -2,7 +2,8 @@ title: "Bash: the special slash character in filename expansion" date: 2015-05-19T18:33:51-07:00 date_display: May 19, 2015 ---- +... + It is well-known and common sense that the slash character (`/`) serves a special role in Bash filename expansion. For instance, the asterisk `*` certainly won't match `/` or `.` when used in filename expansion; otherwise, a standalone `*` would match everything in the filesystem. However, it is less clear how a literal slash character[^expansion] is treated in extended glob patterns. Naively one would expect it to just match a literal slash, but the real situtation is more complicated than that. Consider the following examples: -- cgit v1.2.1