[lfs-dev] Coreutils 8.25 i18n patch breaks cut

Chris Staub chris at beaker67.com
Sun Feb 7 20:27:16 PST 2016


I just tried using jhalfs with a current CLFS system (using a few things 
from LFS) as a host, and it failed attempting to download packages. 
Specifically, basename complained about an extra parameter, which 
happened to be the package's md5sum. After a bit of debugging, I found 
that the problem comes from this command that jhalfs tries to run:

echo http://download.savannah.gnu.org/releases/acl/acl-2.2.52.src.tar.gz 
ftp://ftp.lfs-matrix.net/pub/clfs/conglomeration/acl/acl-2.2.52.src.tar.gz 
a61415312426e9c2212bd7dc7929abda | cut -d" " -f2

This should result in the the 2nd URL listed, but instead it gives this 
output:

http://download.savannah.gnu.org/releases/acl/acl-2.2.52.src.ta
ftp://ftp.lfs-matrix.net/pub/clfs/conglomeration/acl/acl-2.2.52
a61415312426e9c2212bd7dc7929abda

The problem is that the "cut" program isn't giving the expected output. 
After some further experimentation, and checking with William Harrington 
in IRC who got the same results, this problem only occurs when using 
Coreutils 8.25 with the i18n patch that's in LFS. When using 8.24, or 
8.25 without the patch, I get the expected result and jhalfs runs fine.

After some further testing, cut appears to screw up whenever the first 
field is >=64 characters. The patch defines MIN_CHUNK in cut.c with a 
value of 64, and when I increased that to 128 I could use cut 
successfully with the first field up to 128 characters. I don't think 
MIN_CHUNK is supposed to be an *upper* limit for field length, but 
apparently that it is being used as.


More information about the lfs-dev mailing list