[1003.1(2008)/Issue 7 0001079]: focus on bc being an arithmetic language
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1079 == Reported By:tobiasm Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 1079 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Tobias Martens Organization: User Reference: Section:bc Page Number:- Line Number:- Interp Status: --- Final Accepted Text: == Date Submitted: 2016-10-05 23:40 UTC Last Modified: 2016-10-07 22:44 UTC == Summary:focus on bc being an arithmetic language == -- (0003403) tobiasm (reporter) - 2016-10-07 22:44 http://austingroupbugs.net/view.php?id=1079#c3403 -- Exactly, echo "$var^2" will return -4. My suggestion does not take care of this, because there is no way of implementing common arithmetic and getting rid of this issue. The user still needs to know that shell substitutes the variable before passing the whole string (no special knowledge about bc's behaviour required however, which is the great plus). One needs to know the same thing about shell right now (see the other example), so you're right in this point there would be no improvement. "3-$var" was mainly used to show that -- will occur when obviously meant as subtraction. Don't get me wrong, this is no bug report or something similar. bc is ok right now even without change, but I would not oppose improvements for the sake of persistence. 35 years ago computers weren't widespread enough for a common understanding (of how arithmetic user input should be calculated) to become explicit. As I hopefully pointed out, this has changed. So I propose bc to be changed. Issue History Date ModifiedUsername FieldChange == 2016-10-05 23:40 tobiasmNew Issue 2016-10-05 23:40 tobiasmStatus New => Under Review 2016-10-05 23:40 tobiasmAssigned To => ajosey 2016-10-05 23:40 tobiasmName => Tobias Martens 2016-10-05 23:40 tobiasmSection => bc 2016-10-05 23:40 tobiasmPage Number => - 2016-10-05 23:40 tobiasmLine Number => - 2016-10-06 07:41 Vincent LefevreNote Added: 0003395 2016-10-06 07:41 Vincent LefevreNote Edited: 0003395 2016-10-06 07:42 Vincent LefevreNote Edited: 0003395 2016-10-06 08:02 Vincent LefevreNote Edited: 0003395 2016-10-06 08:09 Vincent LefevreNote Added: 0003396 2016-10-06 10:19 stephane Note Added: 0003397 2016-10-06 10:21 stephane Note Edited: 0003397 2016-10-06 10:39 stephane Note Edited: 0003397 2016-10-06 23:05 tobiasmNote Added: 0003398 2016-10-07 00:06 Vincent LefevreNote Added: 0003399 2016-10-07 00:15 Vincent LefevreNote Added: 0003400 2016-10-07 02:14 Don Cragun Note Added: 0003401 2016-10-07 22:44 tobiasmNote Added: 0003403 ==
two things from "Token Recognition" section of the Shell Standard, don't seem to make sense - please comment
Hello, In the Shell Standard (current version 2016), section on Token Recognition, it says (...) shell shall break its input into tokens by applying the first applicable rule below to the next character in its input. and The token shall be from the current position in the input (...) Both of these do not make sense to me. Please comment if you agree or not. 1. "first applicable rule" seems incorrect : if rule 3, 4, or 5 is the first applicable rule, and the current character should be the start of a token, these rules do not say to start a token. In this case we should (I think) follow subsequent rules until we find a rule that says to start a new token. 2. "shall be from the current position in the input" seems to imply, that we start new tokens much too often. If you agree, I can post a bug with a suggested fix. Thank you Mark
Re: Availability of the 2016 edition of the specification
Hello, On Fri, 30 Sep 2016 12:11:33 +0100, Andrew Josey wrote: > We're pleased to announce the availability of the 2016 edition of The > Open Group Base Specifications Issue 7/ IEEE Std 1003.1. The 2016 edition > incorporates Technical Corrigendum 1 and Technical Corrigendum 2. > > The document is available in pdf and html - the html being freely available, > and the pdf restricted to members only as per the agreement with IEEE for > the joint development. > [...] > For a limited time, Austin Group members can obtain a copy of the > pdf from the Austin Group web site at > > https://www.opengroup.org/austin/restricted/ In C165.pdf, the link to fstatat() in the description of lstat() at line number 43130 points to the description of fstat() (line number 32700) and not fstatat() (line number 32783). -- Thomas Mueller
[Online Pubs 0001080]: Misplaced "Chapter 7, Locale"
The following issue has been SUBMITTED. == http://austingroupbugs.net/view.php?id=1080 == Reported By:dannyniu Assigned To: == Project:Online Pubs Issue ID: 1080 Category: Rationale Type: Error Severity: Editorial Priority: normal Status: New Name: DannyNiu/NJF Organization: User Reference: URL: http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap04.html Section:C.4.3 Exclusion of Utilities == Date Submitted: 2016-10-07 09:06 UTC Last Modified: 2016-10-07 09:06 UTC == Summary:Misplaced "Chapter 7, Locale" Description: As of 2016-10-07, the HTML version of the latest 2016 edition seem to be generated with some wrong macros (I presume we're using troff to make publications), as there are many instances of confusing references to the Locale chapter, where as in the PDF version, they seem to refer to the old IEEE POSIX 1992. Desired Action: A republish. == Issue History Date ModifiedUsername FieldChange == 2016-10-07 09:06 dannyniu New Issue 2016-10-07 09:06 dannyniu Name => DannyNiu/NJF 2016-10-07 09:06 dannyniu URL => http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap04.html 2016-10-07 09:06 dannyniu Section => C.4.3 Exclusion of Utilities ==
Problem with troff again?
I just downloaded the zipped version of the 2016 edition, and there seems to be quite a lot of misplaced "Chapter 7, Locale" in the rationales volume as far as I saw.
