Repository navigation
Native globbing: character-individual backtick escaping of wildcard metacharacters is not respected #18038
Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest released version
- Search the existing issues.
- Refer to the FAQ.
- Refer to Differences between Windows PowerShell 5.1 and PowerShell.
See also (the inverse problem): #10683
Steps to reproduce
On Unix-like platforms, unquoted arguments that look like globbing (wildcard) patterns are automatically resolved to matching paths when calling external programs.
While single- and double-quoting can be used to suppress this behavior, using character-individual backtick escaping does not:
/bin/echo `*
Expected behavior
*Actual behavior
(list of file and subdirectory names in the current directory)Error details
No response
Environment data
PowerShell Core 7.3.0-preview.7 on Unix-like platforms.Visuals
No response
Reacted by Lemmingh
Activity
237dmitry commentedon Sep 6, 2022
Why do you expect this (
*) output?mklement0 commentedon Sep 6, 2022
237dmitry, why do you think that Bash syntax is in any way relevant here?
mklement0 commentedon Sep 6, 2022
In PowerShell terms: if
Write-Output `"is the same asWrite-Output '"', why isn't`*the same as'*'(as it indeed is withWrite-Output)?Granted, the escaping in
`*isn't strictly escaping for syntactic reasons, but if'*'serves to signal to the native globbing feature that it should not be applied, so should`*- unless there's a good reason for this discrepancy that I'm missing.237dmitry commentedon Sep 6, 2022
Because in bash
/bin/echo *outputs list of files. You escaped`*and/bin/echogets the clean*mklement0 commentedon Sep 6, 2022
And to bring it back to Bash syntax by analogy:
echo \*- which prints verbatim*- is the analog of/bin/echo `*in PowerShell.It does in PowerShell too, in an effort to emulate this behavior of POSIX-compatible shells called globbing (pathname expansion). That is, it is the shell that perform this expansion, before the target program is passed the results of this expansion.
This emulation is the implied premise of this issue, not its subject.
It doesn't, as shown in the initial post.
It is not
/bin/echothat performs the globbing, if that's your misconception.237dmitry commentedon Sep 6, 2022
/bin/echo receives parameter that already globbed. Isn't it true?
mklement0 commentedon Sep 6, 2022
Yes, if you pass
*. By contrast, if you quote the*as'*'or"*", PowerShell does not apply native globbing and/bin/echoreceives verbatim*(which it prints as-is). And, by PowerShell's quoting / escaping rules,`*should be equivalent to the quoted forms, but isn't.237dmitry commentedon Sep 6, 2022
I'm already confused with escaping.
mklement0 commentedon Sep 7, 2022
PSNativeCommandArgumentPassingis incidental to this discussion, because in effect it only relates to"chars. embedded in arguments.--%is virtually pointless on Unix-like platforms (and documented as such - for the backstory, see Clarify that the stop-parsing symbol is near-useless on Unix-like platforms (about_parsing) MicrosoftDocs/PowerShell-Docs#4963).Generally speaking, unquoted literal arguments are parsed as if they were enclosed in
"..."; that is,/bin/echo 1`n2is the same as/bin/echo "1`n2", meaning that escape sequence`nexpands to a literal newline (LF).Inside
"...",`-escaping characters that do not form an escape sequence isn't necessary, but is tolerated; e.g./bin/echo "`'"is the same as/bin/echo "'"and prints verbatim'.However, in an unquoted argument, characters that wouldn't require escaping if enclosed in
"..."do require escaping if they contain argument-mode metacharacters, such as',",&,|, ..., so that, for instance, you have to use/bin/echo `|to print|verbatim.From that perspective alone,
*does not require`-escaping, because*isn't an argument-mode metacharacter: leaving the native globbing feature out of the picture, all of the following output*verbatim:Write-Output *,Write-Output '*',Write-Output "*", andWrite-Output `*The fact that with respect to native globbing it makes a difference whether you use
'...'/"..."quoting (suppression of the feature) or not, already amounts to special-casing the usual syntax rules, and this special-casing is applied by PowerShell itself, during parameter binding (I don't know the details).My point is that this special-casing should also apply to
`*and`?, for consistency, i.e. these escaped forms should be treated the same as their quoted equivalents,'*'/"*"and'?'/"?", because the intent to treat*and?verbatim is expressed by all of these forms.I do realize that this complicates matters, because an argument such as
a`*b*would then have to treat the first*verbatim, while retaining the second one as a globbing metacharacter; expressed in Bash terms, it would have to be treated asa\*b*for globbing purposes.SteveL-MSFT commentedon Sep 12, 2022
cc James Truher (@JamesWTruher)
It seems reasonable that
`"` is a single literal double quote that*is a single literal asterisk./bin/echo "*"does do what you expect.JamesWTruher commentedon Sep 13, 2022
FWIW, this is behavior is in ps6 as well.
microsoft-github-policy-service commentedon Nov 15, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 15, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 15, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 22, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.