Thanks for the feedback on the proposed -fail_on_alert option.

Following up on our recent thread, I would like to formally suggest integrating 
this patch into the next official Lynx build.

Having this option natively supported would be highly beneficial for automated 
environments, CI/CD pipelines, and scripting, where users need Lynx to cleanly 
exit with an error code the moment an alert is triggered. Merging this upstream 
would allow the wider community to benefit from more robust error handling 
without anyone having to maintain individual forks or local patches.

Please let me know if any further adjustments, cleanup, or documentation 
updates are needed to make the patch ready for inclusion in the official source.


Thank you.

On Friday, May 8th, 2026 at 1:38 AM, Thomas Dickey 
<[email protected]> wrote:

> On Thu, May 07, 2026 at 07:22:13PM +0000, WaitronCharm via Lynx-dev wrote:
> > Hello,
> > 
> > I would like to propose the following patch for Lynx 2.9.0:
> 
> It seems useful (thanks) 
>  
> > $ diff lynx2.9.0/src/HTAlert.c.orig lynx2.9.0/src/HTAlert.c
> > 62a63,66
> > >     if (LYFailOnAlert) {
> > >         alert_occurred = TRUE;
> > >     }
> > > 
> 
> hmm - most but not all calls to HTAlert are urgent.  I see some cases
> where you might not want to exit immediately:
> 
> src/GridText.c:13908:         HTAlert(gettext("Very long lines have been 
> truncated!"));
> src/HTFWriter.c:990:      HTAlert(EXECUTION_DISABLED);
> src/LYLocal.c:354:    HTAlert(gettext("The selected item is not a file or a 
> directory!  Request ignored."));
> src/LYLocal.c:676:    HTAlert(gettext("There is already a directory with that 
> name!  Request ignored."));
> src/LYLocal.c:678:    HTAlert(gettext("There is already a file with that 
> name!  Request ignored."));
> src/LYMain.c:2438:        HTAlert(gettext("persistent cookies state will be 
> changed in next session only."));
> src/LYMainLoop.c:5399:        HTAlert(SHIFT_VS_LINEWRAP);
> src/LYOptions.c:3399:             HTAlert(UA_PLEASE_USE_LYNX);
> 
> > 
> > $ diff lynx2.9.0/src/LYGlobalDefs.h.orig lynx2.9.0/src/LYGlobalDefs.h
> > 669a670,671
> > >     extern BOOLEAN LYFailOnAlert;
> > >     extern BOOLEAN alert_occurred;
> > 
> > $ diff lynx2.9.0/src/LYMain.c.orig lynx2.9.0/src/LYMain.c
> > 731a732,734
> > > BOOLEAN LYFailOnAlert = FALSE;
> > > BOOLEAN alert_occurred = FALSE;
> > > 
> > 919c922,927
> > <     exit(code);
> > ---
> > > 
> > >     if (LYFailOnAlert && alert_occurred) {
> > >         exit(EXIT_FAILURE);
> > >     } else {
> > >         exit(code);
> > >     }
> > 3548a3557,3560
> > >    PARSE_SET(
> > >       "fail_on_alert",    4|SET_ARG,              LYFailOnAlert,
> > >       "exit with error code if any alert is written"
> > >    ),
> > 
> > 
> > This patch introduces a new command-line option, -fail_on_alert, and a 
> > corresponding global flag LYFailOnAlert.
> > 
> > The patch modifies HTAlert.c, LYGlobalDefs.h, and LYMain.c to track whether 
> > 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 
> > EXIT_FAILURE regardless of the standard exit code.
> > 
> > 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, 
> > for example:
> > 
> > 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>&-) > ...
> > 
> > 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.
> > 
> > I believe this is a useful addition for anyone using Lynx in automated 
> > environments or CI/CD pipelines.
> > 
> > 
> 
> -- 
> Thomas E. Dickey <[email protected]>
> https://invisible-island.net
>

Reply via email to