Re: shell variables and attributes
On Thu, May 26, 2022, at 10:39 PM, Christoph Anton Mitterer via austin-group-l at The Open Group wrote: > 2) The draft 2.1 says on page 2398 line 77766: > >The unset utility shall unset each variable or function definition >specified by name that does not >have the readonly attribute and remove any attributes other than >readonly that have been given to >name (see Section 2.14 export and readonly). > > To me that behaviour would seem quite odd ... and it doesn't match the > behaviour of at least bash and dash. > > > What the text currently says is: > `unset` unsets each var/function that is not readonly... > AND (with no further restriction) > removes all attributes other then readonly > (that is: whether or not the var is readonly). > > So that means: >export var=foo >readonly var >unset -v var > as per description, should leave var set (with value "foo"), should > leave the readonly attribute... but should remove the export attribute. Seems that ksh93u+, mksh R59c, and yash 2.52 don't follow this interpretation either. > 3) It's IMO not fully clear whether a readonly variable is allowed to > have other attributes added (or cleared - see (2)). > > On page 2376, line 76926 says: >The values of variables with the readonly attribute cannot be changed >by subsequent assignment or use of the export, getopts, readonly, or >read utilities, nor can those variables be unset by the unset utility. > > and in fact, it seems to work with bash/dash to first mark a var > readonly (whether it's set or not) and then mark it as export. > > But still, given that the other way round seems to not work... it could > IMO deserve further clarification... and maybe emphasis, too, as > allowing to add further attributes is actually a bit contradicting the > read-only property, as it may change the behaviour. At a minimum, bash 5.1.16, ksh93u+, mksh R59c, dash 0.5.11.5, and yash 2.52 already allow exporting an existing readonly variable. If the standard ought to clarify anything, it's that the results of this action are unspecified. -- vq
shell variables and attributes
Hey. I noted the following... 1) First, my understanding is, that a variable needs not to be set, but can still have attributes (e.g. export/readonly) set for it. Not sure whether I just didn't find it, but I think this behaviour is not specifically mentioned somewhere, or is it? 2) The draft 2.1 says on page 2398 line 77766: The unset utility shall unset each variable or function definition specified by name that does not have the readonly attribute and remove any attributes other than readonly that have been given to name (see Section 2.14 export and readonly). To me that behaviour would seem quite odd ... and it doesn't match the behaviour of at least bash and dash. What the text currently says is: `unset` unsets each var/function that is not readonly... AND (with no further restriction) removes all attributes other then readonly (that is: whether or not the var is readonly). So that means: export var=foo readonly var unset -v var as per description, should leave var set (with value "foo"), should leave the readonly attribute... but should remove the export attribute. 3) It's IMO not fully clear whether a readonly variable is allowed to have other attributes added (or cleared - see (2)). On page 2376, line 76926 says: The values of variables with the readonly attribute cannot be changed by subsequent assignment or use of the export, getopts, readonly, or read utilities, nor can those variables be unset by the unset utility. and in fact, it seems to work with bash/dash to first mark a var readonly (whether it's set or not) and then mark it as export. But still, given that the other way round seems to not work... it could IMO deserve further clarification... and maybe emphasis, too, as allowing to add further attributes is actually a bit contradicting the read-only property, as it may change the behaviour. 4) It may not be fully clear, whether unsetting a non-set variable is intended to just clear it's attributes: Line 77766 says: The unset utility shall unset each variable or function definition specified by name that does not have the readonly attribute and remove any attributes other than readonly that have been given to name (see Section 2.14 export and readonly). This could mean that... but OTOH, line 4 says: Unsetting a variable or function that was not previously set shall not be considered an error and does not cause the shell to abort. which rather makes it sound as if this would *just* not be considered an error... (but otherwise have no effect - while in fact it clears the flags). Cheers, Chris.
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 a uselocale() object. Just think about the |> scanf() that is used so often, or strtol(): you cannot even |> convert a number by standard means. | |You are mixing up uselocale() and newlocale(). | |The _l() functions and uselocale() are different ways to make use |of a locale object obtained from newlocale(). | |If there is no _l() function, you can pass the locale object to |uselocale() to set a thread-local current locale which must then |be used by functions that use the current locale, such as scanf() |and strtol(). These functions only use the "global locale" (set |by setlocale()) if there is no thread-local current locale set. That is true. (But i think this is one more occasion where Stroustrup's "a C++ may even be faster, because problems can be solved differently", cited more or less correctly, C++ 98, turns out to be correct.) |-- |Geoff Clare |The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England --End of <20220526085434.GA19184@localhost> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
[1003.1(2013)/Issue7+TC1 0000922]: Implementations should be allowed to change/remove implementation-defined environment variables
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=922 == Reported By:Florian Weimer Assigned To: == Project:1003.1(2013)/Issue7+TC1 Issue ID: 922 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Florian Weimer Organization: Red Hat User Reference: Section:8.1 Environment Variable Definition Page Number: http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html Line Number:141 Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=922#c5844 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2015-02-11 10:08 UTC Last Modified: 2022-05-26 15:18 UTC == Summary:Implementations should be allowed to change/remove implementation-defined environment variables == Issue History Date ModifiedUsername FieldChange == 2015-02-11 10:08 Florian Weimer New Issue 2015-02-11 10:08 Florian Weimer Name => Florian Weimer 2015-02-11 10:08 Florian Weimer Organization => Red Hat 2015-02-11 10:08 Florian Weimer Section => 8.1 Environment Variable Definition 2015-02-11 10:08 Florian Weimer Page Number => http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html 2015-02-11 10:08 Florian Weimer Line Number => 141 2015-02-11 10:08 Florian Weimer Issue Monitored: Florian Weimer 2015-02-13 18:45 dalias Note Added: 0002546 2015-04-30 15:39 eblake Note Added: 0002643 2015-04-30 16:10 eblake Note Added: 0002644 2015-09-04 18:15 philip-guentherNote Added: 0002810 2015-09-04 18:34 dalias Note Added: 0002811 2022-05-26 15:17 geoffclare Note Added: 0005844 2022-05-26 15:18 geoffclare Interp Status => --- 2022-05-26 15:18 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=922#c5844 2022-05-26 15:18 geoffclare Status New => Resolved 2022-05-26 15:18 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2013)/Issue7+TC1 0000922]: Implementations should be allowed to change/remove implementation-defined environment variables
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=922 == Reported By:Florian Weimer Assigned To: == Project:1003.1(2013)/Issue7+TC1 Issue ID: 922 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Florian Weimer Organization: Red Hat User Reference: Section:8.1 Environment Variable Definition Page Number: http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html Line Number:141 Interp Status: --- Final Accepted Text: == Date Submitted: 2015-02-11 10:08 UTC Last Modified: 2022-05-26 15:17 UTC == Summary:Implementations should be allowed to change/remove implementation-defined environment variables == -- (0005844) geoffclare (manager) - 2022-05-26 15:17 https://austingroupbugs.net/view.php?id=922#c5844 -- Page and line numbers are for Issue 8 draft 2.1 After page 156 line 5406 section 8.1 Environment Variable Definition, add:Implementations may ignore some environment variables at the point of use for security reasons, for example in programs whose real and effective user IDs or real and effective group IDs were not equal at program startup. The behavior shall be as if the implementation obtains the values for these environment variables using secure_getenv() instead of getenv() (see [xref to getenv()]); they shall not be removed from the environment of affected processes and shall be inherited as required by this standard. After page 358 line 12432 section , add: [CX]char *secure_getenv(const char *);[/CX] On page 501 line 17742 section 2.9.1, change:the getenv() function andto:the getenv( ) and secure_getenv functions and On page 774 line 26454 section exec, and page 3691 line 127760 section E.1, change:getenv()to:getenv( ), secure_getenv On page 1022 line 35036 section getenv(), change:getenvto:getenv, secure_getenv After page 1022 line 35039 section getenv(), add: [CX]char *secure_getenv(const char *name);[/CX] After page 1022 line 35054 section getenv(), add:[CX]The secure_getenv() function shall be equivalent to getenv(), except that it shall return a null pointer if the calling process does not meet all of the following security criteria: The effective user ID and real user ID of the calling process were equal during program startup. The effective group ID and real group ID of the calling process were equal during program startup. Additional implementation-defined security criteria. [/CX] After page 1022 line 35058 section getenv(), add:[CX]Upon successful completion, secure_getenv() shall return a pointer to a string containing the value for the specified name. If the specified name cannot be found in the environment of the calling process, or the calling process does not meet the security criteria listed in DESCRIPTION, a null pointer shall be returned. After page 1790, sched_yield() entry, insert secure_getenv() pointer page to getenv() After page 3457 line 118185 section A.8.1, add:Some historical implementations removed certain environment variables during program startup when security criteria were not met, instead of just ignoring them at the point of use. The standard developers decided not to allow this behavior because if a process drops all privileges and sets its effective user and group IDs to be the same as its real user and group IDs before executing a program or utility, the behavior should be the same as if the process had originally met the security criteria. Issue History Date ModifiedUsername FieldChange == 2015-02-11 10:08 Florian Weimer New Issue 2015-02-11 10:08 Florian Weimer Name => Florian Weimer 2015-02-11 10:08 Florian Weimer Organization => Red Hat 2015-02-11 10:08 Florian Weimer Section => 8.1 Environment Variable Definition 2015-02-11 10:08 Florian Weimer Page Number => http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html 2015-02-11
Re: POSIX gettext(): changes to the .mo file
Robert Elz wrote: > I would also guess that a side effect of the way it was described > is that changes to the on disc backing store (the .mo file, or > whatever) will not be detected while the application remains > running, and that aside from execing itself to restart clean > there is no way for an application designed to run forever > to ever see updated data. It is true that for some use-cases, it would be beneficial if the gettext() implementation would detect changes to the .mo file and even provide a notification system about which translations have changed. However, this has not been implemented in GNU gettext in more than 25 years. Therefore, IMO, this is not something that POSIX needs to address. Bruno
Minutes of the 23rd May 2022 Teleconference
All Enclosed are the minutes of the Monday meeting this week regards Andrew --- Minutes of the 23rd May 2022 TeleconferenceAustin-1224 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 26th May 2022 Attendees: Don Cragun, IEEE PASC OR Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Mark Ziegast, SHware Systems Dev. Eric Blake, Red Hat, The Open Group OR Geoff Clare, The Open Group Andrew Josey, The Open Group Tom Thompson, IEEE (partial) Eric Ackermann, HPI, University of Potsdam * General news This was a call dedicated to gettext discussions. General bugs are discussed on Thursdays. AI: Andrew to discuss with Geoff gettext approvals and publication in The Open Group (if that was necessary prior to a merge). Closed. The recommendation is that we do need to progress gettext and a couple of interfaces through The Open Group prior to integarting to Draft 3. The following action are still open. AI: Andrew to remind the ISO Secretariat of our plan to submit draft 3 for ISO balloting. * Outstanding actions None. * Current Business Bug 1122: POSIX should include gettext() and friends We continued discussions on the gettext draft. The gettext draft in the etherpad is at https://posix.rhansen.org/p/gettext_draft (most current) Geoff took an action to email responses to items discussed to Bruno Haible. (Completed after meeting) Next Steps -- The next calls are on: Thu 2022-05-26 (general bugs) Thu 2022-05-30 (gettext) NO Meeting US Memorial Day Thu 2022-06-02 (general bugs) NO Meeting UK Spring Bank Holiday Thu 2022-06-06 (gettext) Logistics TBD Apologies in Advance: Nick Stoughton 2022-06-06 and 2022-06-09 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
[Issue 8 drafts 0001577]: dup3 flags usage not entirely specified
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1577 == Reported By:shware_systems Assigned To: == Project:Issue 8 drafts Issue ID: 1577 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: Applied Name: Mark Ziegast Organization: SHware Systems Dev. User Reference: Section:dup3() Page Number:742 Line Number:25487-91 Final Accepted Text:https://austingroupbugs.net/view.php?id=1577#c5827 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2022-04-07 16:20 UTC Last Modified: 2022-05-26 10:37 UTC == Summary:dup3 flags usage not entirely specified == Relationships ID Summary -- related to 0001557 Better wording to describe FD_CLOEXEC. related to 411 adding atomic FD_CLOEXEC support == Issue History Date ModifiedUsername FieldChange == 2022-04-07 16:20 shware_systems New Issue 2022-04-07 16:20 shware_systems Name => Mark Ziegast 2022-04-07 16:20 shware_systems Organization => SHware Systems Dev. 2022-04-07 16:20 shware_systems Section => dup3() 2022-04-07 16:20 shware_systems Page Number => 742 2022-04-07 16:20 shware_systems Line Number => 25487-91 2022-04-07 18:31 kreNote Added: 0005786 2022-04-28 15:50 Don Cragun Relationship added related to 0001557 2022-04-28 16:19 geoffclare Relationship added related to 411 2022-04-28 16:36 geoffclare Note Added: 0005827 2022-04-28 16:37 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1577#c5827 2022-04-28 16:37 geoffclare Status New => Resolved 2022-04-28 16:37 geoffclare Resolution Open => Accepted As Marked 2022-04-28 16:37 geoffclare Tag Attached: issue8 2022-05-26 10:37 geoffclare Status Resolved => Applied ==
[Issue 8 drafts 0001550]: clarifications/ambiguities in the description of context addresses and their delimiters for sed
The following issue has a resolution that has been APPLIED. == 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: Applied Name: Christoph Anton Mitterer Organization: User Reference: Section:Utilities, sed Page Number:3132, ff. (in the draft) Line Number:see below Final Accepted Text:https://austingroupbugs.net/view.php?id=1550#c5816 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2022-01-14 05:32 UTC Last Modified: 2022-05-26 10:34 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... related to 0001556 clarify meaning of \n used in a bracket... related to 0001578 sed y-command: error in description abo... == 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 2022-03-26 00:34 calestyo Note Edited: 0005767 2022-03-31 16:00 nick Relationship added related to 0001556 2022-04-02 01:53 calestyo Note Added: 0005771 2022-04-02 02:30 calestyo Note Added: 0005772 2022-04-02 09:37 kreNote Added: 0005775 2022-04-02 19:47 calestyo Note Added: 0005777 2022-04-08 09:20 geoffclare Note Added: 0005790 2022-04-17 23:51 calestyo Note Added: 0005809 2022-04-22 08:29 geoffclare Note Added: 0005816 2022-04-28 15:12 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1550#c5816 2022-04-28 15:12 geoffclare Status New => Resolved 2022-04-28 15:12 geoffclare Resolution Open => Accepted As Marked 2022-04-28 15:13 geoffclare Tag Attached: issue8 2022-05-05 15:00 nick Relationship added related to 0001578 2022-05-26 10:34 geoffclare Status Resolved => Applied ==
[Issue 8 drafts 0001580]: add a hint that env vars with invalid names might be passed on to the environments of programs/utilities
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1580 == Reported By:calestyo Assigned To: == Project:Issue 8 drafts Issue ID: 1580 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Applied Name: Christoph Anton Mitterer Organization: User Reference: Section:2.12 Shell Execution Environment Page Number:2351 Line Number:76080 Final Accepted Text: Resolution: Accepted Fixed in Version: == Date Submitted: 2022-04-24 23:49 UTC Last Modified: 2022-05-26 10:22 UTC == Summary:add a hint that env vars with invalid names might be passed on to the environments of programs/utilities == Issue History Date ModifiedUsername FieldChange == 2022-04-24 23:49 calestyo New Issue 2022-04-24 23:49 calestyo Name => Christoph Anton Mitterer 2022-04-24 23:49 calestyo Section => 2.12 Shell Execution Environment 2022-04-24 23:49 calestyo Page Number => 2351 2022-04-24 23:49 calestyo Line Number => 76080 2022-05-05 15:33 Don Cragun Status New => Resolved 2022-05-05 15:33 Don Cragun Resolution Open => Accepted 2022-05-05 15:33 Don Cragun Tag Attached: tc3-2008 2022-05-26 10:22 geoffclare Status Resolved => Applied ==
[Issue 8 drafts 0001579]: some minor improvementes to BRE Expression Anchoring
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1579 == Reported By:calestyo Assigned To: == Project:Issue 8 drafts Issue ID: 1579 Category: Base Definitions and Headers Type: Enhancement Request Severity: Editorial Priority: normal Status: Applied Name: Christoph Anton Mitterer Organization: User Reference: Section:9.3.8 BRE Expression Anchoring Page Number:172 Line Number:6015 to 6027 Final Accepted Text: Resolution: Accepted Fixed in Version: == Date Submitted: 2022-04-18 00:27 UTC Last Modified: 2022-05-26 10:20 UTC == Summary:some minor improvementes to BRE Expression Anchoring == Issue History Date ModifiedUsername FieldChange == 2022-04-18 00:27 calestyo New Issue 2022-04-18 00:27 calestyo Name => Christoph Anton Mitterer 2022-04-18 00:27 calestyo Section => 9.3.8 BRE Expression Anchoring 2022-04-18 00:27 calestyo Page Number => 172 2022-04-18 00:27 calestyo Line Number => 6015 to 6027 2022-05-05 15:24 geoffclare Status New => Resolved 2022-05-05 15:24 geoffclare Resolution Open => Accepted 2022-05-05 15:24 geoffclare Tag Attached: tc3-2008 2022-05-26 10:20 geoffclare Status Resolved => Applied ==
[Issue 8 drafts 0001578]: sed y-command: error in description about the number of characters in string1 and string2
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1578 == Reported By:calestyo Assigned To: == Project:Issue 8 drafts Issue ID: 1578 Category: Base Definitions and Headers Type: Error Severity: Editorial Priority: normal Status: Applied Name: Christoph Anton Mitterer Organization: User Reference: Section:Utilities, sed Page Number:3138 Line Number:106249 Final Accepted Text:See https://austingroupbugs.net/view.php?id=1578#c5828. Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2022-04-17 01:40 UTC Last Modified: 2022-05-26 10:17 UTC == Summary:sed y-command: error in description about the number of characters in string1 and string2 == Relationships ID Summary -- related to 0001550 clarifications/ambiguities in the descr... child of0001551 sed: ambiguities in the how BREs/EREs a... == Issue History Date ModifiedUsername FieldChange == 2022-04-17 01:40 calestyo New Issue 2022-04-17 01:40 calestyo Name => Christoph Anton Mitterer 2022-04-17 01:40 calestyo Section => Utilities, sed 2022-04-17 01:40 calestyo Page Number => 3138 2022-04-17 01:40 calestyo Line Number => 106249 2022-05-05 14:59 nick Relationship added child of 0001551 2022-05-05 15:00 nick Relationship added related to 0001550 2022-05-05 15:11 Don Cragun Note Added: 0005828 2022-05-05 15:12 Don Cragun Final Accepted Text => See https://austingroupbugs.net/view.php?id=1578#c5828. 2022-05-05 15:12 Don Cragun Status New => Resolved 2022-05-05 15:12 Don Cragun Resolution Open => Accepted As Marked 2022-05-05 15:13 Don Cragun Tag Attached: tc3-2008 2022-05-26 10:17 geoffclare Status Resolved => Applied ==
[Issue 8 drafts 0001576]: The description of the pipe() function doesn't state which end of the pipe is placed in fildes[0] and fildes[1].
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1576 == Reported By:Don Cragun Assigned To: == Project:Issue 8 drafts Issue ID: 1576 Category: System Interfaces Type: Omission Severity: Editorial Priority: normal Status: Applied Name: Don Cragun Organization: User Reference: Section:pipe() Page Number:1413 Line Number:47100-47102 Final Accepted Text: Resolution: Accepted Fixed in Version: == Date Submitted: 2022-04-07 15:33 UTC Last Modified: 2022-05-26 10:15 UTC == Summary:The description of the pipe() function doesn't state which end of the pipe is placed in fildes[0] and fildes[1]. == Issue History Date ModifiedUsername FieldChange == 2022-04-07 15:33 Don Cragun New Issue 2022-04-07 15:33 Don Cragun Name => Don Cragun 2022-04-07 15:33 Don Cragun Section => open() 2022-04-07 15:33 Don Cragun Page Number => 1413 2022-04-07 15:33 Don Cragun Line Number => 47100-47102 2022-04-28 15:37 geoffclare Status New => Resolved 2022-04-28 15:37 geoffclare Resolution Open => Accepted 2022-04-28 15:37 geoffclare Tag Attached: tc3-2008 2022-05-26 10:15 geoffclare Section open() => pipe() 2022-05-26 10:15 geoffclare Status Resolved => Applied ==
[Issue 8 drafts 0001562]: printf utility: clarify what is (byte) string an what is character string
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1562 == Reported By:calestyo Assigned To: == Project:Issue 8 drafts Issue ID: 1562 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Applied Name: Christoph Anton Mitterer Organization: User Reference: Section:Utilities, printf Page Number:3084 Line Number:104239 Final Accepted Text:https://austingroupbugs.net/view.php?id=1562#c5818 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2022-02-13 00:28 UTC Last Modified: 2022-05-26 10:13 UTC == Summary:printf utility: clarify what is (byte) string an what is character string == Relationships ID Summary -- related to 0001561 clarify what kind of data shell variabl... == Issue History Date ModifiedUsername FieldChange == 2022-02-13 00:28 calestyo New Issue 2022-02-13 00:28 calestyo Name => Christoph Anton Mitterer 2022-02-13 00:28 calestyo Section => Utilities, printf 2022-02-13 00:28 calestyo Page Number => 3084 2022-02-13 00:28 calestyo Line Number => 104239 2022-02-13 01:08 Don Cragun Note Added: 0005673 2022-04-07 16:30 geoffclare Relationship added related to 0001561 2022-04-08 14:48 geoffclare Note Added: 0005792 2022-04-08 14:49 geoffclare Note Edited: 0005792 2022-04-11 08:58 geoffclare Note Added: 0005793 2022-04-15 02:55 calestyo Note Added: 0005806 2022-04-22 15:18 geoffclare Note Added: 0005818 2022-04-22 15:19 geoffclare Note Edited: 0005818 2022-04-28 15:31 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1562#c5818 2022-04-28 15:31 geoffclare Status New => Resolved 2022-04-28 15:31 geoffclare Resolution Open => Accepted As Marked 2022-04-28 15:32 geoffclare Tag Attached: tc3-2008 2022-05-26 10:13 geoffclare Status Resolved => Applied ==
Re: POSIX bind_textdomain_codeset(): some invalid codeset arguments
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 a uselocale() object. Just think about the > scanf() that is used so often, or strtol(): you cannot even > convert a number by standard means. You are mixing up uselocale() and newlocale(). The _l() functions and uselocale() are different ways to make use of a locale object obtained from newlocale(). If there is no _l() function, you can pass the locale object to uselocale() to set a thread-local current locale which must then be used by functions that use the current locale, such as scanf() and strtol(). These functions only use the "global locale" (set by setlocale()) if there is no thread-local current locale set. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
