bug#19240: cut 8.22 adds newline

[Bob Proulx]

John Kendall wrote:
> Bob Proulx wrote:
> >> I came upon this while porting scripts from Solaris 10 to Centos 7.
> > 
> > Can you share with us the specific construct that caused this to
> > arise?  I have done a lot of script porting to and from HP-UX systems
> > and am curious as to the issue.
> 
> The construct in question if just for formatting the output 
> of a script that compares disc files to what's in a database.  
> 
>  echo "$FILE ===========================\c"| cut -c1-30
>  echo " matches =========="

Eww...  Immediately I have a second immune reaction to the above.  The
reason is that the use of echo above is non-portable.  It uses the old
System V echo interface that interprets escape sequences by default.
This can be enabled in bash with the --enable-usg-echo-default flag
but it is off by default because BSD doesn't support it by default.

The solution to this problem has been to recommend using 'printf'
everywhere anywhere that an escape sequence is needed or anywhere that
not having a newline is needed.  Since printf is POSIX standard and
avoids the echo unportability.  Use of echo can be very unportable and
the "\c" is one of those unportable things.

> The output on Solaris might look something like this (with 
> monospaced font on a terminal all the "matches" line up):
> ...

Cool.

> This can be re-written, of course.  (There is one corner case that 
> Solaris's cut handled nicely that I have not been able to come up 
> with a quick fix.) 

Immediately printf comes to mind.  Use %s with a format with
specifier.  Since printf is POSIX standard this should work anywhere.
The failure mode of not having printf available on really, really,
really old systems is trivially handled by providing a printf for that
system.  Much easier than dealing with other differences.

  printf "%.30s matches ==========\n" "$FILE ==========================="

One thing I still don't like about the above is that it will truncate
any long file names.  Any file name longer than 30 will be trunncated.
But of course that would require changes in output format to address.
My preference would be to have "matches" first and the file name
second and let the file name go as long as it needs to go.

Bob