3
# uname -mrs
OpenBSD 6.0 amd64
# RANDOMNUMBER() { /usr/bin/openssl rand -hex 64 | tr -dc 0-9 | /usr/bin/cut -c-4;}
# while true; do WTF=$(/usr/bin/strings /dev/arandom | head -$(RANDOMNUMBER) | sort -R | /usr/bin/perl -pe 's/\n//g' | /usr/bin/cut -c1-63); echo "$WTF"; echo "$WTF" | wc -c; done
!+{l^RQ-QuK=iVYC\ud#pqNw?nJ"oyizU}NI5~0\HEagHv7`/6PI$|b_1)59Aj=
      64
3"fcALD`&L\#Ls7fP!Gs9Ksjv\)     ?Fm9]R#oRlEb%&=R{-zRvRE /})^uM:H9sq
      64
Q|Ik^.zuYu:|_DTt>)q48;[JVwX}F@yU)hu,~v=Wj*"ra'g=@#hJ$.ur\Ru'WMV
      64
lTYU6V2qm;[e;.dsxW+mWqf]LCylFsY,V7+71i}/6L)m<RtuCxH6,et<i[N(NV  
      64
>apV:8T e3      Y<ga$h*+9>4`kanC 35OHoG%\gG8vvWU?rM%XYuV*4?UIWVvB<!U
      64
 #b8vw:L!OvW    73/-iUPw}Ge|$ka{'E=tkTHmzb)1syK!fSN]_As'D>KGe_k<o=
      64
O5='9b}.NGChC]D{{ =^#tg7;EhzDJag`R-z/L<=LJ[h*aLI [2xPbz__+K_Bc|
      64
E\AxbSAu6seR=:-uwG$h86;r\gs(Ni0%95<O.+Yts)br9xd*>b`f    K!%Q_%+9I-
      64
8RXi=aJL3siO!PM5l]>~(5$bgp.#Z|p1,d6au-^0`mD9+Cdk@*].05g(:1,}f"R
      64
K\_a~oim<dq_^,JBjb$sYA,Icv@kOVWi2'z+us2BzW|~@l+iD3@euM|iS;"0tw&
      64
bI[Aev\{[YN"a^$)j'W[\4r?Ey[ !Jn32V6`PE(6WAqL~NYg&/{J-w > _uAS}i
      64
I|jm@onzPfAhK5HJq:V     h<p-<_oPvS68)2L\&4)CWM|GYv0l}8= 7 ZpW wH}UR
      64
i_x?KW3<v7/Pw   w6>gXw7#HE]n,d4mj8'my@)*15m]dK(+9[o!h<w^ $$PS)Q4@
      64
wJ1pv[3sHJrpXV=c-c{2%0A,F-.3;`M^cvV6E&|B"`@V+RYs        dlS*yEqsV_      $G6
      64
M_iq/+  |>*@CC4G.-?9s@;0tR^>&dh]5,sQu.8akCJU01qxiX5TUe&}=I_K;X%`
      64
^C
# 

From this I just cannot understand a few lines (running it manually...):

# echo '>apV:8T e3      Y<ga$h*+9>4`kanC 35OHoG%\gG8vvWU?rM%XYuV*4?UIWVvB<!U' | wc -c
      69
# 
# echo 'wJ1pv[3sHJrpXV=c-c{2%0A,F-.3;`M^cvV6E&|B"`@V+RYs        dlS*yEqsV_      $G6' | wc -c
      76
# 

Why does "cut" do such a thing? I asked it to cut at 63 chars. But it sometimes gives longer lines than 63 that I can prove by later manually selecting the output, puting it in an echo and using "| wc -c".. maybe there is a bug in the "cut" command regarding spaces?

For the first example manual line, the top script gives 64, but checking it manually reveals it is actually 69.

  • not bug, utf8 terminal. – Ipor Sircer Nov 3 '16 at 10:36
6

You've got tabs in there; each tab counts as one character from cut's point of view, but can occupy more space than that onscreen. What's more, it occupies an amount which varies depending on where in the line it is output...

Each line which appears longer than 64 characters has a corresponding gap which aligns with a tabstop (eight characters in most environments so far this century):

3"fcALD`&L\#Ls7fP!Gs9Ksjv\)     ?Fm9]R#oRlEb%&=R{-zRvRE /})^uM:H9sq
                           ^ tab here
                                ^ tabstop here
1234567812345678123456781234567812345678123456781234567812345678

When you copied and pasted the output for your second set of measurements, the spaces that the tabs had been expanded to were copied, so wc -c counted those instead.

  • 1
    Note that wc -c counts bytes, not characters (though in the case of ASCII characters, that's equivalent). wc -m to count characters. See also wc -L with GNU wc to get the display width (of the widest line) – Stéphane Chazelas Nov 3 '16 at 11:39
  • Right, with strings' default settings (7-bit ASCII) the usage here is equivalent. wc -c is a rather confusing short option! We'd probably be better off using wc --bytes for clarity... – Stephen Kitt Nov 3 '16 at 12:00
  • And at Intermediate Unix Level one learns that tabstops are not necessarily at eight character intervals. – JdeBP Nov 3 '16 at 19:20
  • 1
    @JdeBP when you've finished insulting people, perhaps you'd let me point out that I'm explaining the behaviour seen by the OP. I'll clarify the tabstop thing though. – Stephen Kitt Nov 3 '16 at 19:24
  • There's no insult in anything written there, or indeed anything about any person at all. – JdeBP Nov 3 '16 at 23:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.