Re: Fwd: wrong color for broken symlinks
Andreas Frische [EMAIL PROTECTED] wrote: as of ls (GNU coreutils) 6.9 this bug is still not fixed. ls --color | od -tx1z 000 1b 5b 30 30 6d 1b 5b 30 31 3b 33 36 6d 74 65 73 .[00m.[01;36mtes 020 74 1b 5b 30 30 6d 40 0a 1b 5b 6d [EMAIL PROTECTED] 033 ls --color test | od -tx1z 000 1b 5b 30 30 6d 1b 5b 34 30 3b 33 31 3b 30 31 6d .[00m.[40;31;01m 020 74 65 73 74 1b 5b 30 30 6d 40 0a 1b 5b 6d[EMAIL PROTECTED] 036 Please try a snapshot: http://meyering.net/cu/coreutils-6.9+.tar.gz You're probably seeing a bug that's already fixed for the next release. Here's the NEWS entry: 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] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
join bug?
Hi, I was trying to attach 2 files, join -1 1 -2 1 Received_Packets Sent_Packets The problem is, after the packet nr82, there is more numbers that match, and the program just join the files until the packet nr82. and file Received_Packets is: 4 25.109191 5 25.199239 6 25.289286 7 25.384085 8 25.474132 9 25.56418 10 25.654227 11 25.744274 12 25.834322 13 25.929103 14 26.01915 15 26.109197 16 26.199245 17 26.289292 18 26.384091 19 26.474138 20 26.564186 21 26.654233 22 26.74428 23 26.834327 24 26.929103 25 27.01915 45 27.109197 82 27.199245 120 27.289292 159 27.384091 and Sent_Packets is: 0 25.0 1 25.00240 2 25.00480 3 25.00720 4 25.00960 5 25.01200 6 25.01440 7 25.01680 8 25.01920 9 25.02160 10 25.02400 11 25.02640 12 25.02880 13 25.03120 14 25.03360 15 25.03600 16 25.03840 17 25.04080 18 25.04320 19 25.04560 20 25.04800 21 25.05040 22 25.05280 23 25.05520 24 25.05760 25 25.06000 26 25.06240 27 25.06480 28 25.06720 29 25.06960 30 25.07200 31 25.07440 32 25.07680 33 25.07920 34 25.08160 35 25.08400 36 25.08640 37 25.08880 38 25.09120 39 25.09360 40 25.09600 41 25.09840 42 25.10080 43 25.10320 44 25.10560 45 25.10800 46 25.11040 47 25.11280 48 25.11520 49 25.11760 50 25.12000 51 25.12240 52 25.12480 53 25.12720 54 25.12960 55 25.13200 56 25.13440 57 25.13680 58 25.13920 59 25.14160 60 25.14400 61 25.14640 62 25.14880 63 25.15120 64 25.15360 65 25.15600 66 25.15840 67 25.16080 68 25.16320 69 25.16560 70 25.16800 71 25.17040 72 25.17280 73 25.17520 74 25.17760 75 25.18000 76 25.18240 77 25.18480 78 25.18720 79 25.18960 80 25.19200 81 25.19440 82 25.19680 83 25.19920 84 25.20160 85 25.20400 86 25.20640 87 25.20880 88 25.21120 89 25.21360 90 25.21600 91 25.21840 92 25.22080 93 25.22320 94 25.22560 95 25.22800 96 25.23040 97 25.23280 98 25.23520 99 25.23760 100 25.24000 101 25.24240 102 25.24480 103 25.24720 104 25.24960 105 25.25200 106 25.25440 107 25.25680 108 25.25920 109 25.26160 110 25.26400 111 25.26640 112 25.26880 113 25.27120 114 25.27360 115 25.27600 116 25.27840 117 25.28080 118 25.28320 119 25.28560 120 25.28800 121 25.29040 122 25.29280 123 25.29520 124 25.29760 125 25.3 126 25.30240 127 25.30480 128 25.30720 129 25.30960 Why i get after the command: 4 25.109191 25.00960 5 25.199239 25.01200 6 25.289286 25.01440 7 25.384085 25.01680 8 25.474132 25.01920 9 25.56418 25.02160 10 25.654227 25.02400 11 25.744274 25.02640 12 25.834322 25.02880 13 25.929103 25.03120 14 26.01915 25.03360 15 26.109197 25.03600 16 26.199245 25.03840 17 26.289292 25.04080 18 26.384091 25.04320 19 26.474138 25.04560 20 26.564186 25.04800 21 26.654233 25.05040 22 26.74428 25.05280 23 26.834327 25.05520 24 26.929103 25.05760 25 27.01915 25.06000 45 27.109197 25.10800 82 27.199245 25.19680 (no more) Kindly, Tiago Junqueira ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: join bug?
Tiago Junqueira [EMAIL PROTECTED] writes: Why i get after the command: 4 25.109191 25.00960 Your input is not sorted. $ join --help [...] Important: FILE1 and FILE2 must be sorted on the join fields. E.g., use `sort -k 1b,1' if `join' has no options. 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: [PATCH] SEQ BUG
Paul Eggert wrote: Pádraig Brady [EMAIL PROTECTED] writes: OK, how about the attached patch? Better, but it still has problems. For example, on my platform (Debian stable with GCC 4.2.0, x86) the command seq 0.0 0.1 0.9000 outputs something different from seq 0.0 0.1 0.9. The former stops at 0.8, the latter at 0.9. You're stretching :) I'll see if I can fix that, but I do think it's much better that what we have currently. In general, if we want seq's numeric behavior to be independent of the format of the operand numbers, I think we have to take a different approach. Here's an idea. Use sprintf to convert the numbers to a textual format and back, and then use the result of _that_ comparison instead of the internal floating-point comparison. For speed, do this only for the number one past the number that seq would ordinarily print now. Also, don't bother to print this extra number if it's textually identical to the previously printed number. Whaddya think? I'll have another look. Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] SEQ BUG
Pádraig Brady wrote:
Paul Eggert wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
OK, how about the attached patch?
Better, but it still has problems. For example, on my platform
(Debian stable with GCC 4.2.0, x86) the command
seq 0.0 0.1 0.9000 outputs something different from
seq 0.0 0.1 0.9. The former stops at 0.8, the latter at 0.9.
You're stretching :)
I'll see if I can fix that,
The attached patch handles this by
only counting signficant digits from the operands.
Pádraig.
diff -Naur --exclude='*.o' coreutils/doc/coreutils.texi coreutils.pb/doc/coreutils.texi
--- coreutils/doc/coreutils.texi 2007-06-12 07:28:45.0 +
+++ coreutils.pb/doc/coreutils.texi 2007-06-12 07:42:01.0 +
@@ -14041,35 +14041,6 @@
18446744073709551618
@end example
-Be careful when using @command{seq} with a fractional @var{increment};
-otherwise you may see surprising results. Most people would expect to
-see @code{0.03} printed as the last number in this example:
-
[EMAIL PROTECTED]
-$ seq -s ' ' 0 0.01 0.03
-0.00 0.01 0.02
[EMAIL PROTECTED] example
-
-But that doesn't happen on many systems because @command{seq} is
-implemented using binary floating point arithmetic (via the C
[EMAIL PROTECTED] double} type)---which means decimal fractions like @code{0.01}
-cannot be represented exactly. That in turn means some nonintuitive
-conditions like @[EMAIL PROTECTED] * 3 0.03}} will end up being true.
-
-To work around that in the above example, use a slightly larger number as
-the @var{last} value:
-
[EMAIL PROTECTED]
-$ seq -s ' ' 0 0.01 0.031
-0.00 0.01 0.02 0.03
[EMAIL PROTECTED] example
-
-In general, when using an @var{increment} with a fractional part, where
-(@var{last} - @var{first}) / @var{increment} is (mathematically) a whole
-number, specify a slightly larger (or smaller, if @var{increment} is negative)
-value for @var{last} to ensure that @var{last} is the final value printed
-by seq.
-
@exitstatus
diff -Naur --exclude='*.o' coreutils/src/Makefile.am coreutils.pb/src/Makefile.am
--- coreutils/src/Makefile.am 2007-06-12 07:26:01.0 +
+++ coreutils.pb/src/Makefile.am 2007-06-12 06:43:29.0 +
@@ -97,7 +97,7 @@
printf_LDADD = $(LDADD) $(POW_LIB) $(LIBICONV)
# If necessary, add -lm to resolve use of pow in lib/strtod.c.
-seq_LDADD = $(LDADD) $(POW_LIB)
+seq_LDADD = $(LDADD) $(SEQ_LIBM)
# If necessary, add libraries to resolve the `pow' reference in lib/strtod.c
# and the `nanosleep' reference in lib/xnanosleep.c.
diff -Naur --exclude='*.o' coreutils/src/seq.c coreutils.pb/src/seq.c
--- coreutils/src/seq.c 2007-06-11 10:20:57.0 +
+++ coreutils.pb/src/seq.c 2007-06-20 15:00:43.0 +
@@ -21,6 +21,7 @@
#include getopt.h
#include stdio.h
#include sys/types.h
+#include math.h
#include system.h
#include c-strtod.h
@@ -118,6 +119,9 @@
/* Number of digits after the decimal point, or INT_MAX if the
number can't easily be expressed as a fixed-point number. */
int precision;
+
+ /* Number of significat digits after the decimal point */
+ int significant;
};
typedef struct operand operand;
@@ -136,23 +140,37 @@
}
ret.width = strlen (arg);
- ret.precision = INT_MAX;
+ ret.significant = ret.precision = INT_MAX;
- if (! arg[strcspn (arg, eExX)] isfinite (ret.value))
+ if (! arg[strcspn (arg, xX)] isfinite (ret.value))
{
char const *decimal_point = strchr (arg, '.');
if (! decimal_point)
- ret.precision = 0;
+ ret.significant = ret.precision = 0;
else
{
- size_t fraction_len = strlen (decimal_point + 1);
+ size_t fraction_len = strcspn (decimal_point+1, eE);
if (fraction_len = INT_MAX)
- ret.precision = fraction_len;
+ {
+ ret.significant = ret.precision = fraction_len;
+ const char* zeros = decimal_point + fraction_len;
+ while (*zeros-- == '0')
+ ret.significant--;
+ }
ret.width += (fraction_len == 0
? -1
: (decimal_point == arg
|| ! ISDIGIT (decimal_point[-1])));
}
+ char const *e = strchr(arg, 'e');
+ if (!e) e = strchr(arg, 'E');
+ if (e)
+ {
+ long exponent = strtol (e+1, NULL, 10);
+ ret.precision += exponent 0 ? -exponent: 0;
+ ret.significant -= exponent;
+ ret.significant = MIN (0, ret.significant);
+ }
}
return ret;
@@ -225,6 +243,24 @@
fputs (terminator, stdout);
}
+/* Calculate adjustment to last value so that inexactness
+ in floating point representation is not significant
+ when comparing against the last value */
+static long double
+get_last_adjustment (operand first, operand step, operand last)
+{
+ int prec=0;
+ prec = (first.significant != INT_MAX ? MAX (prec, first.significant): prec);
+ prec = (step.significant != INT_MAX ? MAX (prec, step.significant) : prec);
+ prec = (last.significant != INT_MAX ? MAX (prec, last.significant) : prec);
+ if (prec)
+{
+ long
Re: cp alphabetical
It would copy all the albums in alphabetical order, to the same target directory!!. I am interested in having the same directories structure in the player too, i.e: artist1/album1, etc. On 6/19/07, Matthew Woehlke [EMAIL PROTECTED] wrote: Andrés Ghigliazza wrote: I use wildcards for copying alphabetical, but it would be much more easy to copying alphabetical with -r option. ...and Pádraig Brady wrote: find /src | sort | xargs cp --target-directory=/flash How does that not accomplish what you want? -- Matthew Five is right out! -- Cleric (from Monty Python's Quest for the Holy Grail) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fwd: wrong color for broken symlinks
o_O ok, was fixed already... On 6/20/07, Jim Meyering [EMAIL PROTECTED] wrote: Andreas Frische [EMAIL PROTECTED] wrote: as of ls (GNU coreutils) 6.9 this bug is still not fixed. ls --color | od -tx1z 000 1b 5b 30 30 6d 1b 5b 30 31 3b 33 36 6d 74 65 73 .[00m.[01;36mtes 020 74 1b 5b 30 30 6d 40 0a 1b 5b 6d [EMAIL PROTECTED] 033 ls --color test | od -tx1z 000 1b 5b 30 30 6d 1b 5b 34 30 3b 33 31 3b 30 31 6d .[00m.[40;31;01m 020 74 65 73 74 1b 5b 30 30 6d 40 0a 1b 5b 6d[EMAIL PROTECTED] 036 Please try a snapshot: http://meyering.net/cu/coreutils-6.9+.tar.gz You're probably seeing a bug that's already fixed for the next release. Here's the NEWS entry: 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] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp alphabetical
Andrés Ghigliazza wrote: It would copy all the albums in alphabetical order, to the same target directory!!. I am interested in having the same directories structure in the player too, i.e: artist1/album1, etc. untested: find /src | sort | xargs cp --parents --target-directory=/flash Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp alphabetical
I will test it later. Pádraig, Matthew, thanks very much. On 6/20/07, Matthew Woehlke [EMAIL PROTECTED] wrote: Pádraig Brady wrote: Andrés Ghigliazza wrote: It would copy all the albums in alphabetical order, to the same target directory!!. I am interested in having the same directories structure in the player too, i.e: artist1/album1, etc. untested: find /src | sort | xargs cp --parents --target-directory=/flash You beat me to it, but I did test, and it WFM. Another note: find /src -print0 | sort -z | xargs -0 cp [...args...] ...won't break if/when your file names have spaces in them. -- Matthew Nobody expects the Spanish Inquisition! -- Monty Python ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp alphabetical
It works perfectly!! Thanks very much. On 6/20/07, Andrés Ghigliazza [EMAIL PROTECTED] wrote: I will test it later. Pádraig, Matthew, thanks very much. On 6/20/07, Matthew Woehlke [EMAIL PROTECTED] wrote: Pádraig Brady wrote: Andrés Ghigliazza wrote: It would copy all the albums in alphabetical order, to the same target directory!!. I am interested in having the same directories structure in the player too, i.e: artist1/album1, etc. untested: find /src | sort | xargs cp --parents --target-directory=/flash You beat me to it, but I did test, and it WFM. Another note: find /src -print0 | sort -z | xargs -0 cp [...args...] ...won't break if/when your file names have spaces in them. -- Matthew Nobody expects the Spanish Inquisition! -- Monty Python ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
