Repository navigation
Is it worth writing up an RFC on adding new escape characters? #2751
Description
Activity
I suppose it might break some script obfuscation techniques:
`G`et`-`C`h`i`l`d`It`e`m
But it does seem like a valuable addition. We don't need the RFC just yet, but I tagged this for committee review.
I'm also okay with
`eand`uwithout much discussion. Not sure about`_, but we'll discuss it in our next committee meeting.Not sure about `_
Me neither. Just throwing it out because I do think line continuation in PowerShell is one of its weaker areas. At one time, I was suggesting just using
_until I realized that duh,_is a valid function name. :-)Maybe the line continuation problem is worthy of an issue of it's own?
Reacted by Keith Hill and Michael Klement@PowerShell/powershell-committee reviewed this and would be fine support
e andu without the need for a RFC. The risk as a breaking change is minimal and the value is apparent. For line continuation, we suggest opening a separate issue to discuss that.Reacted by Keith Hill- added a commit that references this issue
on Dec 22, 2016 I'm against the
`u<hex>+without an end of hex sequence delimiter syntax because programming languages like that prone to mistakes when the escape code is followed by text that just happens to be a hex character. My preferred solution is something that resembles Perl's bracketed hex escapes like:Though I would modify the above proposal so that U+10000 to U+10FFFF produce
UnicodeCodePointobjects instead of strings:And
[UnicodeCodePoint]to[string]conversion produces a UTF-16 encoded string.29 remaining items
Thanks, Keith Hill (@rkeithhill), all good stuff; yes, I was only talking about argument-mode (which is what "about_Parsing" calls it, at least these days), and I've edited my post to make that clearer; I've also incorporated your other suggestions, except for the background on the advanced coercion techniques (I just point to your comment).
Reacted by Keith HillHere's the latest version of parser error messages for Unicode escape sequence parsing:
Reacted by Troy Campbell and Joey AielloThese error messages are very clear and helpful.
If providing that level of specificity is the consensus, then I think they're great.
I wonder if the specificity is needed, however, given that someone even attempting to use this feature can be assumed to have a reasonable level of technical competence, which is why I suggested a single catch-all message earlier.
(But I'm probably venturing into bike-shedding territory here.)
Thanks! RE too specific, I remember a time when the PowerShell error messages were less than helpful. Over time I think they've gotten better in terms of not only telling you what is wrong but also, when possible, suggesting a mitigation.
Lately, I've been impressed with how well
Gitdoes this e.g.:PS> git statuz git: 'statuz' is not a git command. See 'git --help'. Did you mean this? statusSo while I agree we should keep the error messages as short as possible (otherwise TL;DR) I do think we should provide some help in terms of suggesting a fix.
Reacted by Michael Klement and Joey AielloKeith Hill (@rkeithhill) the PowerShell Team has discussed enhancing the current suggestion system to be more useful for missing or typos for cmdlets or parameters. I didn't find an existing issue, so I opened #3988
Reacted by Keith Hill and Michael KlementThe @PowerShell/powershell-committee reviewed this and we agreed to we do not want the fixed width syntax without braces - we only want the braced syntax.
Arguments against the fixed width syntax:
- It's harder to read
- It might be similar to C#, but it's not exactly the same, so cut and paste doesn't work anyway
- No possible ambiguity, e.g.
`uabcd00vs.`u{abcd}00
Reacted by Michael Klement, Travis Plunk, Ilya and Keith HillWorks for me. I'll try to get the updates finalized tomorrow night. Just got home - spent all day of driving from Salt Lake City back to Colorado.
Reacted by IlyaI rebased and squashed down to a single commit the original support for both forms. Then I pushed a commit with support for the fixed width form removed.
Jason Shirk (@lzybkr) What's the reason for the braced syntax being
`u{abcd}instead of`{abcd}?Derp McDerp (@DerpMcDerp) - the @PowerShell/powershell-committee did not discuss dropping the
u, so I suppose it seemed obvious we needed something.I see some advantages to keeping the
u- it's reasonably descriptive, more similar to other languages, and it's a form of future proofing - it might be desirable to use that same syntax or very similar syntax for some future feature (I don't have anything specific in mind though.)The only advantage I see to dropping the
u- it's one less character, not much of an advantage.Reacted by Michael Klement and Joel BennettBoth
`eand`u{xxxxxx}have been implemented, merged and documented.
Given the inherent breaking changes between Windows PowerShell 5.x and PowerShell Core, especially when running on Linux and macOS, can we consider adding a few new escape characters?
With the addition of ANSI esc sequences to the Windows console host, and existence of the same on terminals in Linux and macOS, I would like to have the following esc chars added:
OK, so that last one is a stretch but there seems to be a few problems with line continuation in PowerShell - hard to see / trailing whitespace. Maybe PowerShell Core presents an opportunity to tweak line continuation a little??
If the PowerShell Committee is willing to entertain this idea, is it worth writing up as an RFC?