That's a fair point. However, I'd like to clarify a few things about how the patch actually behaves (or intended to behave) and why these specific cases might still warrant a non-zero exit code:
No immediate exit: The patch doesn't force an immediate or ungraceful shutdown. 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 any alerts were triggered during the session (and this new command line option 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 unexpected occurred. Regarding the specific examples you mentioned: src/GridText.c (truncated lines): Since this happens when inserting file contents into a TEXTAREA, the final form (of that TEXTAREA) submission might be incomplete. From an automation standpoint, it's ambiguous whether the user'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 'successful' 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 scripts. src/LYMain.c (persistent cookies): Changes to cookie states can fundamentally change the content Lynx shows or dumps. If a user relies on persistent cookies for a specific workflow, a zero exit code could be misleading if those 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 guidance. My original reasoning was inspired by HTTP status codes (4xx/5xx). My impression was that for non-interactive sessions (like -source or -dump), almost any alert suggests the process didn't go perfectly. We could try to classify 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 <[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 >
