Re: [Issue 8 drafts 0001798]: Must posix_getdents remember file offsets across exec?

Austin Group Bug Tracker via austin-group-l at The Open Group wrote in <2b5daa16a52f70c01b47c5d1ad8b3...@austingroupbugs.net>: ... |https://austingroupbugs.net/view.php?id=1798 ... | (0006710) geoffclare (manager) - 2024-03-07 18:14 | https://austingroupbugs.net/view.php?id=1798#c6710 ...

Re: [Issue 8 drafts 0001798]: Must posix_getdents remember file offsets across exec?

Austin Group Bug Tracker via austin-group-l at The Open Group wrote in : ... |https://austingroupbugs.net/view.php?id=1798 ... | (0006709) corinna_vinschen (reporter) - 2024-03-07 15:00 | https://austingroupbugs.net/view.php?id=1798#c6709 ... |You're missing the fact that the underlying

Re: [Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

Geoff Clare via austin-group-l at The Open Group wrote in : |Steffen Nurpmeso wrote, on 26 Feb 2024: |>|https://austingroupbugs.net/view.php?id=1797 |> ... |>| (0006689) eblake (manager) - 2024-02-26 19:32 |>| https://austingroupbugs.net/view.php?id=1797#c6689 |> ... |&g

Re: [Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

|https://austingroupbugs.net/view.php?id=1797 ... | (0006689) eblake (manager) - 2024-02-26 19:32 | https://austingroupbugs.net/view.php?id=1797#c6689 ... |[.]inconsistent with existing practice where some implementations set it to |"GMT"[.] The TZ project itself as such changed just

Re: [Issue 8 drafts 0001801]: xargs: add -P option

Austin Group Bug Tracker via austin-group-l at The Open Group wrote in <5fd3ccb27ac7b65bcfbd97abb3a03...@austingroupbugs.net>: ... |https://austingroupbugs.net/view.php?id=1801 ... |related to 0001811 xargs: add -P option to FUTURE DIRECTIO... ... | (0006670) gabravier (reporter)

Re: [Issue 8 drafts 0001800]: be*toh() have no entries

|https://austingroupbugs.net/view.php?id=1800 ... |Summary:be*toh() have no entries ... | (0006640) steffen (reporter) - 2024-01-25 21:29 | https://austingroupbugs.net/view.php?id=1800#c6640 |-- |No

Re: [Issue 8 drafts 0001799]: endian.h unconditionally requires 64-bit integers

... |https://austingroupbugs.net/view.php?id=1799 ... |Summary:endian.h unconditionally requires 64-bit \ |integers ... Mantis did not post the follow-up message, neither to me nor to https://www.mail-archive.com/austin-group-l@opengroup.org/ Something is wrong

64-bit integer types?

Hello. I just read Paul Eggert on the IANA TZ list saying that POSIX does not require 64-bit integer times, and when i look into that i see (for stdint.h): 12961If an implementation provides integer types with width 64 that meet these requirements, 12962then the

Re: mantis does not email-emit my web edits?

Steffen Nurpmeso via austin-group-l at The Open Group wrote in <20240108212050.2X5aptGT@steffen%sdaoden.eu>: |It seems Mantis did record, but not actually post my web edits of |this year, including the opened issue on tzalloc etc. |It would be nice if these would come :) It seems

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

Andrew Josey via austin-group-l at The Open Group wrote in <36c65d39-81c9-4852-9b1d-43533395d...@opengroup.org>: |> On 5 Jan 2024, at 05:12, Robert Elz via austin-group-l at The Open \ |> Group wrote: |> |>Date:Thu, 04 Jan 2024 23:24:26 +0100 |> From:

mantis does not email-emit my web edits?

Hello. It seems Mantis did record, but not actually post my web edits of this year, including the opened issue on tzalloc etc. It would be nice if these would come :) Ciao -- and a good and healthy 2024 everybody, if at all possible! --steffen | |Der Kragenbaer,The moon bear,

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

Hello. Robert Elz wrote in <2506.1704431...@jacaranda.noi.kre.to>: |Date:Thu, 04 Jan 2024 23:24:26 +0100 |From: Steffen Nurpmeso |Message-ID: <20240104222426.ai7_3Mvo@steffen%sdaoden.eu> | || I was hoping for the draft; the selection list do

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

enh wrote in : |for other precedent, bionic [Android] has tzalloc()/tzfree(), |mktime_z(), localtime_rz(), and the timezone_t type since API level |35: | |https://android.googlesource.com/platform/bionic/+/main/libc/include/time.h Not yet released? "Vanilla ice cream". It really is the

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

Robert Elz wrote in <25502.1704337...@jacaranda.noi.kre.to>: |Date:Thu, 04 Jan 2024 00:21:45 +0100 |From: "Steffen Nurpmeso via austin-group-l at The Open Group" \ | |Message-ID: <20240103232145.6dAnvvQf@steffen%sdaoden.eu> | || My q

IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

Hello. A happy and healthy new year 2024 i wish. As stated in [1] the localtime() and mktime() series of functions have the inherent problem of not being thread-safe regarding possible changes to the time zone: in a pure POSIX environment changes to TZ always affect global data. If my memory

Re: bug#65659: RFC: changing printf(1) behavior on %b

Stephane Chazelas wrote in <20230902084912.vdfedsgbnat2w...@chazelas.org>: |2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The \ |Open Group: ... |>|FWIW, a "printf %b" github shell code search returns ~ 29k |>|entries |>|(https://github.com/sear

Re: bug#65659: RFC: changing printf(1) behavior on %b

Stephane Chazelas via austin-group-l at The Open Group wrote in <20230901181024.pwx4plwclz7ij...@chazelas.org>: |2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group: ... |> How many scripts in the wild actually use %b, though? And if there |> are such scripts, anything

Fwd: Re: RFC: changing printf(1) behavior on %b

Dropped that from my mail queue as i realized there are many other receivers. (And saw Stephane writing much more to bug-bash@.) --- Forwarded from Steffen Nurpmeso --- Date: Fri, 01 Sep 2023 18:34:34 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: "Oğuz via austin-gr

Re: probable UB in recently accepted text

Thorsten Glaser wrote in : |https://www.austingroupbugs.net/view.php?id=561#c6085 (the accepted |text) suggests that… | | versions, the size is typically in the range 92 to 108. An \ | application can | deduce the size by using sizeof(((struct sockaddr_un *)0)->sun_pat\ |

Re: [1003.1(2016/18)/Issue7+TC2 0001642]: DUMB terminal is not defined

Austin Group Bug Tracker wrote in : ... |https://austingroupbugs.net/view.php?id=1642 ... |Summary:DUMB terminal is not defined ... | (0006270) ajosey (manager) - 2023-04-22 08:56 | https://austingroupbugs.net/view.php?id=1642#c6270

Re: $? behaviour after comsub in same command

Robert Elz wrote in <6906.1680741...@jacaranda.noi.kre.to>: ... |The issue here is that people tend to think of | a=1 |as a command. It isn't (not as people think of it anyway). |But with that mindset they treat | a=1 b=$a c=$b |as 3 commands, one after the other. It isn't. To come

Re: $? behaviour after comsub in same command

Steffen Nurpmeso wrote in <20230405193451.u9bfz%stef...@sdaoden.eu>: |Harald van Dijk wrote in | <32a27194-a5ff-68d6-3a87-9120e34d8...@gigawatt.nl>: ||On 05/04/2023 17:44, Oğuz wrote: ||> 5 Nisan 2023 Çarşamba tarihinde Harald van Dijk <mailto:a...@gigawatt.nl>> ya

Re: $? behaviour after comsub in same command

Harald van Dijk wrote in <32a27194-a5ff-68d6-3a87-9120e34d8...@gigawatt.nl>: |On 05/04/2023 17:44, Oğuz wrote: |> 5 Nisan 2023 Çarşamba tarihinde Harald van Dijk > yazdı: |> |> I am not sure which other ash based shells you were looking at, |> |> /bin/sh on

Re: [Issue 8 drafts 0001652]: make: missing option argument

Austin Group Bug Tracker wrote in <0c040d43e9caec7f953fb5bb47219...@austingroupbugs.net>: ... |-- | (0006242) geoffclare (manager) - 2023-04-03 09:31 | https://austingroupbugs.net/view.php?id=1652#c6242

Re: Austin Group questions on iconv()

Eric Blake wrote in <20230309164325.xmqp7mf62obpn...@redhat.com>: |In today's Austin Group meeting, the folks discussing POSIX had a |question for Bruno and/or anyone else with an idea on how the |standards should approach a difference in behavior between Solaris and |GNU iconv()

Re: Issue 991: it should be changed

Geoff Clare wrote in : |Steffen Nurpmeso wrote, on 19 Feb 2023: |> After looking into V10 mail, and all BSD mails i think issue 991 |> should be changed. This is my fault. | |Bug 991 has been applied, so it's not possible to change now. |(At least, we can't change the editing instru

Re: Issue 991: it should be changed

Steffen Nurpmeso wrote in <20230219012433.1dxoo%stef...@sdaoden.eu>: |After looking into V10 mail, and all BSD mails i think issue 991 |should be changed. This is my fault. ... |As i stated in the description, and to extend this description, |"mbox" (and "hold",

Issue 991: it should be changed

Hello. After looking into V10 mail, and all BSD mails i think issue 991 should be changed. This is my fault. Change on page 2923, starting at line 96567: Arrange for the given messages to end up in the mbox save file when mailx terminates normally. to: Arrange for the

Re: behavior of the QUIT character (^\) in the shell command line

Robert Elz wrote in <17402.1671424...@jacaranda.noi.kre.to>: |Date:Mon, 19 Dec 2022 00:17:25 +0100 |From:"Vincent Lefevre via austin-group-l at The Open Group" \ | |Message-ID: <20221218231725.ga104...@zira.vinc17.org> | || Well, so it is not forbidden to

Re: Add -print0 to "find"

Geoff Clare wrote in : |Stephane Chazelas wrote, on 08 Dec 2022: |> 2022-12-08 15:39:32 +, Austin Group Bug Tracker via austin-group-l \ |> at The Open Group: |> [...] |>> It is looking like the group might decide to add find -print0 and \ |>> related |>> xargs and read features (for

Re: "null terminator" v. "NUL terminator" (was: [1003.1(2008)/Issue 7 0000561]: NUL-termination of sun_path in Unix sockets)

Geoff Clare wrote in : |Steffen Nurpmeso wrote, on 01 Dec 2022: |> Being here, i note an increasing number of "null terminators" for |> strings, which surely is wrong as NULL==(void*)0 (or similar aka |> 0x0, 0, __null, whatever they are doing now and have complained or |

Re: [1003.1(2008)/Issue 7 0000561]: NUL-termination of sun_path in Unix sockets

If it was not the GNU C library info manual around Y2K which mentioned how a SUN_LEN() has to look like if it is not available. In the accepted text in https://austingroupbugs.net/view.php?id=561, for bind(2), a space is missing in between where and address_len. For AF_UNIX sockets, some

Re: [1003.1(2008)/Issue 7 0000561]: NUL-termination of sun_path in Unix sockets

Olivier Certner wrote in <9027911.U91TZCKOhC@ravel>: |> Having written that, I did test that 'sizeof(((struct |> sockaddr_un*)0)->sun_path)' compiles with gcc, although I'm less |> certain of whether the C standard permits that (or even if that |> permission has changed over time) - the

Re: [1003.1(2008)/Issue 7 0000561]: NUL-termination of sun_path in Unix sockets

Eric Blake wrote in <20221130150909.pei323lktieb4...@redhat.com>: |On Wed, Nov 30, 2022 at 08:54:03AM -0600, Eric Blake via austin-group-l \ |at The Open Group wrote: |>> ... |>>|https://austingroupbugs.net/view.php?id=561 |> |> First, I chose that wording because 'sizeof(struct |>

Re: [1003.1(2008)/Issue 7 0000561]: NUL-termination of sun_path in Unix sockets

Austin Group Bug Tracker wrote in : ... |https://austingroupbugs.net/view.php?id=561 ... |-- | (0006085) geoffclare (manager) - 2022-11-28 16:24 | https://austingroupbugs.net/view.php?id=561#c6085

Re: [1003.1(2008)/Issue 7 0000249]: Add standard support for $'...' in shell

Geoff Clare wrote in : |Steffen Nurpmeso wrote, on 18 Oct 2022: |> Austin Group Bug Tracker wrote in |> <2969d655ede7498ce22799a53d077...@austingroupbugs.net>: |> ... |>|https://austingroupbugs.net/view.php?id=249 |> ... |>| https://austingroupbugs.n

Re: [1003.1(2008)/Issue 7 0000249]: Add standard support for $'...' in shell

Robert Elz wrote in <28905.1666177...@jacaranda.noi.kre.to>: |Date:Wed, 19 Oct 2022 08:26:46 +0100 |From:"Geoff Clare via austin-group-l at The Open Group" \ | |Message-ID: | || I can't see anything "a few lines earlier" that implies quotation-mark ||

Re: [1003.1(2008)/Issue 7 0000249]: Add standard support for $'...' in shell

Austin Group Bug Tracker wrote in <2969d655ede7498ce22799a53d077...@austingroupbugs.net>: ... |https://austingroupbugs.net/view.php?id=249 ... | https://austingroupbugs.net/view.php?id=249#c5995 ... |If a \e or \cX escape sequence specifies a character that does not have an |encoding in

Re: Thread queue position after unlocking PRIO_PROTECT mutex

shwaresyst wrote in <299142152.189695.1665484864...@mail.yahoo.com>: My idea was |What do implementations actually do? Hopefully do not give up their timeslice. but did not send it. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully

Re: [1003.1(2016/18)/Issue7+TC2 0001437]: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONALE

psm...@gnu.org wrote in <81a04e6224bf59f387aa8bb0a68bf89152b1cd29.ca...@gnu.org>: |On Tue, 2022-09-13 at 14:53 +0100, Geoff Clare via austin-group-l at |The Open Group wrote: |> If I'm honest those cases never occurred to me when we were working |> on the wording.  It seems unlikely a

bind(2) AF_UNIX .. path reusage

Hello. If i .. and bind(2) a AF_UNIX socket, and the server process dies, then the socket still "exists" in the filesystem, and any further bind(2) on the socket fails with EADDRINUSE on Linux 5.15.64, even though it is not actively bound via bind(2). There is no wording about this situation in

Re: stty default output/-a _POSIX_VDISABLE character "undef", contrasts with "" on all known implementations? Formatting loss->overinterpretation since Issue 6.

наб wrote in <20220910120939.iujppzbqbw4al...@tarta.nabijaczleweli.xyz>: ... |This is very curious! /I/ was very curious, at least. ... |My naive interpretation of this is that, after loss of monospacing from |POSIX.2 to SUSv1, at some point in Issue 6's creation, "" was |taken to mean

Re: [1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make

psm...@gnu.org wrote in <2f4c249e139c3391ae56f0027cde10df76292bfa.ca...@gnu.org>: |On Thu, 2022-09-08 at 15:53 +, Austin Group Bug Tracker via austin- |group-l at The Open Group wrote: |>  (0005962) geoffclare (manager) - 2022-09-08 15:53 |>  

Re: [1003.1(2008)/Issue 7 0000767]: Add built-in "local"

Christoph Anton Mitterer wrote in <708410359c03bc0cfb89bfc29baaa9000b0d00b1.ca...@scientia.org>: |On Mon, 2022-08-08 at 15:15 +, Austin Group Bug Tracker via austin- |group-l at The Open Group wrote: |> This was discussed during the 2022-08-08 conference call.  Since |> there is |> clear

Re: 202x/D2.1 cksum format specifier ambiguous/wrong?

Hello. Sorry for the late reply. наб wrote in <20220723210935.jwgfb2izb5owu...@tarta.nabijaczleweli.xyz>: |On Sat, Jul 23, 2022 at 10:32:35PM +0200, Steffen Nurpmeso wrote: |> наб wrote in |> <20220723193024.d7nv7lj43rhnl...@tarta.nabijaczleweli.xyz>: |>|Is the standar

Re: 202x/D2.1 cksum format specifier ambiguous/wrong?

наб wrote in <20220723193024.d7nv7lj43rhnl...@tarta.nabijaczleweli.xyz>: |According to XBD, 5 ("File Format Notation"), L3071: | ’ ’ (An empty character position.) | Represents one or more characters |and XRAT, A.5 ("File Format Notation") agrees in L117453-117455,117456-1\ |17457: |

Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments

Geoff Clare wrote in <20220526085434.GA19184@localhost>: |Steffen Nurpmeso wrote, on 24 May 2022: |> |> I find that "setlocale() may invalidate the string" painful, |> because many functions of the C library do not have _l() variants |> that could work with

Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments

Geoff Clare wrote in <20220524091849.GC25920@localhost>: |Bruno Haible wrote, on 12 May 2022: |> |> https://posix.rhansen.org/p/gettext_draft |> Line 573 |> |> "The application shall ensure that the codeset argument, if non-empty, \ |> is a |> valid codeset name that can be used as the

Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments

Hello! Steffen Nurpmeso wrote in <20220513135904.hhnsw%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20220513132857.xzhqq%stef...@sdaoden.eu>: ||Harald van Dijk wrote in || <9aa0b43f-c5de-1698-9f34-c725a40e6...@gigawatt.nl>: |||On 12/05/2022 23:10, Steffen Nurpmeso w

Re: When can shells remove "known" process IDs from the list?

chet.ra...@case.edu wrote in <217874a6-64d5-184b-68e8-0bedb322f...@case.edu>: |On 5/13/22 10:27 AM, Geoff Clare via austin-group-l at The Open Group \ |wrote: |> Chet Ramey wrote, on 13 May 2022: |>> On 5/13/22 5:20 AM, Geoff Clare via austin-group-l at The Open Group \ |>> wrote: |>>> The

Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments

Harald van Dijk wrote in <9aa0b43f-c5de-1698-9f34-c725a40e6...@gigawatt.nl>: |On 12/05/2022 23:10, Steffen Nurpmeso wrote: |> Harald van Dijk wrote in |> : |>|On 12/05/2022 18:19, Steffen Nurpmeso via austin-group-l at The Open |>|Group wrote: |>|> Bruno Haible w

Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments

Harald van Dijk wrote in : |On 12/05/2022 18:19, Steffen Nurpmeso via austin-group-l at The Open |Group wrote: |> Bruno Haible wrote in |> <4298913.vrqWZg68TM@omega>: |>|Steffen Nurpmeso wrote: |>|> ... |>|>| [.] "UTF-7"." |>|> |>

Re: ML reconfigured?

Steffen Nurpmeso wrote in <20220512173651.yl-pn%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20220512173033.jp_28%stef...@sdaoden.eu>: ||Just wondering, i no longer receive my own messages to the ML? ||I would henceforth save away my sent copy if this is desired? | |S

Re: ML reconfigured?

Steffen Nurpmeso wrote in <20220512173033.jp_28%stef...@sdaoden.eu>: |Just wondering, i no longer receive my own messages to the ML? |I would henceforth save away my sent copy if this is desired? So that i got. It thus seems selective values are selectively applied just as currently d

ML reconfigured?

Hello. Just wondering, i no longer receive my own messages to the ML? I would henceforth save away my sent copy if this is desired? --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks

Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments

Bruno Haible wrote in <4298913.vrqWZg68TM@omega>: |Steffen Nurpmeso wrote: |> ... |>| [.] "UTF-7"." |> |> That is overshoot. | |No. UTF-7 is invalid here because it produces output that is not NUL |terminated. See: | |$ printf 'ab\0' | iconv -t

Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments

Bruno Haible wrote in <24562059.ssLaC8jLEa@omega>: ... | [.] "UTF-7"." That is overshoot. (Though i'd wish they would have used it for internationalized domain names.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one

Re: When can shells remove "known" process IDs from the list?

chet.ra...@case.edu wrote in <195c7c59-8328-4ddc-b936-345f34ab1...@case.edu>: |On 5/10/22 12:03 PM, Geoff Clare via austin-group-l at The Open Group \ |wrote: ... |So for the known IDs list, it's pretty much `wait' and `jobs', right? Great words spoken easily. --steffen | |Der Kragenbaer,

Re: When can shells remove "known" process IDs from the list?

chet.ra...@case.edu wrote in <88762e56-0276-f936-cf4c-d48c8ddc2...@case.edu>: |On 4/29/22 4:23 PM, Robert Elz via austin-group-l at The Open Group wrote: ... |> true & X=$! ... |They're not jobs! A pid is a pid. It doesn't matter whether it's the pid of |the job's controlling process (or

Re: [1003.1(2016/18)/Issue7+TC2 0001533]: struct tm: add tm_gmtoff (and tm_zone) field(s)

Austin Group Bug Tracker wrote in <942dac4371c72bf106541bbfe42be...@austingroupbugs.net>: ... |-- | (0005745) steffen (reporter) - 2022-03-14 00:31 | https://austingroupbugs.net/view.php?id=1533#c5745

Re: [1003.1(2016/18)/Issue7+TC2 0001544]: uudecode: standardise or at least reserve - as another special symbol for decoding to stdout

Robert Elz wrote in <21233.1646233...@jinx.noi.kre.to>: || (0005725) steffen (reporter) - 2022-03-02 12:50 || https://austingroupbugs.net/view.php?id=1544#c5725 || -- || FreeBSD uuencode only supports -o /dev/stdout not

Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility

enh wrote in : |in terms of "what's actually used in the wild", Android uses toybox (0BSD |licensed, so anyone can look :-) ) for both on-device *and* for the OS |build itself on the host. | |toybox readlink ( |https://github.com/landley/toybox/blob/master/toys/other/readlink.c) |currently

Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility

Geoff Clare wrote in <20220225152553.GA4559@localhost>: |Robert Elz wrote, on 25 Feb 2022: |> |> OK. I have looked at the coreutils realpath man page (gnu licensing |> stupidity means I cannot look at their code), and I can see the |> possibility (subject to community agreement) of

Re: Bug 1562 and other locale issues

Steffen Nurpmeso wrote in <20220214152249.embet%stef...@sdaoden.eu>: ... |I mean the w* series can be used to work it at least. |Yes, it is wrong, because it does not work on grapheme |clusters, towupper(wint_t) for example is thus broken. Hah! I missed to add the German term Üb

Re: Bug 1562 and other locale issues

Robert Elz wrote in <22573.1644732...@jinx.noi.kre.to>: |In general I don't comment much on anything related to i18n, |as it is (way) outside my area. | |However, what is clear is that much of what we have related to |locales is a total botch - thrown together in the 80's/90's |when it was

Re: Future of locale, will there be POSIX.utf-8, what will it bring?

k...@keldix.com wrote in <20220110211651.ga2...@www5.open-std.org>: | |please also consider iso 30112, which is a full iso standard, |and written in posix style. it was taken from glibc, after glibc took \ |it from the iso 14652, |it has a number of categories in eccess of the posix oncs,

Re: Future of locale, will there be POSIX.utf-8, what will it bring?

Hello. shwaresyst wrote in <1494661216.220561.1641574109...@mail.yahoo.com>: [i resort a bit] | On Thu, Jan 6, 2022 at 3:40 PM, Steffen Nurpmeso via austin-group-l \ | at The Open Group wrote: Hello! | |I wonder about POSIX.utf-?8, i tried to remember any statement |i ha

Future of locale, will there be POSIX.utf-8, what will it bring?

Hello! I wonder about POSIX.utf-?8, i tried to remember any statement i had read, and Mantis did not show up results. In particular i am interested in whether LC_CTYPE results will bring true Unicode support or not, the reason i am asking is that the upcoming version of my work-box GNU

Re: [Issue 8 drafts 0001505]: Make doesn't seem to specify unset macro expansion behaviour

Geoff Clare wrote in <20211221103814.GB12295@localhost>: |Steffen Nurpmeso wrote, on 20 Dec 2021: |> |> For example CRUX-Linux has a /etc/pkgmk.conf where people can |> define $CFLAGS, $CXXFLAGS, etc., also things like |> |> export JOBS=$(nproc) |> ex

Re: [Issue 8 drafts 0001505]: Make doesn't seem to specify unset macro expansion behaviour

Hello. Geoff Clare wrote in <20211220133200.GA25606@localhost>: |Robert Elz wrote, on 18 Dec 2021: |> bsd make (bmake) has a couple of macros (the doc calls what are |> macros here variables, but they are the same thing), which default to |> being unset, which can be set in the environment

Re: [1003.1(2016/18)/Issue7+TC2 0001531]: time: follow-up to issue #1440

...i have omitted all those "sh -c" invocations without an expansion of command_string that could be misinterpreted. Ideally i catched them all. Ciao, and a nice weekend from Germany i wish, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully

Re: Interpretation starting for a 30 day review (1440)

Robert Elz wrote in <21180.1635554...@jinx.noi.kre.to>: |Date:Sat, 30 Oct 2021 02:23:40 +0200 |From: Steffen Nurpmeso |Message-ID: <20211030002340.gtkvv%stef...@sdaoden.eu> | || Dear Robert Elz, on the other hand || || #?127|unstable9s:$ /usr/xpg

Re: Interpretation starting for a 30 day review (1440)

Robert Elz wrote in <9905.1635549...@jinx.noi.kre.to>: |Date:Fri, 29 Oct 2021 16:42:48 -0500 |From:Eric Blake |Message-ID: <20211029214248.5rsezyh4wvgl2...@redhat.com> | | || Another thing to consider: if enough implementations fix things NOW to || use "--" in

Re: Interpretation starting for a 30 day review (1440)

Robert Elz wrote in <8552.1635508...@jinx.noi.kre.to>: |Date:Fri, 29 Oct 2021 09:51:09 +0100 |From:"Andrew Josey via austin-group-l at The Open Group" \ | |Message-ID: <5bf8909a-6cc2-4089-87c1-5fac762fa...@opengroup.org> ... || 0001440: System Interfaces

Re: [1003.1(2016/18)/Issue7+TC2 0001437]: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONALE

Hello Paul Smith, all. Paul Smith wrote in : |On Sat, 2021-08-28 at 02:38 +0200, Steffen Nurpmeso wrote: |> So to get to the gory details was a bit more complicated than i first |> thought, but i can offer a public domain patch for GNU make (git |> [012918bf11]) | |Hi Steffen

Re: [1003.1(2016/18)/Issue7+TC2 0001437]: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONALE

Dear Paul Smith, all. So to get to the gory details was a bit more complicated than i first thought, but i can offer a public domain patch for GNU make (git [012918bf11]) that for .WAIT: all: lib ham .WAIT bin bin2 ;@echo all command lib: lib/.stamp; @echo lib command ham: ;@echo ham

Re: [1003.1(2016/18)/Issue7+TC2 0001437]: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONALE

Steffen Nurpmeso wrote in <20210827004938.ufzjl%stef...@sdaoden.eu>: ... |+ if (any) |+ { |+ for (tmp = new; tmp != curr; tmp = tmp->next) |+ { |+ l = strlen(tmp->name) +1; |+ bu

Re: [1003.1(2016/18)/Issue7+TC2 0001437]: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONALE

Hello. Steffen Nurpmeso wrote in <20210825133359.wvpz4%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20210821231356.n0d_i%stef...@sdaoden.eu>: ||Paul Smith wrote in || : |||On Sat, 2021-08-21 at 02:24 +0200, Steffen Nurpmeso via austin-group-l |||at The Open Group wrot

Re: [1003.1(2016/18)/Issue7+TC2 0001437]: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONALE

Hallo Jörg, all, Joerg Schilling wrote in <20210825152559.ctbfz%sch...@schily.net>: |"Steffen Nurpmeso via austin-group-l at The Open Group" wrote: |> Now it has to be said, GNU make supports an immense number of |> special cases, pattern expansions etc., and this makes

Re: [1003.1(2016/18)/Issue7+TC2 0001437]: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONALE

Hello. Steffen Nurpmeso wrote in <20210821231356.n0d_i%stef...@sdaoden.eu>: |Paul Smith wrote in | : ||On Sat, 2021-08-21 at 02:24 +0200, Steffen Nurpmeso via austin-group-l ||at The Open Group wrote: ... ||If we really wanted to implement this the easiest possible way, it |

Re: [1003.1(2016/18)/Issue7+TC2 0001437]: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONALE

Steffen Nurpmeso wrote in <20210823213019.wtxaf%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20210821231356.n0d_i%stef...@sdaoden.eu>: ... |That striked me as another worthwile addition to POSIX make(1) |maybe, i always forget about this: the .PHONY target like ..

Re: [1003.1(2016/18)/Issue7+TC2 0001437]: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONALE

Paul Smith wrote in : |On Sat, 2021-08-21 at 02:24 +0200, Steffen Nurpmeso via austin-group-l |at The Open Group wrote: ... |Without knowing what you were trying to do all I can say is that the My only intent ever was to build the projects i am using, and so that the build process

Re: [1003.1(2016/18)/Issue7+TC2 0001437]: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONALE

Austin Group Bug Tracker wrote in : ... |https://austingroupbugs.net/view.php?id=1437 ... Unfortunately i cannot edit in Mantis. I wanted to add Words like quick-dirty and hack i think are really displaced for the nice and elegant solution that .WAIT: is. I remember doing GNU make

Re: utilities and write errors

Geoff Clare wrote in <20210701104540.GA4023@localhost>: |Robert Elz wrote, on 29 Jun 2021: ... |As above, this is all irrelevant to what the standard requires. | |As far as implementation detail goes, obviously if pwd uses stdio |buffering then in order to conform to the standard it must

Re: Fwd: Re: [1003.1(2016/18)/Issue7+TC2 0001436]: make: add "-j max_jobs" option to support simultaneous rule processing

Paul Smith wrote in : |On Sat, 2021-05-22 at 00:59 +0200, Steffen Nurpmeso via austin-group-l |at The Open Group wrote: |> Then stating something like "i am process X, and my parent is Y" |> etc. And the rest being up to the make(1) implementor as a quality |> of impleme

Fwd: Re: [1003.1(2016/18)/Issue7+TC2 0001436]: make: add "-j max_jobs" option to support simultaneous rule processing

Hello. It is kind of redundant, but i think i forward the message once again, now that my subscription is reestablished. --- Forwarded from Steffen Nurpmeso --- Date: Fri, 21 May 2021 17:57:20 +0200 From: Steffen Nurpmeso Subject: Re: [1003.1(2016/18)/Issue7+TC2 0001436]: make: add &qu

Fwd: Re: [1003.1(2016/18)/Issue7+TC2 0001436]: make: add "-j max_jobs" option to support simultaneous rule processing

--- Forwarded from Steffen Nurpmeso --- Date: Fri, 21 May 2021 17:57:20 +0200 From: Steffen Nurpmeso To: Austin Group Bug Tracker Subject: Re: [1003.1(2016/18)/Issue7+TC2 0001436]: make: add "-j max_jobs" option to support simultaneous rule processing Message-ID: <202105211557

Re: [1003.1(2008)/Issue 7 0000249]: Add standard support for $'...' in shell

Hello Robert. Robert Elz wrote in <12854.1612654...@jinx.noi.kre.to>: |Date:Sat, 06 Feb 2021 21:55:19 +0100 |From: Steffen Nurpmeso |Message-ID: <20210206205519.43rln%stef...@sdaoden.eu> | || Fiddling with bytes is something completely different.

Re: [1003.1(2008)/Issue 7 0000249]: Add standard support for $'...' in shell

Robert Elz wrote in <15313.1612563...@jinx.noi.kre.to>: |Date:Fri, 05 Feb 2021 21:54:52 +0100 |From: Steffen Nurpmeso |Message-ID: <20210205205452.7tbl2%stef...@sdaoden.eu> | | || Well .. if i recall correctly quoting inside of ${xYz} has been

Re: [1003.1(2008)/Issue 7 0000249]: Add standard support for $'...' in shell

Hello Robert. Robert Elz wrote in <14199.1612519...@jinx.noi.kre.to>: |Date:Thu, 04 Feb 2021 21:59:52 +0100 |From: Steffen Nurpmeso |Message-ID: <20210204205952.fw6wv%stef...@sdaoden.eu> | || Ok, of course, but let me disagree with the latter. B

Re: [1003.1(2008)/Issue 7 0000249]: Add standard support for $'...' in shell

Hello Robert. Robert Elz wrote in <9394.1612390...@jinx.noi.kre.to>: |Date:Wed, 03 Feb 2021 18:35:01 +0100 |From: Steffen Nurpmeso |Message-ID: <20210203173501.srcqv%stef...@sdaoden.eu> | || What else. Having \$ would be nice, | |It doesn't exi

Re: [1003.1(2008)/Issue 7 0000249]: Add standard support for $'...' in shell

Robert Elz wrote in <11054.1612115...@jinx.noi.kre.to>: |Date:Sun, 31 Jan 2021 06:48:25 + |From:"Austin Group Bug Tracker via austin-group-l at The \ |Open Group" |Message-ID: <79086278e43eeebd97f64b7f45613...@www.austingroupbugs.net> | || A NOTE has

Re: clarification needed: shell 'exec' + function (builtin, ???)

Hallo Jörg. Joerg Schilling wrote in <2020124507.zccfs%sch...@schily.net>: |"Steffen Nurpmeso via austin-group-l at The Open Group" wrote: |> Joerg Schilling wrote in |> <20201210004945.i3n8e%sch...@schily.net>: |>|Steffen Nurpmeso wrote: |>|&

Re: iconv() EILSEQ (was: clarification needed: shell 'exec' + function)

Geoff Clare wrote in <20201211100245.GA1627@localhost>: |Steffen Nurpmeso wrote, on 10 Dec 2020: |> |> While talking about iconv, i got closed glibc bug[1] as "resolved |> invalid", but wouldn't you all agree that in the following |> |> #include

Re: clarification needed: shell 'exec' + function (builtin, ???)

[I bring back austin-group-l, ok? Thorsten Glaser wrote in : |Steffen Nurpmeso dixit: | |> #include |> #include |> #include |> #include |> int main(void){ |> char inb[16], oub[16], *inbp, *oubp; |> iconv_t id; |> size_t inl, oul; |>

Re: mail encoding not-fun (was Re: clarification needed: shell 'exec' + function (builtin, ???))

Thorsten Glaser via austin-group-l at The Open Group wrote in : |Steffen Nurpmeso via austin-group-l at The Open Group dixit: | |>|This is because m4.opengroup.org runs qmail, the arsehole under the MTAs, |>|which auto-converted the mail from quoted-printable to 8bit, sending it |>

Re: clarification needed: shell 'exec' + function (builtin, ???)

Hallo Jörg, all, Joerg Schilling wrote in <20201210004945.i3n8e%sch...@schily.net>: |Steffen Nurpmeso wrote: |> this is an iconv(3)-related error that was fixed in later version |> of the mailer you use. The very error came up on the ML this |> year[1], basically you use LAT

Re: clarification needed: shell 'exec' + function (builtin, ???)

austin-group-l@opengroup.org wrote in : |Joerg Schilling via austin-group-l at The Open Group dixit: | |>here is where the original mail ended for me. Interesting that you did get | |This is because m4.opengroup.org runs qmail, the arsehole under the MTAs, |which auto-converted the mail

Re: clarification needed: shell 'exec' + function (builtin, ???)

e character "junkie", so to say. commit a9ec20d6 Author: Steffen Nurpmeso AuthorDate: 2020-04-23 17:29:57 +0200 Fix: "revert" [ab0cd3b8] from 2017-10-20.. (Claus Assmann).. (FIX iconv for main body part (since EVER!) (Doug McIlroy, Ra

Re: [1003.1(2004)/Issue 6 0001419]: Missing newline / indentation in .SCCS_GET default rule definition

Austin Group Bug Tracker wrote in <8d658048f7dbed7f9cd0b38c954c2...@austingroupbugs.net>: |The following issue has been SUBMITTED. |== |https://austingroupbugs.net/view.php?id=1419 ... |Apologies for not including the

  1   2   >