[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Why cut treats one column input differently for out-of-range field spec?
From: |
Peng Yu |
Subject: |
Why cut treats one column input differently for out-of-range field spec? |
Date: |
Wed, 17 Jan 2018 08:16:24 -0600 |
Hi,
If there is only one column in the input, then an out-of-range field
spec will result in the print of the whole line.
$ cut -f 3 <<< $'a' | xxd
0000000: 610a a.
Otherwise, an empty string is printed.
$ cut -f 3 <<< $'a\tb' | xxd
0000000: 0a .
This is counter-intuitive. I think that one-field input should not be
treated specially. It should still result in no output for an
out-of-range field spec.
Is there a strong reason why `cut` should treat one-field input
different? (What if users do want empty string be printed for
out-of-range field even for one-field input?) Or this should be
considered as a bug?
--
Regards,
Peng
- Why cut treats one column input differently for out-of-range field spec?,
Peng Yu <=
- Prev by Date:
Re: Multibyte support for sort, uniq, join, tr, cut, paste, expand, unexpand, fmt, fold, and pr
- Next by Date:
Re: Why cut treats one column input differently for out-of-range field spec?
- Previous by thread:
Speed up sort with concurrency
- Next by thread:
Re: Why cut treats one column input differently for out-of-range field spec?
- Index(es):