A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1564 ====================================================================== Reported By: calestyo Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1564 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Christoph Anton Mitterer Organization: User Reference: Section: 2.13 Pattern Matching Notation Page Number: 2351 Line Number: 76099 Final Accepted Text: ====================================================================== Date Submitted: 2022-02-23 01:54 UTC Last Modified: 2022-03-03 03:37 UTC ====================================================================== Summary: clariy on what (character/byte) strings pattern matching notation should work ======================================================================
---------------------------------------------------------------------- (0005729) calestyo (reporter) - 2022-03-03 03:37 https://www.austingroupbugs.net/view.php?id=1564#c5729 ---------------------------------------------------------------------- Well I guess the whole thing is also, why your point had been earlier, that '.' as sentinel would be enough, and any implementation that wouldn't carry on invalid encodings (i.e. bytes that do not form characters), would be buggy in that respect already. I guess on the one hand, Geoff is clearly right, when he says that any such behaviour (especially the complicated mappings that you explained above) are not expected to be carried out by an implementation (at least not from the current standard)... and as such '.' would in fact not be enough as the sentinel for command substitution with trailing newlines, but the LC_ALL=C would be required. OTOH... the '*' example above was intended to question whether there are really any implementations which would filter out filenames which contain bytes that do not form characters. I'd guess not. So one more reason, why I think that this should be clearly specified (which I've requested with this issue)... i.e. if there's consensus that it (pattern matching) operates on character strings only - clearly name this, declare operation on non-character strings unspecified (with respect to their results) and remove all current references that indicate that it would operate on bytes. Issue History Date Modified Username Field Change ====================================================================== 2022-02-23 01:54 calestyo New Issue 2022-02-23 01:54 calestyo Name => Christoph Anton Mitterer 2022-02-23 01:54 calestyo Section => 2.13 Pattern Matching Notation 2022-02-23 01:54 calestyo Page Number => 2351 2022-02-23 01:54 calestyo Line Number => 76099 2022-02-25 04:57 calestyo Note Added: 0005716 2022-02-25 20:54 mirabilos Note Added: 0005719 2022-03-03 03:37 calestyo Note Added: 0005729 ======================================================================
