Anonymous | Login | 2024-05-04 16:10 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0000971 | [1003.1(2008)/Issue 7] Shell and Utilities | Objection | Error | 2015-07-22 17:26 | 2019-06-10 08:54 | ||
Reporter | sebor | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | Martin Sebor | ||||||
Organization | |||||||
User Reference | |||||||
Section | join | ||||||
Page Number | 2839 | ||||||
Line Number | 93313-93315, 93389-93391 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | See Note: 0002772. | ||||||
Summary | 0000971: join -t separator underspecified, example incorrect | ||||||
Description |
The join utility -t option takes a character argument that specifies the separator between fields on which to perform the join. There is no description of the format in which the character may be specified (for example, whether it can be an escape sequence, as in \t, or a character class such as [:blank:], similarly to how tr interprets characters in its operands), suggesting that no special formats are accepted. However, the EXAMPLES section shows the following invocation of the utility: join -t "<tab>" -a 1 -a 2 -e '(unknown)' -o 0,1.2,2.2 phone fax Note the "<tab>". I've only tried two implementations of join but neither recognizes "<tab>" as representing the <TAB> character. Instead, both implementations simply treat the leading '<' as the separator and ignore the rest. Unless the example reflects an intent that join accept other separators besides ordinary characters, it will not behave as described. |
||||||
Desired Action |
Since there doesn't seem to be any evidence that the utility is expected to map a symbolic character name in the argument to the -t option to the corresponding character, the example should be changed to show how the utility can be invoked to obtain the expected output. In addition, the standard should be specific about what format the -t argument is required or permitted to be in and what implementations should do when it is not in the expected format. If the behavior is to be left unspecified when the argument is not a single character, it would be nice to make that explicit and encourage implementations to provide more useful behavior than simply ignoring everything past the first character. (For example, issuing a diagnostic would be a useful extension, as would treating the argument the same way tr does.) |
||||||
Tags | tc2-2008 | ||||||
Attached Files | |||||||
|
Issue History | |||
Date Modified | Username | Field | Change |
2015-07-22 17:26 | sebor | New Issue | |
2015-07-22 17:26 | sebor | Status | New => Under Review |
2015-07-22 17:26 | sebor | Assigned To | => ajosey |
2015-07-22 17:26 | sebor | Name | => Martin Sebor |
2015-07-22 17:26 | sebor | Section | => join |
2015-07-22 17:26 | sebor | Page Number | => 2839 |
2015-07-22 17:26 | sebor | Line Number | => 93313-93315, 93389-93391 |
2015-07-22 21:24 | shware_systems | Note Added: 0002771 | |
2015-07-23 15:08 | Don Cragun | Note Added: 0002772 | |
2015-07-23 15:09 | Don Cragun | Interp Status | => --- |
2015-07-23 15:09 | Don Cragun | Final Accepted Text | => See Note: 0002772. |
2015-07-23 15:09 | Don Cragun | Status | Under Review => Resolved |
2015-07-23 15:09 | Don Cragun | Resolution | Open => Accepted As Marked |
2015-07-23 15:09 | Don Cragun | Tag Attached: tc2-2008 | |
2019-06-10 08:54 | agadmin | Status | Resolved => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |