bug#36901: Enhance directory and file moves where target already exists
It's not a wish list that 'mv' doesn't work as documented. On 2019/08/02 22:45, Assaf Gordon wrote: > severity 36901 wishlist > retitle 36901 mv: merge directories where target already exists > stop > > Hello, > > (for context: this is a new topic, diverged at https://bugs.gnu.org/36831#38 ) > > For completeness, quoting your second message ( from > https://bugs.gnu.org/36831#50 ): > > On 2019-08-02 9:56 p.m., L A Walsh wrote: >> On 2019/08/02 19:47, Assaf Gordon wrote: >>> Can new merging features be added to 'mv'? yes. >>> But it seems to me these would be better suited for 'higher level' >>> programs (e.g. a GUI file manager). >> --- >> But neither the person who posted the original bug on this >> nor I are using a GUI, we are running 'mv' GUI, we use the cmd line on >> linux, so that wouldn't >> be of any use. >> >> If the command was named 'ren', then I'd expect it to be dummer, >> but 'mv'/move seem like it should be able to move files from >> one dir into another. >> >> But you say posix wants it to perform as a rename? >> I know, create a 're' command (or 'rn') for rename, and have >> it do what 'mv' would do. Maybe posix would realize it would >> be better to have re/rn behave like rename, and 'mv' to >> behave it was moving something. >> >> So if I have: >> mkdir A B >> touch A/foo B/fee >> >> So when I look at the system call on linux for rename: >> oldpath can specify a directory. In this case, newpath must >> either not >> exist, or it must specify an empty directory. >> (complying with POSIX_C_SOURCE >= 200809L) >> >> So move should give an error: Nope: >> >> mv A B >>> tree B >> B >> ├── A >> │ └── foo >> └── fee >> >> 1 directory, 2 files >> >> So mv is violating POSIX - it didn't do the rename, but moved >> A under B and neither dir had to be empty. >> >> Saying it has to follow POSIX when it doesn't appear to, seems >> a bit contradictory? >> > >
bug#36901: Enhance directory and file moves where target already exists
severity 36901 wishlist retitle 36901 mv: merge directories where target already exists stop Hello, (for context: this is a new topic, diverged at https://bugs.gnu.org/36831#38 ) For completeness, quoting your second message ( from https://bugs.gnu.org/36831#50 ): On 2019-08-02 9:56 p.m., L A Walsh wrote: > > On 2019/08/02 19:47, Assaf Gordon wrote: >> Can new merging features be added to 'mv'? yes. >> But it seems to me these would be better suited for 'higher level' >> programs (e.g. a GUI file manager). > --- > But neither the person who posted the original bug on this > nor I are using a GUI, we are running 'mv' GUI, we use the cmd line on > linux, so that wouldn't > be of any use. > > If the command was named 'ren', then I'd expect it to be dummer, > but 'mv'/move seem like it should be able to move files from > one dir into another. > > But you say posix wants it to perform as a rename? > I know, create a 're' command (or 'rn') for rename, and have > it do what 'mv' would do. Maybe posix would realize it would > be better to have re/rn behave like rename, and 'mv' to > behave it was moving something. > > So if I have: > mkdir A B > touch A/foo B/fee > > So when I look at the system call on linux for rename: > oldpath can specify a directory. In this case, newpath must > either not > exist, or it must specify an empty directory. > (complying with POSIX_C_SOURCE >= 200809L) > > So move should give an error: Nope: > > mv A B >> tree B > B > ├── A > │ └── foo > └── fee > > 1 directory, 2 files > > So mv is violating POSIX - it didn't do the rename, but moved > A under B and neither dir had to be empty. > > Saying it has to follow POSIX when it doesn't appear to, seems > a bit contradictory? >
bug#36831: Enhance directory move. (was Re: bug#36831: enhance 'directory not empty' message)
Hello, On 2019-08-02 9:56 p.m., L A Walsh wrote: On 2019/08/02 19:47, Assaf Gordon wrote: Can new merging features be added to 'mv'? yes. But it seems to me these would be better suited for 'higher level' programs (e.g. a GUI file manager). --- But neither the person who posted the original bug on this nor I are using a GUI, we are running 'mv' GUI, we use the cmd line on linux, so that wouldn't be of any use. The original post was about the error *message*, asking to make it clearer. That is the topic of this thread (and the previous patch) - so let's leave them at that. I see you started a new thread ( https://bugs.gnu.org/36901 ), so I'll reply there.
bug#36831: Enhance directory move. (was Re: bug#36831: enhance 'directory not empty' message)
On 2019/08/02 19:47, Assaf Gordon wrote: > Can new merging features be added to 'mv'? yes. > But it seems to me these would be better suited for 'higher level' > programs (e.g. a GUI file manager). --- But neither the person who posted the original bug on this nor I are using a GUI, we are running 'mv' GUI, we use the cmd line on linux, so that wouldn't be of any use. If the command was named 'ren', then I'd expect it to be dummer, but 'mv'/move seem like it should be able to move files from one dir into another. But you say posix wants it to perform as a rename? I know, create a 're' command (or 'rn') for rename, and have it do what 'mv' would do. Maybe posix would realize it would be better to have re/rn behave like rename, and 'mv' to behave it was moving something. So if I have: mkdir A B touch A/foo B/fee So when I look at the system call on linux for rename: oldpath can specify a directory. In this case, newpath must either not exist, or it must specify an empty directory. (complying with POSIX_C_SOURCE >= 200809L) So move should give an error: Nope: mv A B > tree B B ├── A │ └── foo └── fee 1 directory, 2 files So mv is violating POSIX - it didn't do the rename, but moved A under B and neither dir had to be empty. Saying it has to follow POSIX when it doesn't appear to, seems a bit contradictory?
bug#36901: Enhance directory and file moves where target already exists
Reposting this, since I realize that fixing the target-exists cases with a helpful algorithm could change or eliminate many cases where where now the user gets an error instead. On 2019/07/28 23:28, Assaf Gordon wrote: > > > $ mkdir A B B/A > $ touch A/bar B/A/foo > $ mv A B > mv: cannot move 'A' to 'B/A': Directory not empty > > And the reason (as you've found out) is that the target directory 'B/A' > is not empty (has the 'foo' file in it). > Had this been allowed, moving 'A' to 'B/A' would result in the 'foo' > file disappearing. > --- Why must foo disappear? Microsoft Windows handles this situation by telling the user that the target directory already exists and giving the option to *MERGE* the directories. If you attempt to move a file into a directory that already contains a file by the same name, it pops up another notice asking if you want to replace the old with the new, keep it as it is (file won't be moved and in this case, old directory would still exist with the unmoved files left in it), or keep both with the new file getting a name variant (like foo.exe -> foo_1.exe, keeping the extension the same so as to not mess up the identity of the contents. But in all the cases, a file with a non-conflicting name wouldn't disappear from the target.
bug#36831: Enhance directory move. (was Re: bug#36831: enhance 'directory not empty' message)
Hello, On Fri, Aug 02, 2019 at 02:41:31AM -0700, L A Walsh wrote: > On 2019/07/28 23:28, Assaf Gordon wrote: > > > > > > $ mkdir A B B/A > > $ touch A/bar B/A/foo > > $ mv A B > > mv: cannot move 'A' to 'B/A': Directory not empty > > > > And the reason (as you've found out) is that the target directory 'B/A' > > is not empty (has the 'foo' file in it). > > Had this been allowed, moving 'A' to 'B/A' would result in the 'foo' > > file disappearing. > > > --- > Why must foo disappear? > > Microsoft Windows handles this situation by telling the user that > the target directory already exists and giving the option to *MERGE* > the directories. > > If you attempt to move a file into a directory that already contains > a file by the same name, it pops up another notice asking [...] Certainly, GUI programs (and more 'feature-rich' programs than 'mv') offer many "merging" options. I'm sure Midnight-Commander, KDE/Doplhine, XFCE/Thunar, Gnome/Nautilus and many other free software GUI file managers have some "merging" capabilities. But 'mv' is more basic and does not have this capability. Partly that is because it adheres to the POSIX standards, which mandates: "3. The mv utility shall perform actions equivalent to the rename() function [...]" https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html Some rsync options (--remove-source-files) can mimick 'mv' with merging, but then they are more like "copy+delete" than actual "rename/move". Can new merging features be added to 'mv'? yes. But it seems to me these would be better suited for 'higher level' programs (e.g. a GUI file manager). regards, - assaf
bug#36899: [PATCH] dircolors: Recognize the WebP image format
* src/dircolors: Add .webp for the WebP image format --- src/dircolors.hin | 1 + 1 file changed, 1 insertion(+) diff --git a/src/dircolors.hin b/src/dircolors.hin index 3aa445bfa..9aa5b07da 100644 --- a/src/dircolors.hin +++ b/src/dircolors.hin @@ -158,6 +158,7 @@ EXEC 01;32 .m2v 01;35 .mkv 01;35 .webm 01;35 +.webp 01;35 .ogm 01;35 .mp4 01;35 .m4v 01;35 -- 2.22.0
bug#36887: coreutils-8.31: printf chokes on \u0041
On 2019/08/01 16:37, Paul Eggert wrote: > Ulrich Mueller wrote: > >> Except for the surrogates >> U+D800...U+DFFF, it looks like an arbitrary restriction >> > > It's not entirely arbitrary. Because of the restriction, coreutils printf > doesn't have to worry about what this command should do: > >printf '\u0025d\n' 1 2 > > Does this print a single line "%d", or two lines "1" and "2"? There are good > arguments either way, and one can easily construct even-stranger examples. > There are no format characters in the initial line, so only the 1st argument is interpreted. You can't do multiple interpretations since if you do there's no stopping point, (i.e. a hex-encode of a hex-encode of '%d\n')
bug#36831: Enhance directory move. (was Re: bug#36831: enhance 'directory not empty' message)
On 2019/07/28 23:28, Assaf Gordon wrote: > > > $ mkdir A B B/A > $ touch A/bar B/A/foo > $ mv A B > mv: cannot move 'A' to 'B/A': Directory not empty > > And the reason (as you've found out) is that the target directory 'B/A' > is not empty (has the 'foo' file in it). > Had this been allowed, moving 'A' to 'B/A' would result in the 'foo' > file disappearing. > --- Why must foo disappear? Microsoft Windows handles this situation by telling the user that the target directory already exists and giving the option to *MERGE* the directories. If you attempt to move a file into a directory that already contains a file by the same name, it pops up another notice asking if you want to replace the old with the new, keep it as it is (file won't be moved and in this case, old directory would still exist with the unmoved files left in it), or keep both with the new file getting a name variant (like foo.exe -> foo_1.exe, keeping the extension the same so as to not mess up the identity of the contents. But in all the cases, a file with a non-conflicting name wouldn't disappear from the target.
bug#36887: coreutils-8.31: printf chokes on \u0041
> On Fri, 02 Aug 2019, Paul Eggert wrote: > It's not entirely arbitrary. Because of the restriction, coreutils > printf doesn't have to worry about what this command should do: > printf '\u0025d\n' 1 2 Seems quite obvious, it should do the same as these commands: printf '\045d\n' 1 2 printf '\x25d\n' 1 2 This is different from C behaviour, because printf(3) doesn't deal with backslash escapes at all, which are interpreted earlier during parsing of the string literal. That's why I think the C reasoning doesn't apply here.
