Received: (at 36901) by debbugs.gnu.org; 6 Aug 2019 19:14:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 06 15:14:39 2019 Received: from localhost ([127.0.0.1]:37781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hv4ur-0001PK-Lt for submit <at> debbugs.gnu.org; Tue, 06 Aug 2019 15:14:39 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:43853) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1hv4up-0001P6-0B for 36901 <at> debbugs.gnu.org; Tue, 06 Aug 2019 15:14:35 -0400 Received: from [192.168.101.10] ([93.218.111.19]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1M7sQ6-1i00rD3Xhy-004xjt; Tue, 06 Aug 2019 21:14:25 +0200 Subject: Re: bug#36901: Enhance directory and file moves where target already exists To: L A Walsh <coreutils@HIDDEN>, Assaf Gordon <assafgordon@HIDDEN> References: <5D4500CC.60404@HIDDEN> <20190803054557.GJ15401@HIDDEN> <5D451FE6.5090204@HIDDEN> <20190803061008.GK15401@HIDDEN> <5D4527F7.3060709@HIDDEN> From: Bernhard Voelker <mail@HIDDEN> Openpgp: preference=signencrypt Autocrypt: addr=mail@HIDDEN; prefer-encrypt=mutual; keydata= mQENBFPirzMBCACyzYldTjQ4ufFOkByY5Nn5USb5GFoL48nWBwNHjd9KUbtRRNlQiPNKd6hK Gvd3BGi5aoFKA4ytfRk6jbAbW3jVb3R8wYaV08mOy4KVEKxqN4bxsXlMjNChXVR+rtKDmfI+ oPTL+cPH2X6gW4W02IRbVw0uUhNm6zEedC/gNrY/mTlf1enZ46jxZ7BTUZaG+kx38UMISIMB zSzLRtdkwgmHj4jS3p1fF2cwRqLclIfMjKGpbNFPEXeXKWrCLcqHw78795eAR9q0YvrDkfIn GdDBwfb3VM4NdulwIFzvYZMSXvSbbyPLB5YkHU5aAWQHUse4WlfT5ccDpbzUYldRAvF9ABEB AAG0K0Jlcm5oYXJkIFZvZWxrZXIgPG1haWxAYmVybmhhcmQtdm9lbGtlci5kZT6JATkEEwEC ACMFAlPirzMCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBGUC73lpFxle5wCACC dbs0QaJ0vR3Sff2cKdTk41rUq3YfWngsR///IOU0C5DdkePmCnJE/lUsUy0LRTxcUDLxQR+x QHU8ssRT0JUO9726dI3miy36UdsgmBYaOtLvQcidGmW1R7o0PYYf04+TFtyqKgngOUBPpMgR 6o4UsQxy/OD4bN1WDqOgIjL+D/qJpkKmgp6L6+hhaBCpiOFKRmmV7YyQ3SqVlfQNiHs5ZtkR nXpIjgZARV+GllKucI17bO0CGmTJZ1tstVy0+W3DQT1lbBkTTc++5LONM99D3jjn23l1ocOp folR53F7I4cb2RNfT23v1I59RH37lB9wMOqrKj0UjYAC2YoPGQ3BuQENBFPirzMBCADXLWWp QihBldY6reca8ZKdc3T9qXEOa3akE3DWKztIBmNJhtYOjmpLYajQTkGa7UoJTnbmZE2Rn6ZE oNnvb0gcFNAIcY95KOI+bjOR8HEgh4cx2REXh6L6olIgyXqt/KFusE4wtVZAFxZl+30HzN6n D+1HvrjXxPJRX6MsIYOYyyX9/6OofwJK6QHODYGp8WL2olHDnmsXg4AT6Wlr7qKpKrQELlcF R4xkvdmgL/Ghw/tK0yJTxMIcewCCZWLPOXRmFRbvAadZWPAgVsJ63siNyUlVnVMSzDgTJl+s l/DMabXpqrJQx3/1Yy6mTaDs3XZT/wmBKaTLXx/LByaPxQQ7ABEBAAGJAR8EGAECAAkFAlPi rzMCGwwACgkQRlAu95aRcZWVPwgAqZT6iTXkoP37wYb41323RzhBcJ8JSk4cyBDBUXX0lMrM 3qhiClKG7phpxVdu817Gwc6Hsecg7FfjQAV8MHQ0ZFeEFdk3b2rKBqfsStc+h49/xF3Fb+if CzR9qeQF82fMSxkg18++7hMcHCMO/hPZ/Q0xRi+lrSr2QKDJQuLzSyVU14TxrCkevZjEhtma VNvcJlJzCbiBXee9Fpc5jITUXPFG8E8dxqo1n+duOyIMgozrAnzP7X5V/Ob/Ozf/aGGX9+Jd inyfCX18nWcHALKMU/36Eua/ylalf/2c2YkBp9KCLVmGgPkUgW52EeRPgroIsiwu+rwCSV6Z UyCJ+OymCg== Message-ID: <a293156f-13cb-9eab-91b0-f937d98ed9ba@HIDDEN> Date: Tue, 6 Aug 2019 21:14:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <5D4527F7.3060709@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:eQ+CTEPAHn1Wjmq8bxY9xtGFwqjEctdTh51MMA3GT3Aay7iQBYi hdqw4Wr6ROTd8jhRVQVG/silKgqUtM1mF6GVN6ws6TO3kTH5j1Q82Xqr8w7Ucu27QnNpWGm 1vkW2gxmrZQ98dYbC5F2I3N1DDyHIfw5zHmaZJwi+LMPGiloOuJM21oaJR+Y4az3GArl6SP 107GzP5AVDBs458BudcHA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:cjeOO6UJzxQ=:+WRMba/AQSEakCm6C6KPRA f5FyAggprJ8oRqLuv9upagFv3jQmn0ntyjd7bjuNl2kHQMw76YH0a7Jl4QlySXuqMnduzqJ7m GHxmT+g3jKGQY3rszIvRYJCfMAiV8iFO7WA4rlX62h8Ib/KHAPTygu6+lzJx9+xNui6OdbET4 HT4zR2qxyPh+ScFA0251vPBhJJ7E54T/iie5hVoQwOoGHWcaHixUMVVTBsgCyG7lgdS3B1+M8 pZ4nLLV8LXPl2AOhtTdhv8nAMPXy8dSYSiqbocEGJLXrPLG/YHg1PehAL41jDCW/ZurnZa7Yv 0BNQ2TKNlWQmrrA23TjhQnW3G4+mUj2rUso9CwQ3/PoTBsDp7dnVrLXJ6/fvHWbnNUokhwDV+ kYy4YOY+QD3vDJjYDpHzti6drYKH1mFB9u5Q2YwR2Co/znMZZUKpk3R4nkDXggtQT41mle1Uj xe9tbco/t6FyYcn/E72sWMtCnj4KhZGVz4DUgTpt7cWco6C3Hj8UXyssF/3VpWlqcx+YkmRAN gDTwUvkwRAw62VntLjeKE6VOc+/6EA7mKMZJk8fLbkwC7W5VgXqvUO2teoOauu7zD7GFaarLb hsqqMO8Nly9qbQG84C1EcUpj2NXR+EYUgkZC0Rnd8Iad6sTDnJOJmfWILYulPgrLweiB88I9m bFMeDGnR9pEu0lpbCwSlQUhpaLhdTpenQHagE/sUJuXZS+QRizIPSND7XDUC7OOoH7z4CzUqp T/Mk5Al/z8mfIcPurxXm++6HaU7aT4ncOnztqk+QDq52UpezIUvFLBrdMRFhNrVtZ1EoQCCE8 EBca7lP X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36901 Cc: 36901 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 8/3/19 8:21 AM, L A Walsh wrote: > On 2019/08/02 23:10, Assaf Gordon wrote: >> Specifically, at the top of the page: >> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html >> SYNOPSIS >> mv [-if] source_file target_file >> mv [-if] source_file... target_dir >> DESCRIPTION >> [...] >> In the second synopsis form, mv shall move each file named by a >> source_file operand to a destination file in the existing directory >> named by the target_dir operand [...] This second form is assumed >> when the final operand names an existing directory >> >> In this regard GNU 'mv' is compliant with POSIX. [...] > mkdir A B > touch A/foo B/fee > mv A B > > It B exists and is not empty. Ergo, it is not following the > requirement that the directory must be empty or not exist. There no such condition in the POSIX citation (nor in the whole mv(1) spec) about whether 'B' is empty or not. The question is whether the target operant is an existing directory (or a symlink which resolves to one). Regards, Berny
bug-coreutils@HIDDEN:bug#36901; Package coreutils.
Full text available.Received: (at 36901) by debbugs.gnu.org; 3 Aug 2019 06:21:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 03 02:21:48 2019 Received: from localhost ([127.0.0.1]:58198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1htnQK-0005qt-Eh for submit <at> debbugs.gnu.org; Sat, 03 Aug 2019 02:21:48 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:36808 helo=Ishtar.sc.tlinx.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <coreutils@HIDDEN>) id 1htnQJ-0005qi-B0 for 36901 <at> debbugs.gnu.org; Sat, 03 Aug 2019 02:21:47 -0400 Received: from [192.168.3.12] (Athenae [192.168.3.12]) by Ishtar.sc.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id x736Lh3s059327; Fri, 2 Aug 2019 23:21:45 -0700 Message-ID: <5D4527F7.3060709@HIDDEN> Date: Fri, 02 Aug 2019 23:21:43 -0700 From: L A Walsh <coreutils@HIDDEN> User-Agent: Thunderbird MIME-Version: 1.0 To: Assaf Gordon <assafgordon@HIDDEN> Subject: Re: bug#36901: Enhance directory and file moves where target already exists References: <5D4500CC.60404@HIDDEN> <20190803054557.GJ15401@HIDDEN> <5D451FE6.5090204@HIDDEN> <20190803061008.GK15401@HIDDEN> In-Reply-To: <20190803061008.GK15401@HIDDEN> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36901 Cc: 36901 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2019/08/02 23:10, Assaf Gordon wrote: >>>> 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 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? > > I previously quoted one small part of the entire "mv" POSIX specification > (item #3, regarding using the 'rename(2)' function). > > It would be wise to read the entire specification before making claims > about violating POSIX. ---- One doesn't need to read all federal and state laws before making claims of law violation. > Specifically, at the top of the page: > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html > SYNOPSIS > mv [-if] source_file target_file > mv [-if] source_file... target_dir > DESCRIPTION > [...] > In the second synopsis form, mv shall move each file named by a > source_file operand to a destination file in the existing directory > named by the target_dir operand [...] This second form is assumed > when the final operand names an existing directory > > In this regard GNU 'mv' is compliant with POSIX. But it isn't. Note to mention -- which posix? Different posix versions are not the same. It isn't 1 spec consistent spec, but changes overtime. You quoted a section saying it had to follow the behavior of rename, but it doesn't do that: And it doesn't follow the POSIX section quoted on the manpage. >>>> 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) mkdir A B touch A/foo B/fee mv A B It B exists and is not empty. Ergo, it is not following the requirement that the directory must be empty or not exist.
bug-coreutils@HIDDEN:bug#36901; Package coreutils.
Full text available.
Received: (at 36901) by debbugs.gnu.org; 3 Aug 2019 06:10:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 03 02:10:18 2019
Received: from localhost ([127.0.0.1]:58194 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1htnFC-0005N5-2q
for submit <at> debbugs.gnu.org; Sat, 03 Aug 2019 02:10:18 -0400
Received: from mail-pg1-f193.google.com ([209.85.215.193]:45773)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <assafgordon@HIDDEN>) id 1htnFA-0005Mc-FC
for 36901 <at> debbugs.gnu.org; Sat, 03 Aug 2019 02:10:17 -0400
Received: by mail-pg1-f193.google.com with SMTP id o13so37080725pgp.12
for <36901 <at> debbugs.gnu.org>; Fri, 02 Aug 2019 23:10:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-disposition:content-transfer-encoding:in-reply-to
:user-agent; bh=jh6KoFqEEXWAZEi2O1bts2djYDhfBoswNMSIEog+aA4=;
b=iuLQ9xzLx7vpqrfh1b/QOc6lV1THdyvs5gMJwTOtrRgOvVhuesv/LtB+zXwowx/g9o
eYxNBTbC9hCTiE/W2DMzBN35dP7Pn/7s4p/JyCmwsWia4nt39tNH93MKZasru4sxG8wD
94+lPrg0WaXeLJThztwgRsuk6strhm+2ty7VtOnRPbbujbKixSE31ZpeHEcC/VwZ6bIt
bjk2RfwBmpnnJGzAOVXUvpHlnK0mRhilxIa8tVU6EDQvupNn+pUkTFxGgqyd13uc/o8m
h1fM/OzQJuFTv9CL+yh9Tl7s2eJYLuNTxEbLzIl2DIZAV5i+VuCLMPtH0DBgBO3TVnkP
nYsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-disposition:content-transfer-encoding
:in-reply-to:user-agent;
bh=jh6KoFqEEXWAZEi2O1bts2djYDhfBoswNMSIEog+aA4=;
b=bipVXswvKm0ZeMHEZquozRKYRbTMCN21p8uuhjbMAYgsdRX4mESBRH0MGWs4tzvFDG
cGJTitpIXUZ9UB27AEbpGPRFY8GHM3gTtz4F6+iRuGRr9OIGmlMmbOav2IJ9ZBcq1YYQ
j89OAyLuKIHSr1X7RtpxDwGilrtwkqGJ/y/52Friix2VUfuN8xhg3vz0foi2OA5C88V1
4G6VeWA6yxen/vBXbxcJA/Do1f2zkB4TmTyrbONWOxxT5rTFB7/Kp3boVrOR/YJYfZV8
MBGyxq1Z7yIp6WHrE65sGiLXycjplQjCVl6173erG2Kxj3VfUCwRPGiiaQvaDeK0O/AL
QrWA==
X-Gm-Message-State: APjAAAUhJIM/K/yy/8K2D3xlizzH29hmI89scBzjzhrkD9GfdGsHZArs
3JdbzUhsnSp4p3ad7QzLajQ5bpLs
X-Google-Smtp-Source: APXvYqzeWzusKlKHp6ZHp+EfQzGczQwVY4GsLczkenxQUFrqlttyD/VFE03wQuVSWlbCuR4Am9mkng==
X-Received: by 2002:a63:ec13:: with SMTP id j19mr45855319pgh.369.1564812610003;
Fri, 02 Aug 2019 23:10:10 -0700 (PDT)
Received: from tomato (moose.housegordon.com. [184.68.105.38])
by smtp.gmail.com with ESMTPSA id u97sm9669794pjb.26.2019.08.02.23.10.08
(version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256);
Fri, 02 Aug 2019 23:10:09 -0700 (PDT)
Received: by tomato (Postfix, from userid 1000)
id 3116668195D; Sat, 3 Aug 2019 00:10:08 -0600 (MDT)
Date: Sat, 3 Aug 2019 00:10:08 -0600
From: Assaf Gordon <assafgordon@HIDDEN>
To: L A Walsh <coreutils@HIDDEN>
Subject: Re: bug#36901: Enhance directory and file moves where target already
exists
Message-ID: <20190803061008.GK15401@HIDDEN>
References: <5D4500CC.60404@HIDDEN>
<20190803054557.GJ15401@HIDDEN>
<5D451FE6.5090204@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5D451FE6.5090204@HIDDEN>
User-Agent: Mutt/1.11.4 (2019-03-13)
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 36901
Cc: 36901 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Hello,
On Fri, Aug 02, 2019 at 10:47:18PM -0700, L A Walsh wrote:
> It's not a wish list that 'mv' doesn't work as documented.
The "wishlist" refers to the topic:
You are asking to add new funtionality to 'mv'.
That is a "wishlist" item.
(answering out of order:)
> > On 2019-08-02 9:56 p.m., L A Walsh wrote:
> >> But you say posix wants it to perform as a rename?
[...]
> >>
> >> 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?
I previously quoted one small part of the entire "mv" POSIX specification
(item #3, regarding using the 'rename(2)' function).
It would be wise to read the entire specification before making claims
about violating POSIX.
Specifically, at the top of the page:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html
SYNOPSIS
mv [-if] source_file target_file
mv [-if] source_file... target_dir
DESCRIPTION
[...]
In the second synopsis form, mv shall move each file named by a
source_file operand to a destination file in the existing directory
named by the target_dir operand [...] This second form is assumed
when the final operand names an existing directory
In this regard GNU 'mv' is compliant with POSIX.
> > 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).
> >> ---
> >> 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.
The Austin group (https://www.opengroup.org/austin/) who is in charge
of developing and maintaining the POSIX standard is the place
to go when wanting to change things in POSIX (or add new things).
You can write to them, suggest a modification,
and if they change the standard, GNU coreutils will surely follow.
As for renaming 'mv' or creating new 'rn' command -
part of POSIX is to codify existing behavior (that is - programs which
were in common use *before* POSIX). It's not always logic, it's not always
ideal, but that's what has been in use for many years.
Based on mv's wiki page (https://en.wikipedia.org/wiki/Mv), 'mv' was
first introduced in 1971, 47 years ago.
With hindsight of nearly 5 decades it's easy to point to faults in a
program. If we were designing 'mv' today from scratch, I'm sure we would
improve many of its aspects.
But given that it is a long-standing program and its usage and quirks
are well established, I'm inclined to say it is highly unlikely
we will change mv's default behaviour or replace it with a different
name.
Adding new functionality (e.g. a new '--merge-directory' option)
is possible, and concrete patches are always welcomed.
However, given all the above, there is no guarentee that such new option
will be accepted.
I still think that such specific features are better suited for more
sophisticated programs (whether GUI or command line).
regards,
- assaf
bug-coreutils@HIDDEN:bug#36901; Package coreutils.
Full text available.Received: (at 36901) by debbugs.gnu.org; 3 Aug 2019 05:47:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 03 01:47:24 2019 Received: from localhost ([127.0.0.1]:58187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1htmt2-0002K8-22 for submit <at> debbugs.gnu.org; Sat, 03 Aug 2019 01:47:24 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:35700 helo=Ishtar.sc.tlinx.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <coreutils@HIDDEN>) id 1htmsz-0002Jf-Jj for 36901 <at> debbugs.gnu.org; Sat, 03 Aug 2019 01:47:22 -0400 Received: from [192.168.3.12] (Athenae [192.168.3.12]) by Ishtar.sc.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id x735lIBM057216; Fri, 2 Aug 2019 22:47:20 -0700 Message-ID: <5D451FE6.5090204@HIDDEN> Date: Fri, 02 Aug 2019 22:47:18 -0700 From: L A Walsh <coreutils@HIDDEN> User-Agent: Thunderbird MIME-Version: 1.0 To: Assaf Gordon <assafgordon@HIDDEN> Subject: Re: bug#36901: Enhance directory and file moves where target already exists References: <5D4500CC.60404@HIDDEN> <20190803054557.GJ15401@HIDDEN> In-Reply-To: <20190803054557.GJ15401@HIDDEN> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36901 Cc: 36901 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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 >=20 > Hello, >=20 > (for context: this is a new topic, diverged at https://bugs.gnu.org/368= 31#38 ) >=20 > For completeness, quoting your second message ( from https://bugs.gnu.o= rg/36831#50 ): >=20 > 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 >=3D 200809L) >> >> So move should give an error: Nope: >> >> mv A B >>> tree B >> B >> =E2=94=9C=E2=94=80=E2=94=80 A >> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 foo >> =E2=94=94=E2=94=80=E2=94=80 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? >> >=20 >=20
bug-coreutils@HIDDEN:bug#36901; Package coreutils.
Full text available.Assaf Gordon <assafgordon@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Assaf Gordon <assafgordon@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 36901) by debbugs.gnu.org; 3 Aug 2019 05:46:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 03 01:46:08 2019 Received: from localhost ([127.0.0.1]:58179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1htmro-0002Fn-5H for submit <at> debbugs.gnu.org; Sat, 03 Aug 2019 01:46:08 -0400 Received: from mail-pl1-f173.google.com ([209.85.214.173]:44909) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <assafgordon@HIDDEN>) id 1htmrm-0002En-2T; Sat, 03 Aug 2019 01:46:06 -0400 Received: by mail-pl1-f173.google.com with SMTP id t14so34398374plr.11; Fri, 02 Aug 2019 22:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=PuD2AYDnHGCz45nBM2bZN5X7/MbJ6op32U/zmx9O66c=; b=U+SLOWcu2FMds8rlKCPouieh3xr4mc7mdAel3KJt1qAhoj+Xk9CW2c3RY4ovXxreDc kTm5RhgwSIrax3ucM4tcj7ki3OxEiQnNg/wBgvCxhNSMmA/6WTvUGEiGmhGUdfUUkFio bN9K4E29qsC+x9Q/Xjqew2xXl1j9Rwh6IcW5WNzu8AOFt3TQuvzK20S4ZLnRUfJzH7PY +z673qBHpCoG7d2zt41duOaLJ8j2pEDyHFebF2aF4PDVEwkpJ/H9dR2J+mwyX0gGvmQH LGpVfclo/2zkX4RwyOMsoxPre/nSuoCeJPhl9uB2XVLCFmZXjsD8OM/k9YFwG475KxEP EPcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=PuD2AYDnHGCz45nBM2bZN5X7/MbJ6op32U/zmx9O66c=; b=aBcPAr2/GzkLxPevrKQydGZ2Uj7eBocWJG1Nbe5WrdqHF4kkc10IlIp2nBVVspdBOC cvxmTkTbKZDdetkjjke0bjK0f6MR6eE5Yj4fkrmVq4afgMuCeEHYyfLHQZFXTJWfLKFa RgzH3I/UBCYUDYP6yLWJwEFdiIQjeV68J60KUab7a7RtVAZfdOLdmPFuw/mscjbTpDhn Ps0Rb0v2MRHejkSSdjgKK4uZCTC3KLDpoQgt1bpTUY2samQDqqWYwpohzKPEPqRvESJv EpbyTi2SKOFpnm3ZG27gn/iNay2OjQiv8T3q2YBMGzwhxvhsQTno2UqVGaJ2EKznAw7g bl1Q== X-Gm-Message-State: APjAAAWwsCUPN/DvW1gGB6PqTfO5+0PdVi4Vg/MtjkVBfEGFOcjazCdS 3HPRB1uuxvw3GeSps9NCBuwgEZ4E X-Google-Smtp-Source: APXvYqxye0/Jmj5VX2LMi+ZsaXcOD84RLudSTe7jTUuuQqnxosmMiQVSYk1D9hYnArdKw85RFzM8Mw== X-Received: by 2002:a17:902:7894:: with SMTP id q20mr129870853pll.339.1564811159748; Fri, 02 Aug 2019 22:45:59 -0700 (PDT) Received: from tomato (moose.housegordon.com. [184.68.105.38]) by smtp.gmail.com with ESMTPSA id u3sm9074730pjn.5.2019.08.02.22.45.58 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 02 Aug 2019 22:45:58 -0700 (PDT) Received: by tomato (Postfix, from userid 1000) id DB9C068B22C; Fri, 2 Aug 2019 23:45:57 -0600 (MDT) Date: Fri, 2 Aug 2019 23:45:57 -0600 From: Assaf Gordon <assafgordon@HIDDEN> To: L A Walsh <coreutils@HIDDEN> Subject: Re: bug#36901: Enhance directory and file moves where target already exists Message-ID: <20190803054557.GJ15401@HIDDEN> References: <5D4500CC.60404@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5D4500CC.60404@HIDDEN> User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36901 Cc: 36901 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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-coreutils@HIDDEN:bug#36901; Package coreutils.
Full text available.
Received: (at submit) by debbugs.gnu.org; 3 Aug 2019 03:34:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 02 23:34:50 2019
Received: from localhost ([127.0.0.1]:58133 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1htkok-00060G-7C
for submit <at> debbugs.gnu.org; Fri, 02 Aug 2019 23:34:50 -0400
Received: from lists.gnu.org ([209.51.188.17]:44280)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <coreutils@HIDDEN>) id 1htkoi-000608-F3
for submit <at> debbugs.gnu.org; Fri, 02 Aug 2019 23:34:48 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:54252)
by lists.gnu.org with esmtp (Exim 4.86_2)
(envelope-from <coreutils@HIDDEN>) id 1htkog-0005vB-Hk
for bug-coreutils@HIDDEN; Fri, 02 Aug 2019 23:34:48 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
version=3.3.2
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <coreutils@HIDDEN>) id 1htkoe-0006z1-NZ
for bug-coreutils@HIDDEN; Fri, 02 Aug 2019 23:34:46 -0400
Received: from ishtar.tlinx.org ([173.164.175.65]:39318
helo=Ishtar.sc.tlinx.org)
by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
(Exim 4.71) (envelope-from <coreutils@HIDDEN>) id 1htkoc-0006xV-Rn
for bug-coreutils@HIDDEN; Fri, 02 Aug 2019 23:34:44 -0400
Received: from [192.168.3.12] (Athenae [192.168.3.12])
by Ishtar.sc.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id
x733YaH2078560; Fri, 2 Aug 2019 20:34:39 -0700
Message-ID: <5D4500CC.60404@HIDDEN>
Date: Fri, 02 Aug 2019 20:34:36 -0700
From: L A Walsh <coreutils@HIDDEN>
User-Agent: Thunderbird
MIME-Version: 1.0
To: Assaf Gordon <assafgordon@HIDDEN>, Coreutils <bug-coreutils@HIDDEN>
Subject: Enhance directory and file moves where target already exists
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no
timestamps) [generic]
X-Received-From: 173.164.175.65
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
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.
L A Walsh <coreutils@HIDDEN>:bug-coreutils@HIDDEN.
Full text available.bug-coreutils@HIDDEN:bug#36901; Package coreutils.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.