GNU logs - #74788, boring messages

Message sent to bug-grep@HIDDEN:

Subject: bug#74788: Incorrect return value for SIGPIPE case
Resent-From: Sachin T <sachintu47@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-grep@HIDDEN
Resent-Date: Wed, 11 Dec 2024 14:01:01 +0000
Resent-Message-ID: <handler.74788.B.17339256445567 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 74788 <at> debbugs.gnu.org
MIME-Version: 1.0
From: Sachin T <sachintu47@HIDDEN>
Date: Wed, 11 Dec 2024 18:29:41 +0530
Message-ID: <CAEktRw2S8S-Cbzxon2Cyjbqkce0HTgC1G5W07cmKpBcUqY5sxw@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000006e64610628fe2c67"
Received-SPF: pass client-ip=2a00:1450:4864:20::635;
 envelope-from=sachintu47@HIDDEN; helo=mail-ej1-x635.google.com
X-Spam_score_int: -17
X-Spam_score: -1.8
X-Spam_bar: -
X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.1 (-)
X-Mailman-Approved-At: Wed, 11 Dec 2024 09:00:41 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

--0000000000006e64610628fe2c67
Content-Type: text/plain; charset="UTF-8"

Hi Grep Team,

I am running version 3.11 of grep on the IBM z/OS platform.

I am testing a scenario where grep's output is redirected to a closed pipe.
This was expected to raise a SIGPIPE signal and return an exit status of
141.

Upon inspecting the code, I noticed that the signal is raised by fclose,
which is executed as part of the *clean_up_stdout* handler registered with
atexit. However, on the z/OS platform, when a signal is raised during the
execution of an atexit-registered function, the exit status of the program
is determined by the main program's return status rather than the signal's
exit code. In this case, the exit status is 0, which does not reflect the
SIGPIPE signal.

Could you suggest the preferred solution for handling this situation on the
z/OS platform? Additionally, would it be possible for this behavior to be
addressed as a bug fix specific to the z/OS platform in a future release?

Looking forward to your response.

Regards,
Sachin

--0000000000006e64610628fe2c67
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hi Grep Team,</p><p>I am running version 3.11 of grep o=
n the IBM z/OS platform.</p><p>I am testing a scenario where grep&#39;s out=
put is redirected to a closed pipe. This was expected to raise a SIGPIPE si=
gnal and return an exit status of 141.</p><p>Upon inspecting the code, I no=
ticed that the signal is raised by <code>fclose</code>, which is executed a=
s part of the <b><code>clean_up_stdout</code></b> handler registered with <=
code>atexit</code>. However, on the z/OS platform, when a signal is raised =
during the execution of an <code>atexit</code>-registered function, the exi=
t status of the program is determined by the main program&#39;s return stat=
us rather than the signal&#39;s exit code. In this case, the exit status is=
 0, which does not reflect the SIGPIPE signal.</p><p>Could you suggest the =
preferred solution for handling this situation on the z/OS platform? Additi=
onally, would it be possible for this behavior to be addressed as a bug fix=
 specific to the z/OS platform in a future release?</p><p>Looking forward t=
o your response.</p><p>Regards,<br>Sachin</p></div>

--0000000000006e64610628fe2c67--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Sachin T <sachintu47@HIDDEN>
Subject: bug#74788: Acknowledgement (Incorrect return value for SIGPIPE case)
Message-ID: <handler.74788.B.17339256445567.ack <at> debbugs.gnu.org>
References: <CAEktRw2S8S-Cbzxon2Cyjbqkce0HTgC1G5W07cmKpBcUqY5sxw@HIDDEN>
X-Gnu-PR-Message: ack 74788
X-Gnu-PR-Package: grep
Reply-To: 74788 <at> debbugs.gnu.org
Date: Wed, 11 Dec 2024 14:01:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-grep@HIDDEN

If you wish to submit further information on this problem, please
send it to 74788 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
74788: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D74788
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-grep@HIDDEN:

Subject: bug#74788: Incorrect return value for SIGPIPE case
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-grep@HIDDEN
Resent-Date: Wed, 11 Dec 2024 17:55:02 +0000
Resent-Message-ID: <handler.74788.B74788.17339396975892 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Sachin T <sachintu47@HIDDEN>
Cc: 74788 <at> debbugs.gnu.org
Message-ID: <3a2f92db-c21d-4ce2-97e5-640b2fcc9f15@HIDDEN>
Date: Wed, 11 Dec 2024 09:54:47 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <CAEktRw2S8S-Cbzxon2Cyjbqkce0HTgC1G5W07cmKpBcUqY5sxw@HIDDEN>
Content-Language: en-US
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
In-Reply-To: <CAEktRw2S8S-Cbzxon2Cyjbqkce0HTgC1G5W07cmKpBcUqY5sxw@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On 2024-12-11 04:59, Sachin T wrote:
> Could you suggest the preferred solution for handling this situation on the
> z/OS platform?

Since this problem afflicts many applications (not just grep), the 
preferred solution would be to fix z/OS so that a process terminated by 
a signal has the exit status corresponding to the signal, even if the 
signal arrives during calls by 'exit' to functions registered by 
'atexit'. This is required by POSIX[1] and is what other systems do. Is 
that something you could start the ball rolling on? (I don't use z/OS 
and so cannot file bug reports for it.)

I don't see any straightforward change to 'grep' that would work around 
the z/OS problem. However, if you can think of a change, please let us know.

Also, could you please let us know the z/OS version so that I can 
document this portability problem in Gnulib? Thanks.

[1]: 
https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_04_03_01

Message sent to bug-grep@HIDDEN:

Subject: bug#74788: Incorrect return value for SIGPIPE case
Resent-From: Sachin T <sachintu47@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-grep@HIDDEN
Resent-Date: Thu, 12 Dec 2024 17:01:02 +0000
Resent-Message-ID: <handler.74788.B74788.173402281217838 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Paul Eggert <eggert@HIDDEN>
Cc: 74788 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <CAEktRw2S8S-Cbzxon2Cyjbqkce0HTgC1G5W07cmKpBcUqY5sxw@HIDDEN>
 <3a2f92db-c21d-4ce2-97e5-640b2fcc9f15@HIDDEN>
In-Reply-To: <3a2f92db-c21d-4ce2-97e5-640b2fcc9f15@HIDDEN>
From: Sachin T <sachintu47@HIDDEN>
Date: Thu, 12 Dec 2024 22:28:55 +0530
Message-ID: <CAEktRw0pGqSzsLVwi_jJjXPjkcfey=WYMh_aJTrV1wSYyHcSTQ@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000dad33a062915a1e1"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--000000000000dad33a062915a1e1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Paul,

Thank you for your response.

This issue has been observed in z/OS version 2.5 and later.

I am currently discussing it with the z/OS platform team.
As a workaround, we installed a signal handler for SIGPIPE that invokes
_exit(141).
Once the final changes are determined, I=E2=80=99ll propose a fix upstream.

Best regards,
Sachin



On Wed, Dec 11, 2024 at 11:24=E2=80=AFPM Paul Eggert <eggert@HIDDEN> w=
rote:

> On 2024-12-11 04:59, Sachin T wrote:
> > Could you suggest the preferred solution for handling this situation on
> the
> > z/OS platform?
>
> Since this problem afflicts many applications (not just grep), the
> preferred solution would be to fix z/OS so that a process terminated by
> a signal has the exit status corresponding to the signal, even if the
> signal arrives during calls by 'exit' to functions registered by
> 'atexit'. This is required by POSIX[1] and is what other systems do. Is
> that something you could start the ball rolling on? (I don't use z/OS
> and so cannot file bug reports for it.)
>
> I don't see any straightforward change to 'grep' that would work around
> the z/OS problem. However, if you can think of a change, please let us
> know.
>
> Also, could you please let us know the z/OS version so that I can
> document this portability problem in Gnulib? Thanks.
>
> [1]:
>
> https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html=
#tag_16_04_03_01
>

--000000000000dad33a062915a1e1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hi Paul,</p><p>Thank you for your response.</p><p>This =
issue has been observed in z/OS version 2.5 and later.=C2=A0</p><p>I am cur=
rently discussing it with the z/OS platform team.<br>As a workaround, we in=
stalled a signal handler for SIGPIPE that invokes _exit(141).<br>Once the f=
inal changes are determined, I=E2=80=99ll propose a fix upstream.</p><p>Bes=
t regards,<br>Sachin</p><div><br></div><div><br></div><br><div class=3D"gma=
il_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On We=
d, Dec 11, 2024 at 11:24=E2=80=AFPM Paul Eggert &lt;<a href=3D"mailto:egger=
t@HIDDEN">eggert@HIDDEN</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On 2024-12-11 04:59, Sachin T wrote:<br>
&gt; Could you suggest the preferred solution for handling this situation o=
n the<br>
&gt; z/OS platform?<br>
<br>
Since this problem afflicts many applications (not just grep), the <br>
preferred solution would be to fix z/OS so that a process terminated by <br=
>
a signal has the exit status corresponding to the signal, even if the <br>
signal arrives during calls by &#39;exit&#39; to functions registered by <b=
r>
&#39;atexit&#39;. This is required by POSIX[1] and is what other systems do=
. Is <br>
that something you could start the ball rolling on? (I don&#39;t use z/OS <=
br>
and so cannot file bug reports for it.)<br>
<br>
I don&#39;t see any straightforward change to &#39;grep&#39; that would wor=
k around <br>
the z/OS problem. However, if you can think of a change, please let us know=
.<br>
<br>
Also, could you please let us know the z/OS version so that I can <br>
document this portability problem in Gnulib? Thanks.<br>
<br>
[1]: <br>
<a href=3D"https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_ch=
ap02.html#tag_16_04_03_01" rel=3D"noreferrer" target=3D"_blank">https://pub=
s.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_04_03=
_01</a><br>
</blockquote></div></div>

--000000000000dad33a062915a1e1--

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.