[Issue 8 drafts 0001550]: clarifications/ambiguities in the description of context addresses and their delimiters for sed
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1550 == Reported By:calestyo Assigned To: == Project:Issue 8 drafts Issue ID: 1550 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial 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:32 UTC Last Modified: 2022-03-26 00:08 UTC == Summary:clarifications/ambiguities in the description of context addresses and their delimiters for sed == Relationships ID Summary -- related to 0001551 sed: ambiguities in the how BREs/EREs a... == -- (0005767) calestyo (reporter) - 2022-03-26 00:08 https://austingroupbugs.net/view.php?id=1550#c5767 -- Re: https://austingroupbugs.net/view.php?id=1550#c5756 your (1): agreed your (2a): agreed, and you're right about the issue with "shall be identical" your (2b): I wouldn't agree here because... In "where c is any character other than or ", the idea behind exclusion of and is, AFAIU, rather a *general* exclusion, that is in the sense of "neither of these two characters can ever be delimiters". I wouldn't have understood that sentence in the sense of "any c except and have to use the \cREc form" but rather as "any c have to use the \cREc form and or cannot be used at all". I agree, that the wording of the sentence actually describes the former,... but I think the spirit that it means is rather the latter (in which case it would be open whether c is any character or any character except (forward) ). If not, the question would be open as to how or would be encoded as delimiters. your (2c): Well I agree it's "semi-clear" (especially because of the given example)... still adding a short clarification as in: "If any but the first occurrence of the character designated by c appears following a " shouldn't cause much harm and make it really definite. I personally would recommend against dealing with that in https://austingroupbugs.net/view.php?id=1551 . While they touch the same section, this one here is merely a subtle cosmetic change, which doesn't really affect the deeper semantics as most of #1551 does. Issue History Date ModifiedUsername FieldChange == 2022-01-14 05:32 calestyo New Issue 2022-01-14 05:32 calestyo Name => Christoph Anton Mitterer 2022-01-14 05:32 calestyo Section => Utilities, sed 2022-01-14 05:32 calestyo Page Number => 3132, ff. (in the draft) 2022-01-14 05:32 calestyo Line Number => see below 2022-01-14 05:40 calestyo Note Added: 0005601 2022-01-14 06:34 Don Cragun Relationship added related to 0001551 2022-01-14 06:52 Don Cragun Project 1003.1(2016/18)/Issue7+TC2 => Issue 8 drafts 2022-01-14 06:54 Don Cragun Note Added: 0005603 2022-01-14 06:54 Don Cragun version => Draft 2.1 2022-03-18 11:15 geoffclare Note Added: 0005756 2022-03-18 11:15 geoffclare Note Edited: 0005756 2022-03-25 16:18 geoffclare Note Added: 0005761 2022-03-25 16:22 geoffclare Note Edited: 0005761 2022-03-26 00:08 calestyo Note Added: 0005767 ==
[1003.1(2016/18)/Issue7+TC2 0001546]: BREs: reserve \? \+ and \|
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1546 == Reported By:calestyo Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1546 Category: Base Definitions and Headers Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: Christoph Anton Mitterer Organization: User Reference: Section:9.3 Basic Regular Expressions Page Number:N/A Line Number:N/A Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1546#c5755 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2022-01-08 03:48 UTC Last Modified: 2022-03-25 22:57 UTC == Summary:BREs: reserve \? \+ and \| == Relationships ID Summary -- has duplicate 773 Summary: Add \+, \?, and \| to Basic Re... == -- (0005766) calestyo (reporter) - 2022-03-25 22:57 https://austingroupbugs.net/view.php?id=1546#c5766 -- May I also add the following: a) Not sure whether https://austingroupbugs.net/view.php?id=773 is really to be considered a duplicate of this. This issue was merely about preventing "\?", "\+", and "\|" to get any completely other meaning than that from ERE. While #773 rather asked for defining them to ONLY have the special meaning (not either special or literal - as the above draft resolves it). b) While the draft in 5755 prevents (a) from happening (e.g. \+ couldn't suddenly mean something completely different) I'm still a bit sceptical on whether that's the best way to go. It merely records the current situation of implementations - but with that also statically codifies the two different interpretations (literal ? + \ vs. special). So we'd get non-portable behaviour even deeper into the standard than it was before, where from the standard's PoV any use of "\?", "\+", and "\|" was simply undefined. I realise that it would be problematic to follow the spirit of #773 and define "\?", "\+", and "\|" to have ONLY the special meaning, when there are implementations (you've mentioned Solaris, HP-UX, AIX) who behave already different. OTOH, if an implementation assigns it's own semantics to undefined parts of a standard, it must always assume that sooner or later it could get compatibility issues. The question arises: Do Solaris/HP-UX/AIX really give "\?", "\+", and "\|" the literal meaning on purpose (or is it perhaps just an undocumented side-effect of the implementation),... is it even used there,... would they be willing to adapt? Depending on the answers, it could make sense to follow a different path. And even if that doesn't seem feasible right now, one could perhaps add something to "future directions", indicating that a future standard might require "\?", "\+", and "\|" to have ONLY the special meaning. This would encourage any new implementations to follow that. And as long as any implementations exist (possibly even forever),... the "future direction" would never need to become true, so no one should be sad. Issue History Date ModifiedUsername FieldChange == 2022-01-08 03:48 calestyo New Issue 2022-01-08 03:48 calestyo Name => Christoph Anton Mitterer 2022-01-08 03:48 calestyo Section => 9.3 Basic Regular Expressions 2022-01-08 03:48 calestyo Page Number => N/A 2022-01-08 03:48 calestyo Line Number => N/A 2022-01-28 11:21 mirabilos Note Added: 0005636 2022-01-28 23:10 calestyo Note Added: 0005639 2022-03-03 06:56 Don Cragun Note Added: 0005731 2022-03-03 07:03 Don Cragun Note Edited: 0005731 2022-03-10 17:09 geoffclare Note Added: 0005738
[1003.1(2016/18)/Issue7+TC2 0001546]: BREs: reserve \? \+ and \|
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1546
==
Reported By:calestyo
Assigned To:
==
Project:1003.1(2016/18)/Issue7+TC2
Issue ID: 1546
Category: Base Definitions and Headers
Type: Enhancement Request
Severity: Editorial
Priority: normal
Status: Resolved
Name: Christoph Anton Mitterer
Organization:
User Reference:
Section:9.3 Basic Regular Expressions
Page Number:N/A
Line Number:N/A
Interp Status: ---
Final Accepted Text:https://austingroupbugs.net/view.php?id=1546#c5755
Resolution: Accepted As Marked
Fixed in Version:
==
Date Submitted: 2022-01-08 03:48 UTC
Last Modified: 2022-03-25 22:41 UTC
==
Summary:BREs: reserve \? \+ and \|
==
Relationships ID Summary
--
has duplicate 773 Summary: Add \+, \?, and \| to Basic Re...
==
--
(0005765) calestyo (reporter) - 2022-03-25 22:41
https://austingroupbugs.net/view.php?id=1546#c5765
--
off-topic: Did Austin Group ever consider to handle such changes via git?
It would make following/reviewing changes *so* much easier, than having to
build up the final picture by fiddling around with pages, line numbers and
what's ought to be changed to what.
Regarding https://austingroupbugs.net/view.php?id=1546#c5755
Some comments from my side:
1) I'm still a bit unhappy with the definition of "escape sequence".
It does not directly include the information that the escape character \
itself must not be quoted by another '\'.
Even if you would have 2.2.1 Escape Character (Backslash) in mind:
- this seems more or less defined for chapter 2 - not generally
- and even if one assumes it generally, than 2.2.1 would say "A
that is not quoted" - where quoting however means *any* shell quotation
style (\… '…' "…" and in the future $'…') - however for REs, only
the \… style would apply.
2) Perhaps it would also be better to write instead of:
"An escape sequence, when not in a bracket expression, is defined as the
escape character ('\\') followed by any single character."
something like the following:
"An escape sequence is defined as the escape character ('\\')
followed by any single character, not within a bracket expression."
The problem with "An escape sequence, when not in a bracket expression" is
IMO that this makes no sense, as there are never escape sequences within a
bracket expression - except perhaps for the open question (I've raised in
some other ticket) of whether an an escaped sed delimiter (like in
's.a[\.]b.X.') inside a bracket expression is the undelimitered special
character (special '.' in the example), the undelimitered literal character
(literal '.' in the example) or the literal two characters ('\' and '.' in
the example).
Apart from that,... the draft in 5755 looks good, though I haven't checked
the grammar in detail.
Issue History
Date ModifiedUsername FieldChange
==
2022-01-08 03:48 calestyo New Issue
2022-01-08 03:48 calestyo Name => Christoph Anton
Mitterer
2022-01-08 03:48 calestyo Section => 9.3 Basic Regular
Expressions
2022-01-08 03:48 calestyo Page Number => N/A
2022-01-08 03:48 calestyo Line Number => N/A
2022-01-28 11:21 mirabilos Note Added: 0005636
2022-01-28 23:10 calestyo Note Added: 0005639
2022-03-03 06:56 Don Cragun Note Added: 0005731
2022-03-03 07:03 Don Cragun Note Edited: 0005731
2022-03-10 17:09 geoffclare Note Added: 0005738
2022-03-10 17:09 geoffclare Interp Status => ---
2022-03-10 17:09 geoffclare Final Accepted Text =>
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Fri, 25 Mar 2022 09:22:55 + From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20220325092255.GA26387@localhost> | [I have quoted kre's mail in full here, Thanks for that, that was the best way to compensate for my forgetfulness I believe. | They are different (without -e). Here is what strace shows for | the two cases: OK, that's behaving the way I thought it might (my first algorithm approximately) and your tests also show that they regard only ENOENT as "not existing" (answers the question that was in the comment). | It doesn't read any directories, it just uses lstat() for existence | checks. That, of course, is the easy way. Though that doesn't actually check for existence, but for (not sure of the appropriate word) the ability to manipulate the file. Not quite the same thing. | However, I don't see the need for the standard to be specific about | this, since there are many other places where it talks about existence | of files but doesn't specify how the existence check is done. Most of the other places it doesn't matter, here it does. The file in the d_nox case clearly does exist. But not only does the corelinks code not discover that, it also doesn't (without -e) treat the final component as not existing, and use that algorithm. That is, if you used their realpath on a no-x directory, naming a file that doesn't exist in the directory, their code would not treat that the same as the same file not existing in a directory with 'x' permission. I think we need better terminology than "doesn't exist" here, it might be better to actually refer to getting an ENOENT from the realpath() call on the file, rather than it not existing. That is what it appears is actually implemented. | So perhaps the first bullet should be modified something like this: At this point I will skip replying to this message, as you replaced all of this in your subsequent message, so I will go directly to that one. austin-group-l@opengroup.org (Actually Geoff Clare) said 5 hours later: | I obviously didn't pay enough attention to this result, as the wording | change I proposed doesn't cover it. Or, rather, with hindsight, not go to it (yet). I originally had a whole new way of writing the relevant text (roughly) included here, but before I send it I want to think more on exactly what is required, and how it can be specified. If I'm right, it should be all much simpler than it seems. I think to test this, I need to do an implementation of the coreutils without -e algorithm, and make sure that my results are consistent with its. If we're going to consider including this in NetBSD, I will need to do that anyway, so I may as well just do it. kre
Minutes of the 24th March 2022 Teleconference
All
Enclosed are the minutes of yesterdays’ meeting
regards
Andrew
Minutes of the 24th March 2022 TeleconferenceAustin-1208 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 25th March 2022
Attendees:
Don Cragun, IEEE PASC OR
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
Andrew Josey, The Open Group
Geoff Clare, The Open Group
Mark Ziegast, SHware Systems Dev.
Eric Ackermann, HPI, University of Potsdam
Eric Blake, Red Hat, The Open Group OR
Apologies
Tom Thompson, IEEE
* General news
This was a call dedicated to general bugs.
* Outstanding actions
Bug 1533: struct tm: add tm_gmtoff (and tm_zone) field(s) OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1533
This was discussed in the February 3, 2022 teleconference.
Leave it open until we get a more complete suggestion for the Desired
Action.
* Current Business
Bug 1544: uudecode: standardise or at least reserve - as another special symbol
for decoding to stdout
https://austingroupbugs.net/view.php?id=1544 Open
Left open, but status changed to "Resolution Proposed"
Andrew still has the action to seek another contact at IBM.
Bug 1546: BREs: reserve \? \+ and \| Accepted as Marked
https://austingroupbugs.net/view.php?id=1546
See https://austingroupbugs.net/view.php?id=1546#c5755 for details
Bug 773: Add \+, \?, and \| to Basic Regular Expressions (BREs) Dup of 1546
https://austingroupbugs.net/view.php?id=773
Closed as a duplicate of 1546
Bug 1550: clarifications/ambiguities in the description of context addresses
and their delimiters for sed OPEN
https://austingroupbugs.net/view.php?id=1550
AI Geoff: Propose wording to make the changes suggested in bugnote 5756
Bug 1551: sed: ambiguities in the how BREs/EREs are parsed/interpreted between
delimiters (especially when these are special characters) OPEN
https://austingroupbugs.net/view.php?id=1551
AI Geoff: Propose wording to make the changes suggested in bugnote 5757
Bug 1553: find has two references to -n option that should be about -name
Accepted marked
https://austingroupbugs.net/view.php?id=1553
This item is tagged for TC3-2008
On page 2800 line 92074 (XCU section find (LC_COLLATE)), change:
used in the pattern matching notation for the -n option
to:
used in the pattern matching notation for the -name and -path primaries
On page 2800 line 92079 (XCU section find (LC_CTYPE)), change:
within the pattern matching notation used for the -n option
to:
within the pattern matching notation used for the -name and -path primaries
Note to the editor: this does not need to be merged into the Issue
8 branch as it has already been fixed there.
Bug 1554: find's rationale has odd comment about -name pattern matching
Accepted as Marked
https://austingroupbugs.net/view.php?id=1554
This item is tagged for TC2-2008
On page 2803 line 92185 section find, delete:
The -name file operand was changed
to use the shell pattern matching notation so that find
is consistent with other utilities using pattern matching.
(for historical references: https://github.com/dspinellis/unix-history-repo)
Bug 1555: -a/allexport spec should cover ${var=value} and ${var:=value} OPEN
https://austingroupbugs.net/view.php?id=1555
We will continue this next time
Next Steps
--
The next calls are on:
Mon 2022-03-28 (gettext)
Thu 2022-03-31 (general bugs)
The calls are for 90 minutes
Calls are anchored on US time. (8am Pacific)
Please check the calendar invites for dial in details.
Bugs are at:
https://austingroupbugs.net
An etherpad is usually up for the meeting, with a URL using the date format as
below:
https://posix.rhansen.org/p/20xx-mm-dd
(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)
Andrew JoseyThe Open Group
Austin Group Chair
Email: a.jo...@opengroup.org
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England
To learn how we maintain your privacy, please review The Open Group Privacy
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481
Proposed Interpretations for 30 day review
All The following interpretations have been proposed and are available for a 30 day review 0001549 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Escaped newline in macro expansion in command line. https://austingroupbugs.net/view.php?id=1549 0001538 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities what -s is poorly described, uses the word “quit” https://austingroupbugs.net/view.php?id=1538 Comments back no later than April 25 2022 regards Andrew Andrew JoseyThe Open Group Austin Group Chair Email: a.jo...@opengroup.org Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England To learn how we maintain your privacy, please review The Open Group Privacy Statement at http://www.opengroup.org/privacy. To unsubscribe/opt-out from this mailing list login to The Open Group collaboration portal at https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481
[1003.1(2016/18)/Issue7+TC2 0001538]: what -s is poorly described, uses the word "quit"
The following issue has been UPDATED. == https://austingroupbugs.net/view.php?id=1538 == Reported By:andras_farkas Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1538 Category: Shell and Utilities Type: Error Severity: Editorial Priority: normal Status: Interpretation Required Name: Andras Farkas Organization: User Reference: Section:what Page Number:3437 Line Number:116041 Interp Status: Proposed Final Accepted Text:https://austingroupbugs.net/view.php?id=1538#c5675 == Date Submitted: 2021-12-05 06:48 UTC Last Modified: 2022-03-25 17:08 UTC == Summary:what -s is poorly described, uses the word "quit" == -- (0005764) agadmin (administrator) - 2022-03-25 17:08 https://austingroupbugs.net/view.php?id=1538#c5764 -- Interpretation proposed: 25 March 2022 Issue History Date ModifiedUsername FieldChange == 2021-12-05 06:48 andras_farkas New Issue 2021-12-05 06:48 andras_farkas Name => Andras Farkas 2021-12-05 06:48 andras_farkas Section => what 2022-02-17 09:02 Don Cragun Page Number => 3437 2022-02-17 09:02 Don Cragun Line Number => 116041 2022-02-17 09:02 Don Cragun Interp Status => --- 2022-02-17 15:57 geoffclare Note Added: 0005674 2022-02-17 17:00 geoffclare Note Added: 0005675 2022-02-17 17:02 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1538#c5675 2022-02-17 17:02 geoffclare Status New => Interpretation Required 2022-02-17 17:02 geoffclare Resolution Open => Accepted As Marked 2022-02-17 17:03 geoffclare Interp Status--- => Pending 2022-02-17 17:03 geoffclare Tag Attached: tc3-2008 2022-02-18 09:14 kreNote Added: 0005680 2022-02-18 09:39 geoffclare Note Added: 0005681 2022-02-18 14:39 andras_farkas Note Added: 0005682 2022-02-18 15:07 andras_farkas Note Added: 0005683 2022-02-18 19:20 kreNote Added: 0005687 2022-02-18 19:27 kreNote Added: 0005688 2022-03-25 17:08 agadminInterp StatusPending => Proposed 2022-03-25 17:08 agadminNote Added: 0005764 ==
[1003.1(2016/18)/Issue7+TC2 0001549]: Escaped newline in macro expansion in command line.
The following issue has been UPDATED. == https://austingroupbugs.net/view.php?id=1549 == Reported By:dmitry_goncharov Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1549 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Interpretation Required Name: Dmitry Goncharov Organization: User Reference: Section:Makefile Syntax Page Number:2973 Line Number:98627 Interp Status: Proposed Final Accepted Text:https://austingroupbugs.net/view.php?id=1549#c5754 == Date Submitted: 2022-01-13 16:18 UTC Last Modified: 2022-03-25 17:08 UTC == Summary:Escaped newline in macro expansion in command line. == -- (0005763) agadmin (administrator) - 2022-03-25 17:08 https://austingroupbugs.net/view.php?id=1549#c5763 -- Interpretation proposed: 25 March 2022 Issue History Date ModifiedUsername FieldChange == 2022-01-13 16:18 dmitry_goncharovNew Issue 2022-01-13 16:18 dmitry_goncharovName => Dmitry Goncharov 2022-01-13 16:18 dmitry_goncharovURL => https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html 2022-01-13 16:18 dmitry_goncharovSection => Makefile Syntax 2022-01-14 09:46 geoffclare Project Online Pubs => 1003.1(2016/18)/Issue7+TC2 2022-01-14 09:47 geoffclare Page Number => 2973 2022-01-14 09:47 geoffclare Line Number => 98627 2022-01-14 09:47 geoffclare Interp Status => --- 2022-01-14 09:47 geoffclare Note Added: 0005604 2022-01-14 09:53 geoffclare Note Added: 0005605 2022-01-14 14:14 psmith Note Added: 0005606 2022-01-14 20:31 dmitry_goncharovNote Added: 0005609 2022-03-17 16:14 geoffclare Note Added: 0005754 2022-03-17 16:15 geoffclare Interp Status--- => Pending 2022-03-17 16:15 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1549#c5754 2022-03-17 16:15 geoffclare Status New => Interpretation Required 2022-03-17 16:15 geoffclare Resolution Open => Accepted As Marked 2022-03-17 16:15 geoffclare Tag Attached: tc3-2008 2022-03-25 17:08 agadminInterp StatusPending => Proposed 2022-03-25 17:08 agadminNote Added: 0005763 ==
[Issue 8 drafts 0001556]: clarify meaning of \n used in a bracket expression in a sed context address or s-command
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1556 == Reported By:calestyo Assigned To: == Project:Issue 8 drafts Issue ID: 1556 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Christoph Anton Mitterer Organization: User Reference: Section:Utilities, sed / 9.3.5 RE Bracket Expression Page Number:- Line Number:- Final Accepted Text: == Date Submitted: 2022-01-18 01:07 UTC Last Modified: 2022-03-25 16:37 UTC == Summary:clarify meaning of \n used in a bracket expression in a sed context address or s-command == -- (0005762) geoffclare (manager) - 2022-03-25 16:37 https://austingroupbugs.net/view.php?id=1556#c5762 -- In my opinion the only point raised in this bug that had any need to be addressed is the part of https://austingroupbugs.net/view.php?id=1556#c5622 that gave the example of snAAA[\n]nXXXn but only because of the ambiguity pointed out in bug https://austingroupbugs.net/view.php?id=1550 regarding delimiter escaping. I believe the changes proposed in https://austingroupbugs.net/view.php?id=1550#c5761 for the s command resolve that ambiguity and therefore no further changes are needed for this bug. Issue History Date ModifiedUsername FieldChange == 2022-01-18 01:07 calestyo New Issue 2022-01-18 01:07 calestyo Name => Christoph Anton Mitterer 2022-01-18 01:07 calestyo Section => Utilities, sed / 9.3.5 RE Bracket Expression 2022-01-18 01:07 calestyo Page Number => - 2022-01-18 01:07 calestyo Line Number => - 2022-01-18 09:41 geoffclare Note Added: 0005621 2022-01-18 13:26 calestyo Note Added: 0005622 2022-01-18 16:30 kreNote Added: 0005623 2022-01-18 17:12 calestyo Note Added: 0005624 2022-01-18 18:41 shware_systems Note Added: 0005625 2022-01-18 21:17 calestyo Note Added: 0005626 2022-01-18 21:19 calestyo Note Edited: 0005626 2022-03-25 16:37 geoffclare Note Added: 0005762 ==
Austin Group teleconference +1 888 974 9888 PIN 618 156 403
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1// CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:20120311T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:20121104T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:623df3a895...@opengroup.org DTSTAMP:20220325T165400Z ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org CREATED:20220325T00Z DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 31-Mar-2022 at 11: 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open group.org/platform/single_unix_specification/events.php\n\n* All calls are anchored on US time **\n\nTopic: Austin Group teleconference\n--- \nAudio conference information \n---\n\nYou are invit ed to a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, i OS or Android: https://logitech.zoom.us/j/618156403\n \nor join by phone: \nUS: 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n \nOther international numbers available here:\nhttps://zoom.us/u/adlvrb8IL j\n \nMeeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\n Dial: 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID: 618 156 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n \nOr iPhone one-tap (US Toll): +16699006833\,618156403# or +16465588656\, 618156403#\n\nPassword for zoom call ends with x\n\nAll Austin Group part icipants are most welcome to join the call.\nThe call will last for 90 min utes.\n\n\nAn etherpad is usually up for a meeting\, with a URL using the date format as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\n\nLOGIN R EQUIRED to write to the ETHERPAD (Use your gitlab.opengroup.org login.)\n \n\nBug reports are available at:\nhttps://www.austingroupbugs.net\n DTSTART;TZID=America/New_York:20220331T11 DURATION:PT1H30M0S LAST-MODIFIED:20220325T125400Z ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403 TRANSP:OPAQUE URL:https://collaboration.opengroup.org/platform/single_unix_specification/ events.php X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-VISIBILITY:40 X-JOINBEFORE:5 X-CATEGORY:Teleconference X-PLATO-SITE:Single UNIX Specification X-PLATO-SITEID:136 END:VEVENT END:VCALENDAR meeting.ics Description: application/ics
[Issue 8 drafts 0001550]: clarifications/ambiguities in the description of context addresses and their delimiters for sed
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1550
==
Reported By:calestyo
Assigned To:
==
Project:Issue 8 drafts
Issue ID: 1550
Category: Shell and Utilities
Type: Enhancement Request
Severity: Editorial
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:32 UTC
Last Modified: 2022-03-25 16:18 UTC
==
Summary:clarifications/ambiguities in the description of
context addresses and their delimiters for sed
==
Relationships ID Summary
--
related to 0001551 sed: ambiguities in the how BREs/EREs a...
==
--
(0005761) geoffclare (manager) - 2022-03-25 16:18
https://austingroupbugs.net/view.php?id=1550#c5761
--
Proposed changes to fix this bug and bug
https://austingroupbugs.net/view.php?id=1551 (I was unable to
disentangle the changes into two clean separate edits):
On page 3134 line 106070 section sed, after:... preceded and
followed by a delimiter, usually a ).add a new
paragraph:In a context address, any character other than
or can be specified for use as the delimiter by means
of the construction "\cREc", where c is the chosen
delimiter character. The BRE and ERE syntax shall additionally support
escaping occurrences of the delimiter within the RE with an unescaped
(except inside a bracket expression). If the character
designated by c is not special in a BRE or ERE according to [xref to
XBD 9.3] or [xref to XBD 9.4], respectively, the escape sequence
c shall be treated as that literal character; otherwise,
it is unspecified whether the escape sequence c is
treated as the literal character or the special character. In either case,
the escape sequence c shall not terminate the RE. For
example, the context address "\xabc\xdefx" is equivalent to
"/abcxdef/".
On page 3134 line 106087 section sed, replace the first bullet item
(beginning "In a context address") with:The delimiter character
that precedes and follows the RE shall not terminate the RE when it appears
within a bracket expression. For example, the context address "/[/]/" is
equivalent to "/\//".
On page 3137 line 106204 section sed (s command), change:Within
the RE and the replacement, the RE delimiter itself can be used as a
literal character if it is preceded by a
.to:Within the RE and the replacement,
the delimiter shall not terminate the RE or replacement if it is preceded
by an unescaped (that is not inside a bracket expression in the
RE, where the delimiter does not terminate the RE anyway - see [xref to
Regular Expressions in sed]). If the delimiter character is not special in
a BRE or ERE according to [xref to XBD 9.3] or [xref to XBD 9.4],
respectively, the escape sequence delimiter shall be
treated as that literal character in the RE; otherwise, it is unspecified
whether the escape sequence delimiter is treated as the
literal character or the special character. Likewise, if the delimiter
character is not ('&'), the escape sequence
delimiter shall be treated as that literal character in
the replacement; if it is , it is unspecified whether the escape
sequence delimiter is treated as the literal character or
the special character (see below).
On page 3138 line 106253 section sed (y command), change:...
the delimiter itself can be used as a literal character if it is preceded
by a . If a character is immediately followed by a
character in string1 or string2, the two
characters shall be counted as a single literal
character.to:... the delimiter itself can be used
as a literal character if it is preceded by an unescaped . If a
character is escaped by an immediately preceding unescaped
character in string1 or string2, the two
characters shall be treated as a single literal
character.
On page 3138 line 106278 section sed, add a new paragraph to APPLICATION
USAGE:Applications that use a special RE character as
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Geoff Clare wrote, on 25 Mar 2022: > > > ln -s /tmp/gibberish/file d/link2 > > realpath d/link2 > > $ realpath d/link2; echo exit $? > realpath: d/link2: No such file or directory > exit 1 I obviously didn't pay enough attention to this result, as the wording change I proposed doesn't cover it. I can't see any reasonable way to describe it by reference to realpath(), so I think we'll need to find a different approach. Perhaps something along these lines: The realpath utility shall recursively expand all symbolic links in the pathname specified by the file operand, using the algorithm specified in [xref to Pathname Resolution], until one of the following conditions is met: * The last component of the expanded pathname is found to exist and is not a symbolic link. * The last component of the expanded pathname is found not to exist or its existence cannot be determined. * A component of the path prefix of the expanded pathname is found not to exist or its existence cannot be determined. In this case, realpath shall write a diagnostic message to standard error and exit with a non-zero exit status. and then have the realpath() "as if" stuff, but passing it the expanded pathname, or its prefix if -e isn't specified. Will that work? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
[I have quoted kre's mail in full here, not just the parts I'm
replying to, because the original didn't go to the list.]
Robert Elz wrote, on 25 Mar 2022:
>
> | Do these results (from coreutils 8.30) cover what you need to know:
>
> Some of it, but you tested a directory with x permission, but
> without r (in addition to one with neither) where the more
> interesting case is one with r (so we can see what files exist)
> but without x (so they cannot be stat'd to determine if they
> are symlinks or not - assuming a filesys where the directory doesn't
> contain file type info).
$ mkdir -m a=rw d_nox
$ realpath ./d_nox/foo; echo exit $?
realpath: ./d_nox/foo: Permission denied
exit 1
$ realpath -e ./d_nox/foo; echo exit $?
realpath: ./d_nox/foo: Permission denied
exit 1
> There are also more cases of symlinks to consider
>
> test -d /tmp/realpath || mkdir /tmp/realpath
> cd /tmp/realpath
> mkdir d
> rm -rf foo
> ln -s /tmp/realpath/foo d/link
> realpath d/link
$ realpath d/link; echo exit $?
/tmp/realpath/foo
exit 0
$ realpath -e d/link; echo exit $?
realpath: d/link: No such file or directory
exit 1
> is one, and then
>
> ln -s /tmp/gibberish/file d/link2
> realpath d/link2
$ realpath d/link2; echo exit $?
realpath: d/link2: No such file or directory
exit 1
$ realpath -e d/link2; echo exit $?
realpath: d/link2: No such file or directory
exit 1
> is another. Those are both cases where the final component
> (link and link2) names a file that doesn't exist (in a sense,
> the case "realpath d/nofile" is the simple one, handling that
> case is easy), but in a different way, are they treated the same
> or differently? And what happens in any case? I can do no more
> that guess.
They are different (without -e). Here is what strace shows for
the two cases:
lstat64("/tmp/realpath/d", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/tmp/realpath/d/link", {st_mode=S_IFLNK|0777, st_size=17, ...}) = 0
readlink("/tmp/realpath/d/link", "/tmp/realpath/foo", 18) = 17
lstat64("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64("/tmp/realpath", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/tmp/realpath/foo", 0xbfbe9a3c) = -1 ENOENT
lstat64("/tmp/realpath/d", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/tmp/realpath/d/link2", {st_mode=S_IFLNK|0777, st_size=19, ...}) = 0
readlink("/tmp/realpath/d/link2", "/tmp/gibberish/file", 20) = 19
lstat64("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64("/tmp/gibberish", 0xbfe9cf8c) = -1 ENOENT
> The examples with -e are less interesting, those should be
> how our realpath acts now, but I will verify later, I will only
> comment more on that if there are differences.
>
> | My bugnote 5700 has what I came up with for readlink -f (without -n),
> | which I think could be reused for realpath without -e.
>
> Yes, the 2nd bullet point looks about right, but that makes it more
> important to verify what the coreutils version does with a directory
> that has read premission, but no x permission, as:
>
> If the file operand names a file that is not a symbolic link,
> or if the path prefix of file resolves, with symbolic links followed,
> to an existing directory
>
> that much is just realpath(3) on the path prefix (and probably a
> test that the result is a directory), and that's fine
>
> and the final component of file does not exist as a directory
> entry in that directory,
>
> and that can be determined by reading the directory, and comparing
> entries with the final component of "file" to see if that is an entry
> in the directory or not - which requires r permission, but doesn't
> need x, or by calling lstat() on the results from realpath, with the
> final component appended, which requires x but doesn't require r.
>
> Which one are we supposed to do to determine this question? Which
> dces the coreutils version do? The text (probably for both readlink -f
> and realpath) needs to be very clear about this.
Here's the strace for the d_nox case:
lstat64("/tmp/realpath/d_nox", {st_mode=S_IFDIR|0666, st_size=4096, ...}) = 0
lstat64("/tmp/realpath/d_nox/foo", 0xbf97522c) = -1 EACCES
It doesn't read any directories, it just uses lstat() for existence
checks.
However, I don't see the need for the standard to be specific about
this, since there are many other places where it talks about existence
of files but doesn't specify how the existence check is done. If an
implementation wants to go the extra mile and try to read the directory
after an EACCES from lstat(), it can. It's a quality-of-implementation
issue.
> | It doesn't state anything explicit about the directory permissions,
> | but I think that's fine because it's normal for utility descriptions
> | to leave such things to be covered by the general rules on utility errors.
>
> As it is written in that note it is fine, if the necessary
