Bug 252743 - rs(1) with -C adds spurious trailing separator
Summary: rs(1) with -C adds spurious trailing separator
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: Unspecified
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-16 16:11 UTC by Tim Chase
Modified: 2021-01-16 16:11 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Chase 2021-01-16 16:11:11 UTC
To reproduce:

    $ jot 3 | rs -C,

Expected output:

    1,2,3

Actual output:

    1,2,3,

(note the trailing comma)
_________________________________

By default, rs(1) will strip trailing delimiters:

    $ jot 3 | rs
    1  2  3
    $ jot 3 | rs | hexdump -C | head -1
    00000000  31 20 20 32 20 20 33 0a                           |1  2  3.|

and `rs -m` will properly preserve them:

    $ jot 3 | rs -m | hexdump -C | head -1
    00000000  31 20 20 32 20 20 33 20  20 0a                    |1  2  3  .|

(note the additional two hex "20" space values).

Similarly, the -S$DELIM option properly strips trailing delimiters while `-m` keeps them:

    $ jot 3 | rs -S,
    1,,2,,3
    $ jot 3 | rs -mS,
    1,,2,,3,,

However, when specifying an output delimiter with -C, it doesn't strip the trailing delimiter:

    $ jot 3 | rs -C,
    1,2,3,

That's the output I would expect from `rs -mC,` to maintain a trailing delimiter:

    $ jot 3 | rs -C, -m
    1,2,3,

as the man-page for rs(1) says

> -m  Do not trim excess delimiters from the ends of the output array.

suggesting that trailing delimiters (including those from `-C`) should be trimmed unless `-m` is specified.