Re: wrong color for broken symlinks
Jim Meyering [EMAIL PROTECTED] wrote:
...
diff --git a/src/ls.c b/src/ls.c
index f412dff..c0e332b 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -2578,7 +2578,7 @@ gobble_file (char const *name, enum filetype type,
ino_t i
node,
(type == symbolic_link || type == unknown)
(dereference == DEREF_ALWAYS
|| (command_line_arg dereference != DEREF_NEVER)
- || color_symlink_as_referent))
+ || color_symlink_as_referent || check_symlink_color))
/* Command line dereferences are already taken care of by the above
assertion that the inode number is not yet known. */
|| (print_inode inode == NOT_AN_INODE_NUMBER)
I'll apply that as soon as I write a test.
I wrote the ChangeLog entry and applied Eric's patch:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=1d85945
Here's the test, NEWS, etc:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=383713e
2007-04-24 Jim Meyering [EMAIL PROTECTED]
* THANKS: Add Andreas Frische.
* NEWS: Mention today's ls --color fix.
* tests/ls-2/tests (sl-dangle): Add a test for today's fix.
diff --git a/NEWS b/NEWS
index c4678e7..0542cd9 100644
--- a/NEWS
+++ b/NEWS
@@ -11,6 +11,11 @@ GNU coreutils NEWS-*-
outline -*-
ls -x DIR would sometimes output the wrong string in place of the
first entry. [introduced in coreutils-6.8]
+ ls --color would mistakenly color a dangling symlink as if it were
+ a regular symlink. This would happen only when the dangling symlink
+ was not a command-line argument and in a directory with d_type support.
+ [introduced in coreutils-6.0]
+
ls --color, (with a custom LS_COLORS envvar value including the
ln=target attribute) would mistakenly output the string target
before the name of each symlink. [introduced in coreutils-6.0]
diff --git a/THANKS b/THANKS
index 63fcc39..2033c38 100644
--- a/THANKS
+++ b/THANKS
@@ -26,6 +26,7 @@ Alexey Vyskubov [EMAIL PROTECTED]
Alfred M. Szmidt[EMAIL PROTECTED]
Andi Kleen [EMAIL PROTECTED]
Andre Novaes Cunha [EMAIL PROTECTED]
+Andreas Frische [EMAIL PROTECTED]
Andreas Gruenbacher [EMAIL PROTECTED]
Andreas Jaeger [EMAIL PROTECTED]
Andreas Luik[EMAIL PROTECTED]
diff --git a/tests/ls-2/tests b/tests/ls-2/tests
index 3f2fc1d..9bf4057 100755
--- a/tests/ls-2/tests
+++ b/tests/ls-2/tests
@@ -130,6 +130,19 @@ my @Tests =
['sl-target', '--color=always d',
{OUT = \e[0m\e[01;34mX\e[0m\n\e[m}, $target, $target2],
+ # Test for another bug fixed in coreutils-6.10.
+ # This one bites only for a system/file system with d_type support.
+ ['sl-dangle', '--color=always d',
+ {OUT = \e[0m\e[40;31;01mX\e[0m\n\e[m},
+ {PRE = sub {
+ mkdir 'd',0755 or die d: $!\n;
+ symlink 'non-existent', 'd/X' or die d/X: $!\n;
+ $ENV{LS_COLORS}='or=40;31;01'
+ }},
+ {POST = sub {unlink 'd/X' or die d/X: $!\n;
+ rmdir 'd' or die d: $!\n }},
+ ],
+
# Test for a bug that was introduced in coreutils-4.5.4; fixed in 4.5.5.
# To demonstrate it, the file in question (with executable bit set)
# must not be a command line argument.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort -t: -k1 behaves strangely
Eric Blake scripsit: Did you mean to use -k1,1 instead of -k1? Otherwise, you are stating that the key begins with the first field, but continues through the end of the line (with the field separators ignored), and since ' ' comes before '#', the output looked correct to me. Using -k1,1 swaps the line to list #2 first. Ah, thanks. Unfortunately, this is documented only on the info page, not on the man page or sort --help. Adding or EOL if omitted to those two sources would be very helpful. I've probably never noticed the difference before, because I usually sort tab-delimited rather than colon-delimited files. -- The man that wanders far[EMAIL PROTECTED] from the walking tree http://www.ccil.org/~cowan --first line of a non-existent poem by: John Cowan ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
sort by line length
Dear coreutils team, I would like to see a sort by line length in the sort tool. Is anything like this planned. It seems easy to implement. I could also write the code for that, if you wish. Best regards, Georg ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort by line length
According to Georg Müller on 4/24/2007 6:22 AM: Dear coreutils team, I would like to see a sort by line length in the sort tool. Is anything like this planned. Not really planned, but it doesn't sound all that bad to me. Submit a patch for discussion, if you would like. But it sounds non-trivial (don't forget the documentation and testsuite), so you will need copyright assignment on file. It seems easy to implement. I could also write the code for that, if you wish. It may be possible to already do this with existing tools, although certainly not conventional. For example, it can probably be achieved already by writing a custom locale that treats all bytes as the same collation class, so that strcoll then compares according to line length. Or you could use a series of operations, such as sed to number the lines and convert all remaining characters to a single character, sort the converted file by the reduced key, and then use the resulting order of the line numbers as the directions for which order to retrieve lines from the original file. -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort by line length
Georg Müller [EMAIL PROTECTED] wrote:
I would like to see a sort by line length in the sort tool.
Is anything like this planned.
It seems easy to implement.
I could also write the code for that, if you wish.
You can do this in perl (or awk, ruby, etc) as a one-liner,
so it may not be worth adding to a C application:
echo 1 938 four aa a | fmt -1 \
| perl -ne 'push @line, $_;sub END{print sort {length $a=length $b} @line}'
1
aa
938
four
a
Is that good enough for you?
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort by line length
Georg Müller wrote: Dear coreutils team, I would like to see a sort by line length in the sort tool. Is anything like this planned. It seems easy to implement. I could also write the code for that, if you wish. That seems like a very specific need which is probably best fulfilled with a combination of tools? Have you an example of why you need this? If I was doing it, I would use my funcpy tool¹ as follows, to transform the data into the appropriate format: funcpy '%d\t%s % (len(x),x)' | sort -k1,1n | cut -f2- thanks, Pádraig. ¹http://www.pixelbeat.org/scripts/funcpy ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort by line length
Jim Meyering wrote:
You can do this in perl (or awk, ruby, etc) as a one-liner,
so it may not be worth adding to a C application:
echo 1 938 four aa a | fmt -1 \
| perl -ne 'push @line, $_;sub END{print sort {length $a=length $b}
@line}'
1
aa
938
four
a
Not to derail on perl golfing but how about just:
$ perl -e 'print sort {length($a)=length($b)} ' file
Brian
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort by line length
Georg Müller [EMAIL PROTECTED] writes:
I would like to see a sort by line length in the sort tool.
awk '{ print length(), $0 }' input | sort -k1,1n | cut -d' ' -f2- output
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort by line length
I know that I can solve this by these combinations, but having a -l flag for sort would be much shorter to write and I am not so familiar with perl. It was just an idea to make things easier, if you don't like it, ignore it. I need it atm for bug fixing other stuff, but searched for that a time ago... Thanks for the quick answers, Georg ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
