Subject: bug#19240: cut 8.22 adds newline

From: John Kendall <[email-masked]>
Date: Thu, 4 Dec 2014 22:29:53 +0000

On Dec 4, 2014, at 1:56 PM, Eric Blake <[email-masked]>
 wrote:

> On 12/04/2014 02:13 PM, John Kendall wrote:
>> Yes, that's what I've done.  The corner case I mentioned is 
>> handled badly by this, however.  In the corner case $FILE 
>> is a list of files separated by a newlines.  Solaris cut would 
>> list them and then the ============= would be tacked 
>> on to the last line:
> 
> Again, mention your goal up front, and you can save us some iterations.
> So you really DO want to grab a rectangular region of text, and append
> to just the last line, rather than chop a single line of input at a
> fixed length (it was not obvious to us from the naming or your example
> that you intended for $FILE to contain newlines).
> 

My goal was to bring up the differences between Solaris cut and gnu cut 
and hear the justification.  And I've learned a lot.  I've been in the
Solaris gated community for so long, imagine how much I have never
had to think about!

But it was never my intention to have you solve the re-write for me.  I 
only shared my code because Bob asked.  But I really appreciate you 
solving it for me!

Thanks again to all of you.

> So, my solution of using command substitution still does this, and portably:
> 
> echo "$(echo "$FILE ============================"| cut -c1-30)" \
>      " matches =========="
> 
> So does sed, although no longer a short one-liner:
> 
> echo "$FILE" | sed -e 's/^\(.\{30\}\).*/\1/' \
>                   -e '$ {' \
>                   -e   's/$/ ============================/' \
>                   -e   's/^\(.\{30\}\).*/\1/' \
>                   -e   '$ s/$/ matches ==========/' \
>                   -e '}'
> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>