View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001507 | 1003.1(2016/18)/Issue7+TC2 | Shell and Utilities | public | 2021-08-10 14:29 | 2024-06-11 09:07 |
Reporter | geoffclare | Assigned To | |||
Priority | normal | Severity | Objection | Type | Error |
Status | Closed | Resolution | Accepted | ||
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.to: 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 |
|
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". |
|
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. |
|
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. |
|
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. |
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 |