A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1551 ====================================================================== Reported By: calestyo Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1551 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Christoph Anton Mitterer Organization: User Reference: Section: Utilities, sed Page Number: 3132, ff. (in the draft) Line Number: see below Final Accepted Text: ====================================================================== Date Submitted: 2022-01-14 05:39 UTC Last Modified: 2022-02-01 20:12 UTC ====================================================================== Summary: sed: ambiguities in the how BREs/EREs are parsed/interpreted between delimiters (especially when these are special characters) ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001550 clarifications/ambiguities in the descr... ======================================================================
---------------------------------------------------------------------- (0005648) calestyo (reporter) - 2022-02-01 20:12 https://www.austingroupbugs.net/view.php?id=1551#c5648 ---------------------------------------------------------------------- Just something more for the records (in case someone tries to reproduce the above with current versions): Another commit in BusyBox (https://git.busybox.net/busybox/commit/?id=f12fb1e4092900f26f7f8c71cde44b1cd7d26439) seems to have "fully" aligned it's behaviour with that of GNU set (well "fully" in the sense of the test cases given above in https://www.austingroupbugs.net/view.php?id=1551#c5612 ). In especially, BusyBox sed now also seems to consider the 2nd '.' in: s.\..X. as a special character and no longer as literal one, i.e. equivalent to: s/./X/ (haven't teste other special characters) So with respect to the most recent version, the table would look the same for BusyBox sed and GNU sed. The main points of this issue remain however, i.e. that POSIX is ambiguous with respect to them. Issue History Date Modified Username Field Change ====================================================================== 2022-01-14 05:39 calestyo New Issue 2022-01-14 05:39 calestyo Name => Christoph Anton Mitterer 2022-01-14 05:39 calestyo Section => Utilities, sed 2022-01-14 05:39 calestyo Page Number => 3132, ff. (in the draft) 2022-01-14 05:39 calestyo Line Number => see below 2022-01-14 06:34 Don Cragun Relationship added related to 0001550 2022-01-14 06:48 Don Cragun Project 1003.1(2016/18)/Issue7+TC2 => Issue 8 drafts 2022-01-14 06:51 Don Cragun Note Added: 0005602 2022-01-14 06:51 Don Cragun version => Draft 2.1 2022-01-14 15:52 calestyo Note Added: 0005607 2022-01-14 20:36 calestyo Note Added: 0005610 2022-01-14 21:40 calestyo Note Added: 0005611 2022-01-14 21:48 calestyo Note Added: 0005612 2022-01-14 22:07 calestyo Note Edited: 0005612 2022-01-14 22:08 calestyo Note Edited: 0005612 2022-01-14 22:09 calestyo Note Edited: 0005612 2022-01-14 22:15 calestyo File Added: summary-of-literal-behaviour-gnu-vs-busybox.txt 2022-01-14 22:17 calestyo Note Added: 0005613 2022-01-18 21:18 calestyo Note Added: 0005627 2022-01-24 14:52 calestyo Note Added: 0005634 2022-01-24 15:48 calestyo Note Edited: 0005634 2022-02-01 20:12 calestyo Note Added: 0005648 ======================================================================
