jida...@jidanni.org wrote:
Gentlemen, I object. The messages for these two commands should be different.
$ cp -v f g
`f' - `g'
$ mv -v f g
`f' - `g'
Exactly how different etc. I leave up to you. Maybe even just = for the
latter instead of -.
I think it's fine from the context as is?
If one
:56 PM
To: Halas, Miroslav
Cc: bug-coreutils@gnu.org
Subject: Re: mv doesn't respect --reply=no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Halas, Miroslav on 10/20/2009 3:54 PM:
This bus was encountered as part of mv.exe from coreutils 5.3.0 from
gnuwin project
Severely old
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Halas, Miroslav on 10/20/2009 3:54 PM:
This bus was encountered as part of mv.exe from coreutils 5.3.0 from
gnuwin project
Severely old. The latest version is 8.0. I'd recommend upgrading to
something a little more maintained, such
Jim Meyering wrote:
Maybe you want a new option to enable this behavior when
does not do an atomic rename, but it will never be the
efault, because it would cause a huge performance hit
when copying many files between devices.
True, it's the classic reliability vs performance tradeoff,
On Thu, 30 Apr 2009, Stefano Mersi wrote:
when trying to move a diretcory into itself the progam says in italian:
mv: impossibile spostare myDir in una sottodirectory di sé stessa,
myDir/myDir
There is a grammar error:
sé stessa should become se stessa
Please report translations bugs here:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Dennis Heuer on 3/30/2009 11:10 AM:
hello,
i just read the message as in the subject as i tried to archive some
web-pages. the problem with dropping this option is that there is no
alternative for --reply=no, if you think twice.
Hello Dennis,
On Monday 30 March 2009 19:10:11 Dennis Heuer wrote:
i just read the message as in the subject as i tried to archive some
web-pages. the problem with dropping this option is that there is no
alternative for --reply=no, if you think twice. this option is quite
helpful to not
Hello Mike,
there is an alternative: 'mv -n'. Which version of coreutils are you using?
What does 'mv --version' say?
Kamil
On Tuesday 03 March 2009 16:06:44 Mike McWilliam wrote:
Hello All
I have read many explainations why '--reply=no' does not
work as expected. I am
Richard Leeden wrote:
Since 7.1 I'm seeing an error message with mv when attempting to move files
from filesystems mounted on swap (such as /tmp and /var/run). I've only been
able to test on sparc Solaris and see the issue on Solaris 8 and 9 but not
on 10.
To reproduce:
roottouch /tmp/a
Jim Meyering wrote:
Thanks for the report.
However we'll need more information.
For example, what is the type of your destination file system?
If it's a local file system, df -hT . will tell you.
If it's NFS, it'd be good if you could tell us the OS of the server
as well as the type of
Richard Leeden wrote:
Jim Meyering wrote:
Thanks for the report.
However we'll need more information.
For example, what is the type of your destination file system?
If it's a local file system, df -hT . will tell you.
If it's NFS, it'd be good if you could tell us the OS of the server
as
Jim Meyering wrote:
Richard Leeden wrote:
Jim Meyering wrote:
Thanks for the report.
However we'll need more information.
For example, what is the type of your destination file system?
If it's a local file system, df -hT . will tell you.
If it's NFS, it'd be good if you could tell us
TL Mieszkowski t...@ftfa.us wrote:
I've needed to swap two filenames more than once,
but no UNIX program I can find does it.
The patch I've included works on two regular files,
one regular file and a directory, but if you provide two
directories or 1 directory first it trashes the first
[EMAIL PROTECTED] (Karl Berry) wrote:
$ mv foo
mv: missing destination file operand after `/u/karl/tmp/paper.ltx'
The destination operand doesn't have to be a file, it is often a
directory. So I suggest deleting file. Not that I will argue if you
decide not to :).
Hi Karl,
Thanks for the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 9/25/2008 1:24 AM:
mv: missing destination file operand after `/u/karl/tmp/paper.ltx'
However, file is often used not to distinguish between symlink,
directory, fifo, block device, etc, but rather to denote a generic
Eric Blake [EMAIL PROTECTED] wrote:
According to Jim Meyering on 9/25/2008 1:24 AM:
mv: missing destination file operand after `/u/karl/tmp/paper.ltx'
However, file is often used not to distinguish between symlink,
directory, fifo, block device, etc, but rather to denote a generic file
Jim Meyering [EMAIL PROTECTED] writes:
Removing the one-arg feature of ln is not an option, as I'm sure you
know. GNU ln has been that way for a very long time -- probably since
the beginning.
In fact, it's already in 2BSD. But both cp and mv always required at
least two arguments.
On Jan 28, 2008 12:45 AM, Bob Proulx [EMAIL PROTECTED] wrote:
For all distros perhaps being more aggressive at forwarding downstream
bugs to the upstream mailing list would be a good thing. I know that
I have not been doing that as much as I should.
I could not agree more. I often find that
Jim Meyering wrote:
Eric Blake wrote:
Meanwhile, would it be worth subscribing bug-coreutils to the debian bug
feed list? That way, this list would see bugs as they are reported, and
others besides Jim will be able to chime in with advice.
I know Bob Proulx is already subscribed there.
Eric Blake [EMAIL PROTECTED] wrote:
I've noticed that Jim just committed a patch based on a bug originally
reported through the debian tracker without any additional mention here:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=c0c8685
On Sat, Jan 26, 2008 at 07:23:08PM +0100, Jim Meyering wrote:
I know Bob Proulx is already subscribed there.
Some of the traffic would not be interesting, i.e., a message
announcing that a bug is closed, or tagged -- but those are easy to skip.
Overall, I think it would be better for both
-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
-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
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
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
Jonathan Lennox lennox at cs.columbia.edu writes:
On Cygwin using non-managed mounts (and presumably other operating systems
when using a case-insensitive file system), it's not possible to use
Coreutils mv to change the case of a filename; mv reports that they are the
same file.
There is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Elmar Stellnberger on 8/17/2007 1:13 PM:
package/version: coreutils-5.93-20
Consider upgrading. The latest stable coreutils is 6.9.
In this case the privileges suffice for creating a new directory entry
for the destination file
Eric Blake wrote:
[snip] Mac HFS is the other biggest case-preserving
case-insensitive system out there; can anyone comment on
whether rename(2) is a no-op or changes case when given two
case-wise distinct spellings of the same file?
Adding to what Jonathan already posted...
$ df -T .
On Thursday, August 16 2007, John Cowan wrote to Eric Blake, John Cowan,
Jonathan Lennox, bug-coreutils@gnu.org saying:
Eric Blake scripsit:
You missed my earlier remark - since POSIX requires case sensitivity,
a case-insensitive file system is not specified by POSIX, therefore,
a
Jonathan Lennox scripsit:
No, on Cygwin rename(2) will change file case:
Ah, sorry. I had mixed up what rename(2) does with what mv does.
--
First known example of political correctness: John Cowan
After Nurhachi had united all the other http://www.ccil.org/~cowan
Jurchen tribes
On Wednesday, August 15 2007, Eric Blake wrote to Jonathan Lennox,
bug-coreutils@gnu.org saying:
(I reported this issue on the bug tracker on Savannah, but it looks like
sending bug reports to this mailing list is preferred, so I'm repeating it
here.)
The bug-tracker forwards all edits
FAT is always upper case and the driver forces it to
lower case. VFAT ignores attempts to change case
with rename(), in conformity to Posix.
You missed my earlier remark - since POSIX requires
case sensitivity, a case-insensitive file system is not
specified by POSIX, therefore, a platform
Chris Moore [EMAIL PROTECTED] writes:
$ mv dir ..
mv: cannot move `dir' to a subdirectory of itself, `../dir'
With coreutils 6.9 you'll get Directory not empty.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP
Andreas Schwab wrote:
Chris Moore [EMAIL PROTECTED] writes:
$ mv dir ..
mv: cannot move `dir' to a subdirectory of itself, `../dir'
With coreutils 6.9 you'll get Directory not empty.
That also seems incorrect. Shouldn't the error be A file ( directory )
with that name already exists?
Phillip Susi [EMAIL PROTECTED] writes:
Andreas Schwab wrote:
Chris Moore [EMAIL PROTECTED] writes:
$ mv dir ..
mv: cannot move `dir' to a subdirectory of itself, `../dir'
With coreutils 6.9 you'll get Directory not empty.
That also seems incorrect. Shouldn't the error be A file (
(I reported this issue on the bug tracker on Savannah, but it looks like
sending bug reports to this mailing list is preferred, so I'm repeating it
here.)
The bug-tracker forwards all edits to this list, so you just repeated
yourself.
On Cygwin using non-managed mounts (and presumably
On Thu, Jun 14, 2007 at 06:18:38AM +0800, Dan Jacobson wrote:
$ mv /etc/motd /etc/lilo.conf
mv: overwrite `/etc/lilo.conf', overriding mode 0644? y
mv: cannot move `/etc/motd' to `/etc/lilo.conf': Permission denied
I would skip the first message, as isn't there no point in asking, as
it is
J Thanks for the bug report, but 5.97 is very close to a year old.
J You're wasting your time testing it, I think, because many changes
J have been made since then. Please try a recent version of coreutils.
J (More generally, before reporting a bug in any piece of software, it
J is advisabel to
On 3/23/07, Eric Blake [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The fact that you mailed the obsolete bug-fileutils list implies that you
may be due for an upgrade. fileutils merged into coreutils, and the
latest stable version is now 6.9.
Is it time perhaps to
[EMAIL PROTECTED] wrote:
Hello maintainers of the mv command,
I have a problem with the mv command.
I cannot rename a file to lower case.
I used mv because Konqueror also fails.
Is there an explanation to this issue?
Greetings, Fabian.
You're trying this on a USB key right?
They generally
James Youngman [EMAIL PROTECTED] wrote:
On 3/23/07, Eric Blake [EMAIL PROTECTED] wrote:
The fact that you mailed the obsolete bug-fileutils list implies that you
may be due for an upgrade. fileutils merged into coreutils, and the
latest stable version is now 6.9.
Is it time perhaps to
[EMAIL PROTECTED] wrote on 22-03-07 17:58:
Hello maintainers of the mv command,
I have a problem with the mv command.
I cannot rename a file to lower case.
I used mv because Konqueror also fails.
Is there an explanation to this issue?
Greetings, Fabian.
Yes! -- in fact there are many possible
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The fact that you mailed the obsolete bug-fileutils list implies that you
may be due for an upgrade. fileutils merged into coreutils, and the
latest stable version is now 6.9.
According to [EMAIL PROTECTED] on 3/22/2007 10:58 AM:
Hello maintainers
P But the only way to find out is to try. ACLs allow file systems to
P change their minds, so you don't know for sure whether the lunch was
P cancelled until you show up and try to eat. The same principle
P applies here.
Must be some ask permission before taking the candy vs. take the candy
and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Dan Jacobson on 3/15/2007 2:05 PM:
JM They're not bound to fail.
JM An alternate access method (e.g., an ACL) may allow it to succeed.
Does it cost much more to check first that too then before asking?
E.g., if I were a secretary, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 3/15/2007 6:17 PM:
Sorry, but POSIX requires the current behavior. If it bothers you that
much, then take it up with the Austin group with proposed wording that
allows your desired behavior without breaking 30 years of
Rich Morgan [EMAIL PROTECTED] writes:
I'm trying to move large files from one filesystem to another and the mv
command fails with the message File size limit exceeded. The partial
destination file is not removed and is 4,294,967,295 bytes in size.
Most likely that's not a bug in mv; it's a
Paul Eggert wrote:
Rich Morgan [EMAIL PROTECTED] writes:
I'm trying to move large files from one filesystem to another and the mv
command fails with the message File size limit exceeded. The partial
destination file is not removed and is 4,294,967,295 bytes in size.
Most likely
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please post questions about coreutils to the bug-coreutils list, as
requested in the 'mv --help' output, rather than sending private mail to
just one of the developers. You will then be more likely to get an answer
by someone who knows (the
On Wed, 7 Dec 2005, Vincent Chan wrote:
I have a bunched of files in a directory and there are a.avi and a.rar
in it. Inside the directory, there is also a directory called a. I
wanted to type mv a.* a. But instead I typed mv a.* by mistake. As
a result, I can't find the original a.rar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 11/30/2005 10:57 AM:
It does appear that POSIX does not specify what should happen when you
do this:
mkdir new
cd new
touch a
mv a b/c
That is, if b does not exist, then rename(a, b/c) is not
required to fail.
Hmm, I'm not familiar with that resolution. I looked for it in
http://www.opengroup.org/austin/aardvark/finaltext/xshbug.txt and
found that XSH Enhancement Request Number 108 talks about the y0()
function. Perhaps you got the number wrong? Or am I looking in the
wrong place?
You are
[EMAIL PROTECTED] (Eric Blake) writes:
You are looking at the pre-2004 defects; try looking at the current ones
http://www.opengroup.org/austin/aardvark/latest/xshbug2.txt
But ERN 108 in that URL refers to what happens with rename(a,
b/.), which obviously should fail. It doesn't really
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 11/29/2005 11:16 PM:
No, because POSIX requires that Write access permission is required
for the directory containing 'old' and the directory containing
'new'. Here 'new' is b/, which is equivalent to b/.. So the
Eric Blake [EMAIL PROTECTED] writes:
I maintain that Linux is still
POSIX-compliant by allowing rename(a, b/) to succeed
It does appear that POSIX does not specify what should happen when you
do this:
mkdir new
cd new
touch a
mv a b/c
That is, if b does not exist, then rename(a, b/c) is not
Paul Eggert [EMAIL PROTECTED] wrote:
I also would favor (B). But we certainly need testsuite additions to
ensure that we don't introduce future regressions against this decision.
OK, it'll be harder to test (B), since that relies on the test suite
knowing what rename() does. But I guess we
[EMAIL PROTECTED] (Bob Proulx) wrote:
Jim Meyering wrote:
Paul Eggert [EMAIL PROTECTED] wrote:
I also would favor (B). But we certainly need testsuite additions to
ensure that we don't introduce future regressions against this decision.
OK, it'll be harder to test (B), since that relies
Jim Meyering wrote:
Bob Proulx wrote:
Jim Meyering wrote:
Paul Eggert wrote:
OK, it'll be harder to test (B), since that relies on the test suite
knowing what rename() does. But I guess we can work around that.
It shouldn't be hard.
Just run a little perl snippet to determine
Note that the underlying rename would fail on Linux 2.6.x and *BSD
(but it'd succeed on Solaris 9 and 10):
$ touch a; rm -rf b; perl -e 'rename a, b/ or die $!'
The difference is whether a is a directory or a regular file.
When a is not a directory, I would expect rename(a, b/)
to fail
Tim Waugh [EMAIL PROTECTED] wrote:
On Tue, Nov 29, 2005 at 05:24:32PM +0100, Jim Meyering wrote:
Note that the underlying rename would fail on Linux 2.6.x and *BSD
(but it'd succeed on Solaris 9 and 10):
No, you're looking at a different case:
$ touch a; rm -rf b; perl -e 'rename a, b/
Eric Blake [EMAIL PROTECTED] writes:
I read that as rename() sees that a is a directory, so it resolves
b/ as b/. to ensure that b/ is not the pathname of a
non-directory (it isn't, since b/. does not exist), then can go
ahead
No, because POSIX requires that Write access permission is
Tim Waugh [EMAIL PROTECTED] writes:
rm -rf a b
mkdir a
mv a b/
fails on Linux with coreutils-5.93:
mv: target `b/' is not a directory: No such file or directory
In previous releases (such as 5.2.1) it has worked. The rename() call
is also happy with the trailing slash.
Is this a
[EMAIL PROTECTED] wrote:
I think there is a bug in the mv command. New files created by mv do not
inherit their parent directory's default ACL entries (if any), but retain
their original ACLs.
I have tested this behavoir on different distributions and filesystems
supporting acls.
We
Eric Blake [EMAIL PROTECTED] wrote:
According to Dr. David Alan Gilbert on 9/26/2005 11:17 AM:
$ mkdir a b
$ ln -s $PWD/a sym
$ mv sym/ b
mv: cannot move `sym/' to `b/sym': Not a directory
Nod. Perhaps the warning needs a warning that it can't be relied
on?
No, POSIX requires rename(sym/,
Jim Meyering [EMAIL PROTECTED] writes:
As you can imagine, I find the POSIX-required behavior to be senseless.
Two things.
First, I recall that you preferred the non-POSIX behavior because of
file name completion issues. But because we agitated about this a
while ago, Bash now does a better
[cc-ing bash-completion maintainer]
First, I recall that you preferred the non-POSIX behavior because of
file name completion issues. But because we agitated about this a
while ago, Bash now does a better job with file name completion. For
example, given this:
mkdir dir
ln -s
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
As you can imagine, I find the POSIX-required behavior to be senseless.
Two things.
First, I recall that you preferred the non-POSIX behavior because of
file name completion issues. But because we agitated about
[EMAIL PROTECTED] (Eric Blake) writes:
Why don't rm and rmdir have a --strip-trailing-slashes option?
I'd guess because that option is an ugly hack and we'd rather that the
problem went away
we should bring this up with the austin group.
Perhaps, but let's figure out what we want first.
[EMAIL PROTECTED] (Eric Blake) wrote:
As you can imagine, I find the POSIX-required behavior to be senseless.
The above behavior of non-POSIX rename, seen on Linux-2.6.x, is fine.
Now that Linux/glibc provides a sane rename function, I'm tempted
to make mv work in the above manner on all
On a related note, why don't rm and rmdir have a --strip-trailing-slashes
option?
Because as far as I know, there is no need.
Do you know of a system where `rmdir symlink/'
removes only the referent of the symlink?
Yes, cygwin (but again, that goes back to the rmdir(2) bug
in cygwin that
Jim Meyering [EMAIL PROTECTED] writes:
Do you know of a system where `rmdir symlink/'
removes only the referent of the symlink?
Lots of systems do that, I expect. Solaris 10 does, for example.
This is either with Solaris rmdir or coreutils 5.3.0 rmdir.
I wouldn't be surprised if core
Jim Meyering [EMAIL PROTECTED] writes:
I think the wrapper-induced overhead of an extra lstat imposed on losing
systems, but only for operands with a trailing slash, is bearable.
This is one of those `would be nice' things.
But I'm not in any big hurry, since Linux 2.6.x does it right.
Yes,
On a related note, why don't rm and rmdir have a --strip-trailing-slashes
option?
Because as far as I know, there is no need.
Do you know of a system where `rmdir symlink/'
removes only the referent of the symlink?
By a strict reading of
* Jim Meyering ([EMAIL PROTECTED]) wrote:
$ mkdir a b
$ ln -s $PWD/a sym
$ mv sym/ b
mv: cannot move `sym/' to `b/sym': Not a directory
The 'mv' is straight out of recent cvs. I'm in an ext3 filesystem
on Linux (Ubuntu).
Am I misunderstanding something about that warning or is
Dr. David Alan Gilbert [EMAIL PROTECTED] wrote:
In the info pages for 'mv' is the following statement:
---
_Warning_: If you try to move a symlink that points to a directory,
and you specify the symlink with a trailing
Thomas Rachel wrote:
I recently deteted that if I use mv --reply=no, it doesn't behave as if I
pressed 'n' on mv -i.
This has become a hot topic. Please read this thread to catch up on
the happenings.
http://lists.gnu.org/archive/html/bug-coreutils/2005-06/msg00160.html
Bob
Christian Boltz wrote:
I just found a bug in mv: it overwrites files even when --reply=no is
given (which should never overwrite existing files according to the
documentation).
This has become a hot topic. Please read this thread to catch up on
the happenings.
[EMAIL PROTECTED] wrote:
The date bug of mv is still present in
mv (coreutils) 5.2.1
distributed with Fedore Core 3. When superuser moves a
directory into a another directory, the date of the former
directory changes to the current date.
The date of the directory is updated
Paul Eggert wrote:
Urs Thuermann [EMAIL PROTECTED] writes:
lstat64(bar, 0xb904) = -1 ENOENT (No such file or directory)
rename(foo, bar)= 0
This check, however, is not sufficient as a file named bar could be
created between the calls to lstat(2) and
[EMAIL PROTECTED] (Bob Proulx) writes:
I think the reason for the question might be for what purpose is the
lstat() call there? It is there to tell if the destination is a
directory and if so then it converts the rename to a rename to a
file in the subdirectory, also as required by POSIX.
Urs Thuermann [EMAIL PROTECTED] writes:
$ strace mv foo bar
Hmm, your email's Subject: line says mv -f but this strace doesn't.
I'll assume for now that you meant to write about plain mv, not mv -f.
lstat64(bar, 0xb904) = -1 ENOENT (No such file or directory)
rename(foo,
[EMAIL PROTECTED] (Eric Blake) wrote:
This may be worthy of raising an issue with the austin group, but I
thought I'd ask here first. A complaint was raised on the cygwin list
that the following sequence had no interactive prompt:
$ uname
CYGWIN_NT-5.0
$ touch a
$ ln a b
$ mv -i a b
$
My patch of Monday (2004-10-18) was wrong.
Here's a fix that introduces fewer bugs.
I've added a test for the cross-partition mv failure
and another that makes rm fail with Monday's patch.
2004-10-21 Jim Meyering [EMAIL PROTECTED]
* tests/mv/leak-fd: New file.
*
Cyril Bouthors [EMAIL PROTECTED] wrote:
I'm having problems when moving everything from a directory that
contains 10852 top level directories and a total of ~30+ files and
subdirectories with this command:
Thanks a lot for that report.
It is indeed a bug.
Here's the fix:
Plug a
Paul Eggert [EMAIL PROTECTED] wrote:
Here's how I reproduced it, both with coreutils 5.2.1 and with CVS
coreutils. On my host, /tmp and /home are different file systems;
this is a crucial part of the bug.
ulimit -n 1024
cd /home/eggert/junk
mkdir foo /tmp/foo
cd foo
for f
Cyril Bouthors wrote:
I'm having problems when moving everything from a directory that
contains 10852 top level directories and a total of ~30+ files and
subdirectories with this command:
# mv * ../../../webalizer-clients/
It fails with:
mv: cannot create regular file
[EMAIL PROTECTED] (Bob Proulx) writes:
I am unable to reproduce the problem locally.
I think your attempt didn't capture all the relevant parts of the bug.
Here's how I reproduced it, both with coreutils 5.2.1 and with CVS
coreutils. On my host, /tmp and /home are different file systems;
this
Never mind, my mistake.
After reading the SuS spec another 10 times i realise i was taking parts
out of context.
Glenn
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Tim Waugh [EMAIL PROTECTED] wrote:
With coreutils-5.2.1, I see unexpected behaviour with mv -i
--reply=no:
$ rm -rf x
$ mkdir -p x/a x/b
$ cd x
$ echo a a/foo
$ echo b b/foo
$ mv -i --reply=no a/foo b/foo
$ cat b/foo
a
That's because -i is equivalent to --reply=query (as mentioned in
Jim Meyering [EMAIL PROTECTED] wrote:
Tim Waugh [EMAIL PROTECTED] wrote:
$ echo a a/foo
$ echo b b/foo
$ mv -i --reply=no a/foo b/foo
$ cat b/foo
a
That's because -i is equivalent to --reply=query (as mentioned in --help),
and since you specify --reply=no after -i,
the --reply=no takes
On Thu, Apr 15, 2004 at 11:41:33AM -0400, Paul Jarc wrote:
I think that's what Tim expected. But b/foo was replaced with a/foo,
in spite of --reply=no. The same thing happens for me with 5.2.1.
Well, I didn't expect --reply=no to override the -i; I had thought
(without reading the
[EMAIL PROTECTED] (Paul Jarc) wrote:
Jim Meyering [EMAIL PROTECTED] wrote:
Tim Waugh [EMAIL PROTECTED] wrote:
$ echo a a/foo
$ echo b b/foo
$ mv -i --reply=no a/foo b/foo
$ cat b/foo
a
That's because -i is equivalent to --reply=query (as mentioned in --help),
and since you specify
I forgot to say that this is also on GNU/Hurd. Sorry for that.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Have you perhaps hacked ls.c so that it always prints the `author'
name?
Nope, this is a pristine checkout from CVS.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Alfred M. Szmidt [EMAIL PROTECTED] wrote:
From todays CVS the following test(s) fail (full log, so scroll down a bit):
...
Have you perhaps hacked ls.c so that it always prints the `author' name?
It seems like something like that is causing these differences: e.g.,
- 1 cp loc_reg rem_sl [cp:
Jim Meyering [EMAIL PROTECTED] wrote:
Iida Yosiaki [EMAIL PROTECTED] wrote:
It seems for me that mv in coreutils 4.5.8 failes to move files
in a certain condition.
* How to reproduce the bug.
...
Thank you for the very nice bug report!
To reassure anyone who might be worrying about
96 matches
Mail list logo
