Re: [1003.1(2008)/Issue 7 0000518]: Allow make's "include" to include multiple files

[shwaresyst]

I can't reopen the bug to add a note, so like we did 1318 on top of 411, it 
probably should be reopened and discussed. Straightforward or not, what you put 
in is not what is marked as to be put in.
On Thursday, March 19, 2020 Geoff Clare  wrote:
shwaresyst  wrote, on 18 Mar 2020:
>
>> -- 
>>  (0004798) geoffclare (manager) - 2020-03-18 15:21
>>  https://austingroupbugs.net/view.php?id=518#c4798 
>> -- 
>> Note that when applying the changes from this bug, I noted that other
>> changes had been made to the Include Lines subsection since the 2008
>> edition, and therefore I did not follow the instruction to replace that
>> section with the new text, but instead identified the changes between the
>> 2008 edition text and the text given here and then applied equivalent
>> changes to the current text.
>> 
>> Some of the intervening changes were from bug
>> https://austingroupbugs.net/view.php?id=333 adding
>> -include ("silent includes"), but there were also some TC changes. 
> 
> Note 1190 does not include mention of -include, so imo a separate note should 
> be added showing what was committed.

I think a separate note with the details is unnecessary; the way to
merge the changes was obvious and straightforward. If it had not been,
then I would have reopened the bug.

If you really think such a note is needed then go ahead and add one.
(You can copy from the latest Base.pdf in the Issue8 branch in
gitlab.)

> As example, the text about "file not found" always invoking unspecified 
> behavior is not true for -include, it is now explicit these are ignored as 
> the specified behavior.

Sounds like you think a needed change was missed in bug 333, in which
case you should submit a new bug to propose that change.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Re: [1003.1(2008)/Issue 7 0000518]: Allow make's "include" to include multiple files

[Geoff Clare]

shwaresyst  wrote, on 18 Mar 2020:
>
>> -- 
>>  (0004798) geoffclare (manager) - 2020-03-18 15:21
>>  https://austingroupbugs.net/view.php?id=518#c4798 
>> -- 
>> Note that when applying the changes from this bug, I noted that other
>> changes had been made to the Include Lines subsection since the 2008
>> edition, and therefore I did not follow the instruction to replace that
>> section with the new text, but instead identified the changes between the
>> 2008 edition text and the text given here and then applied equivalent
>> changes to the current text.
>> 
>> Some of the intervening changes were from bug
>> https://austingroupbugs.net/view.php?id=333 adding
>> -include ("silent includes"), but there were also some TC changes. 
> 
> Note 1190 does not include mention of -include, so imo a separate note should 
> be added showing what was committed.

I think a separate note with the details is unnecessary; the way to
merge the changes was obvious and straightforward. If it had not been,
then I would have reopened the bug.

If you really think such a note is needed then go ahead and add one.
(You can copy from the latest Base.pdf in the Issue8 branch in
gitlab.)

> As example, the text about "file not found" always invoking unspecified 
> behavior is not true for -include, it is now explicit these are ignored as 
> the specified behavior.

Sounds like you think a needed change was missed in bug 333, in which
case you should submit a new bug to propose that change.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Re: XCU: 'exit' trap condition

[Dirk Fieldhouse]

On 16/03/20 14:37, Robert Elz wrote:

 Date:Sun, 15 Mar 2020 14:44:51 +
 From:Dirk Fieldhouse 
 Message-ID:  <55e0c45a-f13c-fa1d-db22-4c0a1b02d...@gmx.net>

...>
You need to read the whole standard to understand it, you cannot simply
read one section here and there and expect that to make sense.   It is
not a tutorial, not even an advanced user manual.


Except when it is: 

From the standard's Introduction:

"The intended audience for POSIX.1-2017 is all persons concerned with an
industry-wide standard operating
system based on the UNIX system. This includes at least four groups of
people:
- Persons buying hardware and software systems
- Persons managing companies that are deciding on future corporate
computing directions
- Persons implementing operating systems, and especially
- Persons developing applications where portability is an objective"

I have been in or advised or acted for all of these groups, especially
the final "especially" group. I read standards for breakfast, or at
least shortly afterwards. Compared with something like the ISO MPEG
series, POSIX is a light read. As someone who has written and maintained
plenty of shell scripts, the EXIT trap is one area that I hadn't really
exercised. A programmer who relied on 'man dash' or 'man ksh' could be
completely unaware of this feature; 'man bash' does mention it in a
simple description of 'exit' that doesn't attempt to deal with execution
environments. And certainly the DESCRIPTIONs of 'exit' and 'trap' are
the only sections of the standard that cover it. So it would be fair to
say that these sections provide the only good documentation of the feature.


   | -- which the standard contrasts with
   | "otherwise, the shell utility shall terminate...".

I have no idea what the "contrasts" is there.


You did once you'd read my response to Harald.


...

   | Should the standard say instead that the trap is executed "before the
   | shell exits from the current execution environment,"

It could say that, rather than "terminates", but the effect is the
same ...

If anything were to change, it would be better to say "before the
current execution environment terminates" - the reason for "terminate"
rather than "exit" is that this is the description of the exit command.
If we just say (in more words) "exit causes the shell to exit" it looks
kind of like a circular definition "x does x" - which is not very
illuminating.Hence "terminate" as the action for the exit command.


Definitely +1 for "before the current execution environment terminates"
or even "before the shell leaves the current execution environment", or
"before leaving the current execution environment".


...
it is really difficult to believe that any of this part can possibly
be misinterpreted.   And no, I don't believe that the wording that
you quoted in your reply to Harald is in any real way confusing.


The meaning ought to be obvious to someone who doesn't have a portfolio
of shell source codes and binaries to help resolve ambiguity. If I
hadn't already seen the results that you presented using such resources,
I would have gone with what I said the text "appears to require", and
I'd have tested that if were writing a test suite.


The issues that arose (the can of worms) are what is to happen when
a subshell execution environment (in a function) ends because of a
return command - all shells have the execution environment end
when that happens, but a couple don't run the exit trap.   Since currently
that return gives unspecified results, it would be plausible (if
a little bizarre) for those shells to claim that their unspecified
result is to exit without running an exit trap.


Sure, but to be sure of triggering an EXIT trap in a POSIX-conformant
shell the programmer could have used 'exit' instead of 'return'. Doctor,
when I hit my hand with the hammer it hurts: what should I do?


If we were to update the standard to specify that a return command
in a subshell in a function causes the subshell to exit, then we need
to be clear what happens with exit traps.


Which could be seen as a reason to let that whole aspect remain in limbo?

/df

--
London SW6
UK