The asterisk character (*) is treated differently depending on the body section and escaping does not seem to help

[mstaessen]

The * character does not end up in the output when appearing mid-text. Escaping does not seem to resolve it. In a "note"-section though, the asterisks seems to appear just fine in the output.

Evidence:

docs/xml/System.IO/Directory.xml

Line 781 in 81117b1

Characters other than the wildcard are literal characters. For example, the `searchPattern` string "*t" searches for all names in `path` ending with the letter "t". The `searchPattern` string "s\*" searches for all names in `path` beginning with the letter "s".

is translated into

Characters other than the wildcard are literal characters. For example, the searchPattern string "t" searches for all names in path ending with the letter "t". The searchPattern string "s\" searches for all names in path beginning with the letter "s".

But in the note below:

docs/xml/System.IO/Directory.xml

Lines 783 to 789 in 81117b1

	> [!NOTE]
	> When you use the asterisk wildcard character in a `searchPattern` such as "*.txt", the number of characters in the specified extension affects the search as follows:
	>
	> - If the specified extension is exactly three characters long, the method returns files with extensions that begin with the specified extension. For example, "*.xls" returns both "book.xls" and "book.xlsx".
	> - In all other cases, the method returns files that exactly match the specified extension. For example, "*.ai" returns "file.ai" but not "file.aif".
	>
	> When you use the question mark wildcard character, this method returns only files that match the specified file extension. For example, given two files, "file1.txt" and "file1.txtother", in a directory, a search pattern of "file?.txt" returns just the first file, whereas a search pattern of "file*.txt" returns both files.

it is translated correctly

When you use the asterisk wildcard character in a searchPattern such as "*.txt", the number of characters in the specified extension affects the search as follows:

[mairaw]

Hi @mstaessen, thanks for reporting this issue. It seems an issue with our migration logic that didn't escape those asterisks when the content was converted to Markdown. But why do you say that escaping them doesn't resolve the issue? I'll create a test PR to see the results.

/cc @wh-alice @yishengjin1413

[mairaw]

My test PR #3259 indicates that escaping the asterisks would fix the issue:

[mstaessen]

The reason I suspected that escaping was not working came from comparing source code of the docs and current state of the currently published doc page.

• "*t" => "t"
• "s\*" => "s\"
• in the note: "*.txt" => "*.txt"

That did not seem consistent. However your version seems to produce the correct result.

[mairaw]

Thanks @mstaessen. Maybe the build tool behaves differently when it sees asterisks on notes. Not sure.

I've opened an internal bug to track this. Maybe we can get a data fix applied. #1088347

[mairaw]

I was following up on this issue and apparently the engineering team fixed this a long time ago:
dotnet/docfx#2106

Please let us know if you encounter more issues like this.