View Issue Details

IDProjectCategoryView StatusLast Update
0001743Issue 8 draftsShell and Utilitiespublic2024-06-11 09:12
Reportersteffen Assigned To 
PrioritynormalSeverityEditorialTypeError
Status ClosedResolutionAccepted 
Product VersionDraft 3 
Namesteffen
Organization
User Reference
Sectionmailx
Page Number3085, 3087
Line Number103783, 103869
Final Accepted Text
Summary0001743: mailx: revert faulty change
DescriptionHello.

Unfortunately i introduced "another fault", another non-portable-across-implementations problem.

It is the *metoo* variable that does not affect `alternates' (command) names in the historical, and the BSD codebases, but _only_ $LOGNAME.
For those, `alternates' are _always_ removed from recipient lists (and _only_ when replying).
(And the *from* and *sender* variables are non-portable.)

(It is also that further mailx(1) development can hardly be expected in portable manner, standardizable manner.)
Desired ActionOn page 3085, line 103783 ff., change

  Suppress the deletion of the user’s login name and any alternative addresses from the recipient list when replying to a message or sending to a group. The default shall be nometoo.

to

  Suppress the deletion of the user’s login name from the recipient list when replying to a message or sending to a group. The default shall be nometoo.

On page 3087, line 103869 ff., change

  Declare a list of alternative addresses for the address consisting of the user’s login name. When responding to a message or sending to a group, if the metoo variable is unset these alternative addresses shall be removed from the list of recipients. The comparison of addresses shall be performed in a case-insensitive manner. With no arguments, alternates shall write the current list of alternative addresses.

to

  Declare a list of alternative addresses for the address consisting of the user’s login name. When responding to a message these alternative addresses shall be removed from the list of recipients. The comparison of addresses shall be performed in a case-insensitive manner. With no arguments, alternates shall write the current list of alternative addresses.

Page and line numbers from IEEE P1003.1™-202x/D3, March 2023.
Tagsapplied_after_i8d3, issue8

Activities

steffen

2023-06-20 18:24

reporter   bugnote:0006342

But what current POSIX defines is a sane approach, and work has been put into it so that it is like that.
And it mirrors what other MUAs do (mutt for example).
And it can be implemented on all codebases in a few minutes.

If it is not too much work you could close this.

The only real thing is

  on page 3087, line 103862 ff., insert after

    [.] for example, when hlj is an alias, hlj@posix.com does not trigger
    the alias substitution.

  the sentences

    Recursive expansion of an alias group member can be prevented by
    prefixing it with an unquoted <backslash>.

describing status quo of all codebases; i open a different issue on that.

Sorry. "Despair" on my side: if you read documentation and see the clean approach of a from-scratch implementation like from mutt, for example, with slightly different meaning of metoo, alternates and alias.

Don Cragun

2023-07-24 15:42

manager   bugnote:0006399

Last edited: 2023-07-24 17:59

We discussed this during the 2023-07-24 conference call and found 0001743:0006342 ambiguous. It sounds like the submitter is unhappy with the proposed changes in the note. We are backing out the changes made in issue 8 as suggested in the desired action and look forward to a new bug report to address the issues raised in the note.

Issue History

Date Modified Username Field Change
2023-06-08 20:48 steffen New Issue
2023-06-08 20:48 steffen Name => steffen
2023-06-08 20:48 steffen Section => mailx
2023-06-08 20:48 steffen Page Number => 3085, 3087
2023-06-08 20:48 steffen Line Number => 103783, 103869
2023-06-13 14:51 geoffclare Project 1003.1(2016/18)/Issue7+TC2 => Issue 8 drafts
2023-06-20 18:24 steffen Note Added: 0006342
2023-07-20 23:42 Don Cragun Product Version => Draft 3
2023-07-24 15:33 Don Cragun Status New => Resolved
2023-07-24 15:33 Don Cragun Resolution Open => Accepted
2023-07-24 15:34 Don Cragun Tag Attached: issue8
2023-07-24 15:42 Don Cragun Note Added: 0006399
2023-07-24 17:59 Don Cragun Note Edited: 0006399
2023-08-22 14:27 geoffclare Status Resolved => Applied
2023-08-22 14:27 geoffclare Tag Attached: applied_after_i8d3
2024-06-11 09:12 agadmin Status Applied => Closed