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:6087a14e21...@opengroup.org DTSTAMP:20210427T052950Z ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org CREATED:20210427T00Z DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 03-May-2021 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\n\nBug reports are available at:\nhttps://www.austingroupbugs.net\n DTSTART;TZID=America/New_York:20210503T11 DURATION:PT1H30M0S LAST-MODIFIED:20210427T012950Z 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
Re: [1003.1(2008)/Issue 7 0001468]: awk FS definition not quite correct
On Mon, Apr 26, 2021 at 12:26 PM Geoff Clare via austin-group-l at The
Open Group wrote:
>
> Oğuz wrote, on 25 Apr 2021:
> >
> > On Sat, Apr 24, 2021 at 6:22 PM Austin Group Bug Tracker via
> > austin-group-l at The Open Group wrote:
> > > $ echo 'x,,z' | awk -F'[^,]*' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
> > > 1 <>
> > > 2 <,,>
> > > 3 <>
> >
> > This seems rather like an implementation bug. Although mawk and nawk
> > agree with gawk on how that case should be handled, there really is no
> > reason for `,,' to be a single field there. And if you replace the
> > asterisk with its interval equivalent, there is no consensus on how
> > that should work among existing implementations (the ones I have
> > access to, at least).
> >
> > $ echo 'x,,z' | gawk -F'[^,]{0,}' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
> > 1 <>
> > 2 <,,>
> > 3 <>
> > $
> > $ echo 'x,,z' | mawk -F'[^,]{0,}' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
> > 1
> > $
> > $ echo 'x,,z' | nawk -F'[^,]{0,}' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
> > 1
> > $
>
> The mawk and nawk behaviour is clearly just wrong here. Fields should
> never contain (non-empty) parts that match FS.
>
> > $ echo 'x,,z' | busybox awk -F'[^,]{0,}' '{for (i=1;i<=NF;i++) print
> > i, "<"$i">"}'
> > 1 <>
> > 2 <,>
> > 3 <,>
> > 4 <>
> > 5 <>
>
> Busybox awk also does this with -F'[^,]*'
>
> > And the expected output is as follows.
> >
> > 1 <>
> > 2 <,>
> > 3 <,>
> > 4 <>
> >
> > So either the standard should make the behavior unspecified when `FS'
> > is an ERE that would match a zero-length string, or implementations
> > should fix these bugs.
>
> I think there are two reasonable choices: either require that FS
> does not match zero-length strings (as in the desired action in the
> bug), or make it unspecified whether or not it matches zero-length
> strings. If we do the latter, busybox would have a minor bug because
> of the extra field, and the mawk and nawk behaviour with {0,} would
> still not conform.
Apparently the majority of implementations behave the way gawk does or
try to do so, and it makes sense too. There really aren't many use
cases where busybox awk behavior would be helpful. Upon reflection, I
think the former choice, requiring FS to not match zero-length
strings, would be the best.
>
> --
> Geoff Clare
> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
>
Re: [1003.1(2008)/Issue 7 0001468]: awk FS definition not quite correct
Oğuz wrote, on 25 Apr 2021:
>
> On Sat, Apr 24, 2021 at 6:22 PM Austin Group Bug Tracker via
> austin-group-l at The Open Group wrote:
> > $ echo 'x,,z' | awk -F'[^,]*' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
> > 1 <>
> > 2 <,,>
> > 3 <>
>
> This seems rather like an implementation bug. Although mawk and nawk
> agree with gawk on how that case should be handled, there really is no
> reason for `,,' to be a single field there. And if you replace the
> asterisk with its interval equivalent, there is no consensus on how
> that should work among existing implementations (the ones I have
> access to, at least).
>
> $ echo 'x,,z' | gawk -F'[^,]{0,}' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
> 1 <>
> 2 <,,>
> 3 <>
> $
> $ echo 'x,,z' | mawk -F'[^,]{0,}' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
> 1
> $
> $ echo 'x,,z' | nawk -F'[^,]{0,}' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
> 1
> $
The mawk and nawk behaviour is clearly just wrong here. Fields should
never contain (non-empty) parts that match FS.
> $ echo 'x,,z' | busybox awk -F'[^,]{0,}' '{for (i=1;i<=NF;i++) print
> i, "<"$i">"}'
> 1 <>
> 2 <,>
> 3 <,>
> 4 <>
> 5 <>
Busybox awk also does this with -F'[^,]*'
> And the expected output is as follows.
>
> 1 <>
> 2 <,>
> 3 <,>
> 4 <>
>
> So either the standard should make the behavior unspecified when `FS'
> is an ERE that would match a zero-length string, or implementations
> should fix these bugs.
I think there are two reasonable choices: either require that FS
does not match zero-length strings (as in the desired action in the
bug), or make it unspecified whether or not it matches zero-length
strings. If we do the latter, busybox would have a minor bug because
of the extra field, and the mawk and nawk behaviour with {0,} would
still not conform.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
