Re: Add -fail_on_alert option to exit with error on alerts

That's a fair point. However, I'd like to clarify a few things about how th=
e patch actually behaves (or intended to behave) and why these specific cas=
es might still warrant a non-zero exit code:

No immediate exit: The patch doesn't force an immediate or ungraceful shutd=
own. Lynx is allowed to finish its job and perform all necessary cleanups. =
The exit code is only bifurcated at the final statement based on whether an=
y alerts were triggered during the session (and this new command line optio=
n was given).

User continuity: The user can continue their session normally; the non-zero=
 exit code simply serves as a post-execution signal that something unexpect=
ed occurred.

Regarding the specific examples you mentioned:

src/GridText.c (truncated lines): Since this happens when inserting file co=
ntents into a TEXTAREA, the final form (of that TEXTAREA) submission might =
be incomplete. From an automation standpoint, it's ambiguous whether the us=
er's intent was fully satisfied. A non-zero exit code alerts the user that =
the output or submission might not be what they expected.

src/HTFWriter.c (execution disabled): If an external viewer or a permanent =
disk action is blocked, the session's final result differs from a 'successf=
ul' run where execution is enabled. An error code reflects this discrepancy=
.

src/LYLocal.c (file/directory collisions): This is similar to the noclobber=
 flag in POSIX shells. If a shell can't overwrite a file, it returns a non-=
zero status; Lynx following that same principle provides consistency for sc=
ripts.

src/LYMain.c (persistent cookies): Changes to cookie states can fundamental=
ly change the content Lynx shows or dumps. If a user relies on persistent c=
ookies for a specific workflow, a zero exit code could be misleading if tho=
se cookies weren't handled as expected.

src/LYMainLoop.c and src/LYOptions.c: I agree these are closer to 'warnings=
' than 'errors', as they mostly affect viewing mode or provide user guidanc=
e.

My original reasoning was inspired by HTTP status codes (4xx/5xx). My impre=
ssion was that for non-interactive sessions (like -source or -dump), almost=
 any alert suggests the process didn't go perfectly. We could try to classi=
fy alerts into 'errors' (non-zero) vs. 'warnings' (zero), but that might be=
 overkill for this implementation.

What do you think about maintaining the non-zero exit specifically for non-=
interactive modes?

On Friday, May 8th, 2026 at 1:38 AM, Thomas Dickey <dickey@invisible-island=
.net> wrote:

> On Thu, May 07, 2026 at 07:22:13PM +0000, WaitronCharm via Lynx-dev wrote=
:
> > Hello,
> >=20
> > I would like to propose the following patch for Lynx 2.9.0:
>=20
> It seems useful (thanks)=20
> =20
> > $ diff lynx2.9.0/src/HTAlert.c.orig lynx2.9.0/src/HTAlert.c
> > 62a63,66
> > >     if (LYFailOnAlert) {
> > >         alert_occurred =3D TRUE;
> > >     }
> > >=20
>=20
> hmm - most but not all calls to HTAlert are urgent.  I see some cases
> where you might not want to exit immediately:
>=20
> src/GridText.c:13908:=09=09HTAlert(gettext("Very long lines have been tru=
ncated!"));
> src/HTFWriter.c:990:=09    HTAlert(EXECUTION_DISABLED);
> src/LYLocal.c:354:=09HTAlert(gettext("The selected item is not a file or =
a directory!  Request ignored."));
> src/LYLocal.c:676:=09HTAlert(gettext("There is already a directory with t=
hat name!  Request ignored."));
> src/LYLocal.c:678:=09HTAlert(gettext("There is already a file with that n=
ame!  Request ignored."));
> src/LYMain.c:2438:=09    HTAlert(gettext("persistent cookies state will b=
e changed in next session only."));
> src/LYMainLoop.c:5399:=09HTAlert(SHIFT_VS_LINEWRAP);
> src/LYOptions.c:3399:=09=09    HTAlert(UA_PLEASE_USE_LYNX);
>=20
> >=20
> > $ diff lynx2.9.0/src/LYGlobalDefs.h.orig lynx2.9.0/src/LYGlobalDefs.h
> > 669a670,671
> > >     extern BOOLEAN LYFailOnAlert;
> > >     extern BOOLEAN alert_occurred;
> >=20
> > $ diff lynx2.9.0/src/LYMain.c.orig lynx2.9.0/src/LYMain.c
> > 731a732,734
> > > BOOLEAN LYFailOnAlert =3D FALSE;
> > > BOOLEAN alert_occurred =3D FALSE;
> > >=20
> > 919c922,927
> > <     exit(code);
> > ---
> > >=20
> > >     if (LYFailOnAlert && alert_occurred) {
> > >         exit(EXIT_FAILURE);
> > >     } else {
> > >         exit(code);
> > >     }
> > 3548a3557,3560
> > >    PARSE_SET(
> > >       "fail_on_alert",=094|SET_ARG,=09=09LYFailOnAlert,
> > >       "exit with error code if any alert is written"
> > >    ),
> >=20
> >=20
> > This patch introduces a new command-line option, -fail_on_alert, and a =
corresponding global flag LYFailOnAlert.
> >=20
> > The patch modifies HTAlert.c, LYGlobalDefs.h, and LYMain.c to track whe=
ther an alert has occurred during a session. If the -fail_on_alert flag is =
set and the alert_occurred boolean is triggered, Lynx will now exit with EX=
IT_FAILURE regardless of the standard exit code.
> >=20
> > Currently, detecting if a Lynx session encountered an alert (such as a =
403 Forbidden error) from a script is unnecessarily difficult. Without this=
 patch, one has to resort to convoluted shell piping and stderr scraping, f=
or example:
> >=20
> > set -e; set -o pipefail; ((lynx -stderr -source "$URL" 3>&1 1>&2 2>&3 3=
>&- | (grep -F -x 'Alert!: HTTP/1.0 403 Forbidden' || test $? -eq 1) | cmp =
-s - /dev/null) 3>&1 1>&2 2>&3 3>&-) > ...
> >=20
> > This approach is brittle and hard to maintain. Providing a built-in way=
 to fail on alerts aligns Lynx with similar functional options available in=
 other CLI tools like curl (--fail) and wget.
> >=20
> > I believe this is a useful addition for anyone using Lynx in automated =
environments or CI/CD pipelines.
> >=20
> >=20
>=20
> --=20
> Thomas E. Dickey <[email protected]>
> https://invisible-island.net
>