Re: mv: Moving directories to themselves (not the bug with incorrect error message)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Michal Wencl on 11/18/2007 3:16 AM: mkdir -p a b/a touch a/1 a/2 b/a/2 move a b Current result: In my version of mv (5.97) the following error message is returned: Consider upgrading. The latest stable version of coreutils is 6.9, and it includes some bug fixes for mv. Expected result: Directory a is fully moved to directory b/a, thus b/a contains files 1 and 2 where b/a/2 was overwritten witch a/2. Wrong. POSIX doesn't allow this behavior. In order to move directory a to a subdirctory of b, when b/a already exists, b/a must be unlinkable; but since b/a is not empty, it can't be unlinked. Could you think about it, please? It would be great if at least a switch for it was added to mv (and other coreutils). What you appear to be wanting is a new option to mv, maybe spelled like 'mv --merge'. But such a feature is not part of coreutils yet, because no one has submitted a patch for it. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQDw684KuGfSFAYARAvTiAJ4iBg1Ao0I16Y4vcxSIrtJJ4aeUUwCdGOd1 fUxP2Kr0h+vbSm0mRrjD8mQ= =z0MJ -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv: Moving directories to themselves (not the bug with incorrect error message)
Hi. I'm not sure if this is a bug, feature, todo, or a change request but I think the current behaviour is not expected for most people. At least not for those coming from Windows. My scenario: mkdir -p a b/a touch a/1 a/2 b/a/2 move a b Current result: In my version of mv (5.97) the following error message is returned: mv: cannot move `a' to a subdirectory of itself, `b/a' I know it was changed to a more meaningful message in later version but this is not the problem. Expected result: Directory a is fully moved to directory b/a, thus b/a contains files 1 and 2 where b/a/2 was overwritten witch a/2. Moreover, this is how mv works if b/a doesn't exist yet. It creates b/a and moves a/* inside. Could you think about it, please? It would be great if at least a switch for it was added to mv (and other coreutils). Thanks, Michal Wencl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: Moving directories to themselves (not the bug with incorrect error message)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 11/18/2007 6:20 AM: Could you think about it, please? It would be great if at least a switch for it was added to mv (and other coreutils). What you appear to be wanting is a new option to mv, maybe spelled like 'mv --merge'. But such a feature is not part of coreutils yet, because no one has submitted a patch for it. As a followup, I'm pretty sure rsync already does what you are looking for, so why bloat mv to do something that can be done with another tool? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQD1I84KuGfSFAYARAtehAKCKcuXr5P3lcuvPQmT+iprw4LWmIQCfdCyl L3aMb0bqHSlTSZ2VcJ0xgnM= =TTAH -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: Moving directories to themselves (not the bug with incorrect error message)
As a followup, I'm pretty sure rsync already does what you are looking for, so why bloat mv to do something that can be done with another tool? Thanks for a quick answer. I didn't study rsync deeply yet but I understand it as a copy utility that temporarily takes filesystem space and wears down a storage medium when moving files to another directory. That is not necessary (it's unwanted) in this case. The mv --merge you proposed might still be useful. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Jim Meyering [EMAIL PROTECTED] writes:
Dan Nicolaescu [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Dan Nicolaescu [EMAIL PROTECTED] wrote:
...
I created a new account with /bin/tcsh as a shell, deleted all the
dot
files in that new account, logged in on a linux console and run the
perl command above. It prints IGNORE.
tcsh is: tcsh-6.14-15
perl is: perl-5.8.8-23.fc7
Finally! So that version of tcsh may be at fault.
I built tcsh-6.15 using the F8 rpm, and the problem still occurs with
that one.
When you tested this, did you try from an account that uses tcsh as
the shell? Because if I start tcsh from bash things work...
Yes. I changed my shell to /bin/tcsh and logged in again.
Have you tried on other systems?
I have installed Fedora 8 on another 32bit x86 system, and the problem
appears there too.
(I moved /etc/csh* out of the way, used a freshly created account that
uses /bin/tcsh. I also deleted all the ~/.* files)
I straced the mingetty process corresponding to VT 1, and logged on
there.
The only mention of SIGPIPE is this:
4549 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
4549 is the mingetty process.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: Moving directories to themselves (not the bug with incorrect error message)
Michal Wencl wrote: As a followup, I'm pretty sure rsync already does what you are looking for, so why bloat mv to do something that can be done with another tool? I didn't study rsync deeply yet but I understand it as a copy utility that temporarily takes filesystem space Rsync is a swiss-army-chainsaw tool. It has a zillion options and operating modes. But it is also often simply the best tool for the job too. Check out the --inplace option. It is not a perfect fit but may be enough. and wears down a storage medium when moving files to another directory. I think you are thinking of the work needed to compare two files between the client and the server. For individual runs it is unlikely to be a problem. It becomes a problem when a server is serving a large number of files to a large number of clients. The large number of processes all grinding away can be a problem. But in the single threaded case it is not much different from other file copy methods. That is not necessary (it's unwanted) in this case. The mv --merge you proposed might still be useful. If someone were to write a patch with a copyright assignment to the FSF so that it could be used I am sure that it would be considered. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: seq .1 .1 would mistakenly generate no output on FreeBSD 6.1
Jim Meyering wrote:
(gdb) p last
$4 = 0.1000135525271560688
(gdb) p x
$5 = 0.155511151231257827
That's odd, since X was set via this assignment:
x = first + i * step;
and I is zero, which means X should equal FIRST, and (with seq .1 .1)
FIRST should equal LAST. All the values in question have the type
long double so there shouldn't be any rounding error here.
I suspect the problem came up because FreeBSD has what I like to call
varying width floating point. That is, long double sometimes has
a 53-bit fraction, and sometimes a 64-bit fraction, depending on which
temporary happens to hold the long double value. This would explain
the problem, since the closest approximation to 0.1 with a 53-bit
fraction (IEEE double) is exactly
0.155511151231257827021181583404541015625, and with a
64-bit fraction (Intel extended) it's exactly
0.100013552527156068805425093160010874271392822265625,
and these numbers match the values shown above (modulo the finite
print width of GDB).
Varying width floating point conforms to C89, but it's a real hassle
to code portably to. For example, if you have code like this:
long double x = (something);
long double y = x;
you cannot assume that y == x. Here's another, more-drastic example:
long double x = (something);
long double y = (something_else);
assert (x == y || x != y);
The assertion might fail, since the first use of X might have a 64-bit
fraction, but the second might have a 53-bit fraction.
I looked at the revised print_numbers function and found what I think
is one or two other instances of similar problems. I hope the
following code will have a better chance of surviving similar problems
in the future. (The proposed code is a tad shorter and avoids some
code duplication and IF_LINT stuff; that's a good sign...)
2007-11-18 Paul Eggert [EMAIL PROTECTED]
* src/seq.c (print_numbers): Rewrite in an attempt to avoid the
more-general rounding issues exposed by the previous patch.
diff --git a/src/seq.c b/src/seq.c
index eec5ed5..261a44b 100644
--- a/src/seq.c
+++ b/src/seq.c
@@ -238,24 +238,32 @@ static void
print_numbers (char const *fmt, struct layout layout,
long double first, long double step, long double last)
{
- long double i;
- long double x0 IF_LINT (= 0);
+ bool out_of_range = (step 0 ? first last : last first);
- for (i = 0; /* empty */; i++)
+ if (! out_of_range)
{
- long double x = first + i * step;
+ long double x = first;
+ long double i;
- if (step 0 ? x last : last x)
+ for (i = 1; ; i++)
{
- /* If we go one past the end, but that number prints as a
-value equal to last, and prints differently from the
-previous number, then print last. This avoids problems
-with rounding. For example, with the x86 it causes seq
-0 0.01 0.03 to print 0.03 instead of
-stopping at 0.02. */
-
- if (i)
+ long double x0 = x;
+ printf (fmt, x);
+ if (out_of_range)
+ break;
+ x = first + i * step;
+ out_of_range = (step 0 ? x last : last x);
+
+ if (out_of_range)
{
+ /* If the number just past LAST prints as a value equal
+to LAST, and prints differently from the previous
+number, then print the number. This avoids problems
+with rounding. For example, with the x86 it causes
+seq 0 0.01 0.03 to print 0.03 instead
+of stopping at 0.02. */
+
+ bool print_extra_number = false;
long double x_val;
char *x_str;
int x_strlen = asprintf (x_str, fmt, x);
@@ -269,34 +277,20 @@ print_numbers (char const *fmt, struct layout layout,
char *x0_str = NULL;
if (asprintf (x0_str, fmt, x0) 0)
xalloc_die ();
- if (!STREQ (x0_str, x_str))
- {
- fputs (separator, stdout);
- fputs (x_str, stdout);
- }
+ print_extra_number = !STREQ (x0_str, x_str);
free (x0_str);
}
free (x_str);
+ if (! print_extra_number)
+ break;
}
- /* With floating point arithmetic, we may well reach this point
-with i == 0 and first == last. E.g., ./seq .1 .1 on FreeBSD 6.1.
-Hence the first conjunct: don't break out of this loop when
-i == 0. *unless* first and last themselves are out of order,
-in which case we must print nothing, e.g. for ./seq -1 */
- if (i || (0 step last first) || (step 0 first last))
- break;
+ fputs (separator, stdout);
}
-
