RGBCube/uutils-coreutils
1
Fork 0
mirror of https://github.com/RGBCube/uutils-coreutils synced 2025-07-27 11:07:44 +00:00
Code Issues Activity

ls: gnu color-clear-to-eol fix (#6507)

Browse source 
---------

Co-authored-by: Sylvestre Ledru <sylvestre@debian.org>
This commit is contained in:
sreehari prasad 2024-06-29 13:36:00 +05:30 • committed by GitHub
parent f451714d26
commit dbeae9f444
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
4 changed files with 103 additions and 26 deletions
Download patch file Download diff file Expand all files Collapse all files

12
util/build-gnu.sh
View file

@ -355,4 +355,14 @@ sed -i -E 's/(\^\[\[0m)+/\^\[\[0m/g' tests/ls/color-norm.sh
# GNU's ls seems to output color codes in the order given in the environment
# variable, but our ls seems to output them in a predefined order. Nevertheless,
# the order doesn't matter, so it's okay.
sed -i 's/44;37/37;44/' tests/ls/multihardlink.sh
sed -i 's/44;37/37;44/' tests/ls/multihardlink.sh
# Just like mentioned in the previous patch, GNU's ls output color codes in the
# same way it is specified in the environment variable, but our ls emits them
# differently. In this case, the color code is set to 0;31;42, and our ls would
# ignore the 0; part. This would have been a bug if we output color codes
# individually, for example, ^[[31^[[42 instead of ^[[31;42, but we don't do
# that anywhere in our implementation, and it looks like GNU's ls also doesn't
# do that. So, it's okay to ignore the zero.
sed -i "s/color_code='0;31;42'/color_code='31;42'/" tests/ls/color-clear-to-eol.sh