GNU bug report logs -
#26971
mu -v output ordering looks impossible
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26971 in the body.
You can then email your comments to 26971 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Wed, 17 May 2017 20:30:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Wed, 17 May 2017 20:30:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I do
mv -v /home/jidanni/jidanni.org/location/grow/programs /tmp
and see
'/home/jidanni/jidanni.org/location/grow/programs' -> '/tmp/programs'
'/home/jidanni/jidanni.org/location/grow/programs/grow.tgz' -> '/tmp/programs/grow.tgz'
removed '/home/jidanni/jidanni.org/location/grow/programs/grow.tgz'
removed directory '/home/jidanni/jidanni.org/location/grow/programs'
but isn't that a rather impossible sequence? At least the first two?
Well I don't know the best way to write it.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Wed, 17 May 2017 20:56:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 26971 <at> debbugs.gnu.org (full text, mbox):
On 17/05/17 21:19, 積丹尼 Dan Jacobson wrote:
> I do
> mv -v /home/jidanni/jidanni.org/location/grow/programs /tmp
So this is working across file systems
> and see
> '/home/jidanni/jidanni.org/location/grow/programs' -> '/tmp/programs'
create dir /tmp/programs
> '/home/jidanni/jidanni.org/location/grow/programs/grow.tgz' -> '/tmp/programs/grow.tgz'
copy file grow.tgz
> removed '/home/jidanni/jidanni.org/location/grow/programs/grow.tgz'
> removed directory '/home/jidanni/jidanni.org/location/grow/programs'
obvious
> but isn't that a rather impossible sequence? At least the first two?
> Well I don't know the best way to write it.
I suppose we could distinguish the creation operations, though
note if the first attempted rename() worked for the source dir,
then there would have been just a single operation output like:
'/home/jidanni/jidanni.org/location/grow/programs' -> '/tmp/programs'
So the create operations are implicit in the reported remove operations.
Therefore there is nothing ambiguous here I think.
cheers,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Wed, 17 May 2017 21:47:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 26971 <at> debbugs.gnu.org (full text, mbox):
PB> So this is working across file systems
Yes.
>> '/home/jidanni/jidanni.org/location/grow/programs' -> '/tmp/programs'
This says to me "I, the mv command, have just moved A to B.
PB> create dir /tmp/programs
If that (create B) is what it is doing in that step, then it should not
mention the unrelated A.
>> '/home/jidanni/jidanni.org/location/grow/programs/grow.tgz' -> '/tmp/programs/grow.tgz'
This says to me "I am moving A/C to B/C". But there is no more A... at
least that is what the user thinks... so how could it still move it.
PB> I suppose we could distinguish the creation operations, though
PB> note if the first attempted rename() worked for the source dir,
PB> then there would have been just a single operation output like:
PB> '/home/jidanni/jidanni.org/location/grow/programs' -> '/tmp/programs'
Well all I know is if the user always can do something on one line, then he
would expect a consistent number of -v output lines.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Wed, 17 May 2017 21:53:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 26971 <at> debbugs.gnu.org (full text, mbox):
On 05/17/2017 01:55 PM, Pádraig Brady wrote:
> there is nothing ambiguous here
Although it's not ambiguous it is a bit confusing for non-experts, and
part of the point of -v is to help non-experts.
Reply sent
to
Pádraig Brady <P <at> draigBrady.com>
:
You have taken responsibility.
(Thu, 18 May 2017 01:13:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
:
bug acknowledged by developer.
(Thu, 18 May 2017 01:13:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 26971-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 17/05/17 22:46, 積丹尼 Dan Jacobson wrote:
> PB> So this is working across file systems
> Yes.
>>> '/home/jidanni/jidanni.org/location/grow/programs' -> '/tmp/programs'
> This says to me "I, the mv command, have just moved A to B.
>
> PB> create dir /tmp/programs
> If that (create B) is what it is doing in that step, then it should not
> mention the unrelated A.
>
>>> '/home/jidanni/jidanni.org/location/grow/programs/grow.tgz' -> '/tmp/programs/grow.tgz'
> This says to me "I am moving A/C to B/C". But there is no more A... at
> least that is what the user thinks... so how could it still move it.
>
>
> PB> I suppose we could distinguish the creation operations, though
> PB> note if the first attempted rename() worked for the source dir,
> PB> then there would have been just a single operation output like:
>
> PB> '/home/jidanni/jidanni.org/location/grow/programs' -> '/tmp/programs'
>
> Well all I know is if the user always can do something on one line, then he
> would expect a consistent number of -v output lines.
Well I'm not sure about having a consistent number of output lines,
but I do see that the output can be confusing. The attached patch
distinguishes the different operations for mv, as follows:
$ mkdir /tmp/mv-test && touch /tmp/mv-test/file
$ src/mv -v /tmp/mv-test .
created directory './mv-test'
copied '/tmp/mv-test/file' -> './mv-test/file'
removed '/tmp/mv-test/file'
removed directory '/tmp/mv-test'
$ src/mv -v mv-test mv-test-2
renamed 'mv-test' -> 'mv-test-2'
$ src/mv -v mv-test-2/file mv-test-2/file2
renamed 'mv-test-2/file' -> 'mv-test-2/file2'
cheers,
Pádraig
[mv-v-explicit.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Thu, 18 May 2017 09:00:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 26971 <at> debbugs.gnu.org (full text, mbox):
On 05/18/2017 03:11 AM, Pádraig Brady wrote:
> Subject: [PATCH] mv: distinguish copy and rename operations with --verbose
+1 looks nice, thanks.
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Thu, 18 May 2017 14:43:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 26971 <at> debbugs.gnu.org (full text, mbox):
On 05/17/2017 06:11 PM, Pádraig Brady wrote:
> created directory './mv-test'
> copied '/tmp/mv-test/file' -> './mv-test/file'
> removed '/tmp/mv-test/file'
> removed directory '/tmp/mv-test'
>
> $ src/mv -v mv-test mv-test-2
> renamed 'mv-test' -> 'mv-test-2'
If we're changing the format, I suggest having the output be useful as
input to the shell, like this:
$ src/mv -v /tmp/mv-test .
mkdir './mv-test'
cp '/tmp/mv-test/file' './mv-test/file'
rm '/tmp/mv-test/file'
rmdir '/tmp/mv-test'
$ src/mv -v mv-test mv-test-2
mv 'mv-test' 'mv-test-2'
This would be more useful. It would also be less confusing, since people who use 'mv' already know the syntax of 'mv' etc., whereas with the draft version they would need to deduce another syntax.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Thu, 18 May 2017 14:54:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 26971 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
> Am 18.05.2017 um 16:41 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> On 05/17/2017 06:11 PM, Pádraig Brady wrote:
>> created directory './mv-test'
>> copied '/tmp/mv-test/file' -> './mv-test/file'
>> removed '/tmp/mv-test/file'
>> removed directory '/tmp/mv-test'
>>
>> $ src/mv -v mv-test mv-test-2
>> renamed 'mv-test' -> 'mv-test-2'
>
> If we're changing the format, I suggest having the output be useful as input to the shell, like this:
>
> $ src/mv -v /tmp/mv-test .
> mkdir './mv-test'
> cp '/tmp/mv-test/file' './mv-test/file'
> rm '/tmp/mv-test/file'
> rmdir '/tmp/mv-test'
>
> $ src/mv -v mv-test mv-test-2
> mv 'mv-test' 'mv-test-2'
>
> This would be more useful. It would also be less confusing, since people who use 'mv' already know the syntax of 'mv' etc., whereas with the draft version they would need to deduce another syntax.
This could be interpreted as steps someone has to issue now to complete the command. Like the output of `ssh-agent`.
- Leave the output like it was initially.
- Introduce -vv to increase verbosity and output the above sequence.
-- Reuti
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Thu, 18 May 2017 15:05:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 26971 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/18/2017 09:41 AM, Paul Eggert wrote:
>
> If we're changing the format, I suggest having the output be useful as
> input to the shell, like this:
>
> $ src/mv -v /tmp/mv-test .
> mkdir './mv-test'
If we do this, you'd probably want to use:
mkdir -- './mv-test'
at least when the destination directory being moved into starts with -
rather than './'. You also have to be sure that the quoting style is
shell-appropriate (is that always the case currently, or can environment
preferences for quoting cause something that is not shell-valid?).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Thu, 18 May 2017 15:10:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 26971 <at> debbugs.gnu.org (full text, mbox):
On 05/18/2017 04:41 PM, Paul Eggert wrote:
> $ src/mv -v /tmp/mv-test .
> mkdir './mv-test'
> cp '/tmp/mv-test/file' './mv-test/file'
> rm '/tmp/mv-test/file'
> rmdir '/tmp/mv-test'
>
> $ src/mv -v mv-test mv-test-2
> mv 'mv-test' 'mv-test-2'
I think this may be confusing in longer shell output with "set -x":
+ src/mv -v /tmp/mv-test .
mkdir './mv-test'
cp '/tmp/mv-test/file' './mv-test/file'
rm '/tmp/mv-test/file'
rmdir '/tmp/mv-test'
+ src/mv -v mv-test mv-test-2
mv 'mv-test' 'mv-test-2'
so the user has to search for the leading "+" to see what really has
been executed. IMO the '->' style is a great eye-catcher in such
listings.
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Thu, 18 May 2017 21:43:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 26971 <at> debbugs.gnu.org (full text, mbox):
I'm fine with whatever you guys come up with, just don't
R> - Leave the output like it was initially.
else I'll just be back here five years later after forgetting the whole episode.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Thu, 18 May 2017 22:22:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 26971 <at> debbugs.gnu.org (full text, mbox):
On 05/18/2017 08:09 AM, Bernhard Voelker wrote:
> the '->' style is a great eye-catcher in such
> listings.
We could address that issue by outputting an eyecatching string at the
start of each -v output line. E.g.,:
+ src/mv -v /tmp/mv-test .
:;:; mkdir './mv-test'
:;:; cp '/tmp/mv-test/file' './mv-test/file'
:;:; rm '/tmp/mv-test/file'
:;:; rmdir '/tmp/mv-test'
+ src/mv -v mv-test mv-test-2
:;:; mv 'mv-test' 'mv-test-2'
or substitute something even more eyecatching for ":;:;".
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#26971
; Package
coreutils
.
(Thu, 18 May 2017 22:48:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 26971 <at> debbugs.gnu.org (full text, mbox):
I don't think you guys should invent new eye-catching strings.
Aren't there already standard ways to show what is going on under the
hood? Let's see, sh -x uses + and ++... strace uses... maybe just use '# '
comments.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 16 Jun 2017 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 307 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.