Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001507 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2021-08-10 14:29 2024-06-11 09:07
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section mailx
Page Number 2964
Line Number 98259
Interp Status ---
Final Accepted Text
Summary 0001507: Exit status 0 for mailx needs changing
Description The description of exit status 0 for the mailx utility assumes that mailx is always used to send one or more messages. In Send Mode that is true, but in Receive Mode it only sends messages if one of the forms of Follow Up, Mail, or Reply commands is used.
Desired Action Change:
note that this status implies that all messages were sent, but it gives no assurances that any of them were actually delivered.
note that this status implies that any messages that mailx was instructed to send were all successfully sent, but it gives no assurances that any of them were actually delivered.

Tags tc3-2008
Attached Files

- Relationships

-  Notes
steffen (reporter)
2021-08-12 22:51

It is .. difficult.
You know, i personally start an instance of my mailx clone on Monday, and quit it on Saturday (Sunday that is already, mostly).
Should the exit status on Saturday reflect a failed delivery attempt on say Tuesday?

For my clone i added options like "set errexit", an "ignerr" command / "-" command escape prefix (to explicitly ignore errors even if "errexit" is active etc etc.
We also have per-command return/exit status and error numbers.
So if we survive errors, the next command will reset the exit status to 0.

It can be said that we are not compliant to the current state of affairs POSIX defines in at least receive mode, on the other hand.
Maybe i should make any occurrence of the send-error bit persistent, and restore it upon program exit, in at least send mode, and at least in conjunction with $POSIXLY_CORRECT aka "set posix".
shware_systems (reporter)
2021-12-09 17:26

Re: 5441
As the workarounds for that use case involve extensions, it was felt these extensions are better as a seperate enhancement proposal than affect the issue here.
steffen (reporter)
2021-12-09 19:52

Re: 5550
Well i have implemented it now, but any other codebase does not do that, neither BSD Mail nor System V10 mailx?, they all _only_ exit "send-error" in "Send-only mode: send mail "to-addr"(ess) receiver(s)", but not in ""Receive" mode, starting on [-u user], primary *inbox* or [$MAIL]" nor in ""Receive" mode, starting on -f (secondary $MBOX or [file])".
That is only in send-one-mail mode. But it is ok and easily implemented.
steffen (reporter)
2021-12-09 19:59

I should have explained myself and the problem better, for sure.
I mean it is ok, since even POSIX mailx can be used to batch-send several messages, and with the outcome of this issue the exit status reflects a "grand total". (*sendwait* should be set.)

But it is surely true that more fine-grained delivery control requires non-trivial work on the codebases, let alone via more generalized concepts like accessible return values, and per-command error suppressing.

My fault, i should have explained my problem better.

- Issue History
Date Modified Username Field Change
2021-08-10 14:29 geoffclare New Issue
2021-08-10 14:29 geoffclare Name => Geoff Clare
2021-08-10 14:29 geoffclare Organization => The Open Group
2021-08-10 14:29 geoffclare Section => mailx
2021-08-10 14:29 geoffclare Page Number => 2964
2021-08-10 14:29 geoffclare Line Number => 98259
2021-08-10 14:29 geoffclare Interp Status => ---
2021-08-12 22:51 steffen Note Added: 0005441
2021-12-09 17:22 Don Cragun Status New => Resolved
2021-12-09 17:22 Don Cragun Resolution Open => Accepted
2021-12-09 17:22 Don Cragun Tag Attached: tc3-2008
2021-12-09 17:26 shware_systems Note Added: 0005550
2021-12-09 19:52 steffen Note Added: 0005552
2021-12-09 19:59 steffen Note Added: 0005553
2022-01-11 11:31 geoffclare Status Resolved => Applied
2024-06-11 09:07 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker