GNU bug report logs - #5926
feature request: mv -p to create missing target dir

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 5926 in the body.
You can then email your comments to 5926 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rodolfo Borges <rodolfo.borges <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: feature request: mv -p to create missing target dir
Date: Sun, 11 Apr 2010 11:07:09 -0300

$ mv foo ~/some/path/
mv: cannot create regular file `/home/bart9h/some/path/': Is a directory
$ mkdir -p ~/some/path/
$ mv foo ~/some/path/
$ :(
bash: syntax error near unexpected token `newline'
$
$
$ pacman -Sy coreutils
(... upgrades package ...)
$
$
$ mv -vp foo ~/some/path/
mv: created directory `/home/bart9h/some'
mv: created directory `/home/bart9h/some/path/'
`foo' -> `/home/bart9h/some/path/foo'
$ alias mv='mv -p'
$ :)
bash: syntax error near unexpected token `)'
$

Message #8 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Rodolfo Borges <rodolfo.borges <at> gmail.com>
Cc: 5926 <at> debbugs.gnu.org
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Thu, 15 Apr 2010 17:13:41 -0600

Rodolfo Borges wrote:
> $ mv foo ~/some/path/
> mv: cannot create regular file `/home/bart9h/some/path/': Is a directory

No target directory exists.

> $ mkdir -p ~/some/path/
> $ mv foo ~/some/path/

That seems like the best way to do it.

> $ :(
> bash: syntax error near unexpected token `newline'
> ...
> $ :)
> bash: syntax error near unexpected token `)'

Using this format to tell us what you are thinking is very confusing!

> $ mv -vp foo ~/some/path/
> mv: created directory `/home/bart9h/some'
> mv: created directory `/home/bart9h/some/path/'
> `foo' -> `/home/bart9h/some/path/foo'

I don't think this is a good idea.  It could be added.  But does it
really gain you anything over calling mkdir -p?  I don't think so.  It
would simply add code bloat to the program.

Plus it wouldn't be portable.  Other implementations wouldn't have it.
It is only of marginal benefit if at all and so other implementations
might never have it.  In any case you would need to wait years before
the feature trickled down to where you could use it reliably.  Also
you can always accomplish this yourself with a shell script.  In
general things that can be easily encapsulated in a shell script are
not good additions to the utilities.

Adding that option is counter to The Unix Philosophy.  Small is
beautiful.  Make each program do one thing well.  Choose portability
over efficiency.  Use shell scripts to increase leverage and
portability.

Bob

Message #11 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Rodolfo Borges <rodolfo.borges <at> gmail.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 5926 <at> debbugs.gnu.org
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Fri, 16 Apr 2010 08:30:47 -0300

On Thu, Apr 15, 2010 at 8:13 PM, Bob Proulx <bob <at> proulx.com> wrote:
> Rodolfo Borges wrote:
>> $ mv foo ~/some/path/
>> mv: cannot create regular file `/home/bart9h/some/path/': Is a directory
>
> No target directory exists.
>
>> $ mkdir -p ~/some/path/
>> $ mv foo ~/some/path/
>
> That seems like the best way to do it.
>
>> $ :(
>> bash: syntax error near unexpected token `newline'
>> ...
>> $ :)
>> bash: syntax error near unexpected token `)'
>
> Using this format to tell us what you are thinking is very confusing!
>

It seems you haven't got the writing style.
I know the cause of the error in the first `mv` and, sheesh!, I
frigging know bash doesn't understand emoticons.
Better to fallback to plain boring English, then.


>> $ mv -vp foo ~/some/path/
>> mv: created directory `/home/bart9h/some'
>> mv: created directory `/home/bart9h/some/path/'
>> `foo' -> `/home/bart9h/some/path/foo'
>
> I don't think this is a good idea.  It could be added.  But does it
> really gain you anything over calling mkdir -p?
> I don't think so.
> It would simply add code bloat to the program.

You don't have to type the path twice, and more importantly, you don't
have to know beforehand that the path doesn't exist yet.
The use case if fairly common: you start typing `mv
my-first-salsa-album/ ~/music/sal<tab><tab>` ops!, I have no salsa
subdir yet in my music collection: I have to cancel the command,
create the directory, then type it again.

> Plus it wouldn't be portable.  Other implementations wouldn't have it.
> It is only of marginal benefit if at all and so other implementations
> might never have it.  In any case you would need to wait years before
> the feature trickled down to where you could use it reliably.

The GNU utilities already have a bunch of features that other
implementations don't have.

> Also you can always accomplish this yourself with a shell script.  In
> general things that can be easily encapsulated in a shell script are
> not good additions to the utilities.

cat <<EOF >> ~/.bashrc
function mv() {
    local target="${!#}"
    local dir
    if [[ "$target" =~ '/$' ]]; then
        dir="$target"
    else
        dir="$(dirname "$target")"
    fi
    test -d "$dir" || mkdir -vp "$dir"
    $(which mv) "$@"
}
EOF


> Adding that option is counter to The Unix Philosophy.  Small is
> beautiful.  Make each program do one thing well.  Choose portability
> over efficiency.  Use shell scripts to increase leverage and
> portability.

`cp` does create directories, shouldn't it restrict itself to copying
files then?

Message #16 received at 5926-done <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Rodolfo Borges <rodolfo.borges <at> gmail.com>
Cc: 5926-done <at> debbugs.gnu.org
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Sat, 24 Apr 2010 14:08:03 -0600

Rodolfo Borges wrote:
> Bob Proulx wrote:
> > Rodolfo Borges wrote:
> >> $ :(
> >> bash: syntax error near unexpected token `newline'
> >> ...
> >> $ :)
> >> bash: syntax error near unexpected token `)'
> >
> > Using this format to tell us what you are thinking is very confusing!
> 
> It seems you haven't got the writing style.

No.  When reading through reported bugs one is naturally looking for
error messages.  By including error messages in your report that are
unrelated to the topic you are reporting it actively distracts from
it.  It makes the job of reading your report much harder.

> I know the cause of the error in the first `mv` and, sheesh!, I
> frigging know bash doesn't understand emoticons.

Including smileys or frownies is just fine.  It was only the bash
error message that you included along with them that I found difficult.

> Better to fallback to plain boring English, then.

Please do.  Thank you.

> >> $ mv -vp foo ~/some/path/
> >> mv: created directory `/home/bart9h/some'
> >> mv: created directory `/home/bart9h/some/path/'
> >> `foo' -> `/home/bart9h/some/path/foo'
> >
> > I don't think this is a good idea.  It could be added.  But does it
> > really gain you anything over calling mkdir -p?
> > I don't think so.
> > It would simply add code bloat to the program.
> 
> You don't have to type the path twice, and more importantly, you don't

True.  But the same could be said for any complex command that could
be written to do any ten or twenty things all in one command.  You
want one thing, I want a different thing, ten other people want ten
other different things.  Creating such complex commands is not a good
thing and violates the Unix Philosophy as I explained.

> have to know beforehand that the path doesn't exist yet.

That is also true of calling 'mkdir -p DIR' on the path beforehand.
You don't have to know if it exists or not.

> The use case if fairly common: you start typing `mv
> my-first-salsa-album/ ~/music/sal<tab><tab>` ops!, I have no salsa
> subdir yet in my music collection: I have to cancel the command,
> create the directory, then type it again.

For someone who always used the proposed 'mv -p' option it would mean
that a typo would accidentally create a new and differently named
directory by mistake.  Your typing and spelling would need to be
consistent and accurate because the risk from a mistake would be
increased.

> > Plus it wouldn't be portable.  Other implementations wouldn't have it.
> > It is only of marginal benefit if at all and so other implementations
> > might never have it.  In any case you would need to wait years before
> > the feature trickled down to where you could use it reliably.
> 
> The GNU utilities already have a bunch of features that other
> implementations don't have.

True.

> > Also you can always accomplish this yourself with a shell script.  In
> > general things that can be easily encapsulated in a shell script are
> > not good additions to the utilities.
> 
> cat <<EOF >> ~/.bashrc
> function mv() {
>     local target="${!#}"
>     local dir
>     if [[ "$target" =~ '/$' ]]; then
>         dir="$target"
>     else
>         dir="$(dirname "$target")"
>     fi
>     test -d "$dir" || mkdir -vp "$dir"
>     $(which mv) "$@"
> }
> EOF

Very good!  I see that you have a solution to your problem.

As a side comment I don't see the point of:

>     $(which mv) "$@"

The 'which' command is another one of those simple but not very
portable commands that does different things on different systems.  In
the simple case of reporting where the command is found on PATH the
use here is redundant since the command would otherwise simply be
found on PATH.

  mv "$@"

> > Adding that option is counter to The Unix Philosophy.  Small is
> > beautiful.  Make each program do one thing well.  Choose portability
> > over efficiency.  Use shell scripts to increase leverage and
> > portability.
> 
> `cp` does create directories, shouldn't it restrict itself to copying
> files then?

The -R, -r, --recursive option does copy directories recursively.  It
is a copy of the input directory hierarchy and therefore cp copies it.
But is that the same thing as making arbitrary directories down the
destination path?  I don't think so.

Since you have a simple resolution to your issue by using your small
shell script and no one else has joined into the discussion and
sufficient time has passed to allow everyone to have read it then I
will assume that there isn't any motivation from others to make this
change.  Therefore I am going to close this bug.  It will remain in
the archive and will be available for further discussion.  If the
opinion changes then the issue may be reopened.

Bob

Message #19 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: bob <at> proulx.com (Bob Proulx)
Cc: 5926 <at> debbugs.gnu.org
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Sat, 24 Apr 2010 17:57:17 -0500 (GMT+5)

Bob Proulx writes:
> 
> As a side comment I don't see the point of:
> 
> >     $(which mv) "$@"
> 

I can guess the point:

bash$ alias mv='mv -i'
bash$ touch a b
bash$ mv a b
mv: overwrite `b'? ^C
bash$ $(which mv) a b
bash$ ls -l a b
ls: cannot access a: No such file or directory
-rw------- 1 pacman users 0 Apr 24 17:55 b

Silly aliases.

-- 
Alan Curry

Message #22 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 5926 <at> debbugs.gnu.org
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Sat, 24 Apr 2010 17:47:36 -0600

Alan Curry wrote:
> Bob Proulx writes:
> > As a side comment I don't see the point of:
> > 
> > >     $(which mv) "$@"
> 
> I can guess the point:
> 
> bash$ alias mv='mv -i'
> bash$ touch a b
> bash$ mv a b
> mv: overwrite `b'? ^C
> bash$ $(which mv) a b

Good observation.

Yes, but...  Using aliases in general scripting?  That way leads to
madness.  In the proposed shell function aliases could be in effect
but if that is the case then it would be better to explicitly turn off
aliasing for that command.  The traditional quoting to avoid aliases:

  \mv "$@"

> Silly aliases.

Agreed.

Bob

Message #25 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 5926 <at> debbugs.gnu.org
Cc: Rodolfo Borges <rodolfo.borges <at> gmail.com>, bob <at> proulx.com
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Sun, 25 Apr 2010 15:29:34 +0200

Just a few obsevations on side issues...

Bob Proulx writes:
> Rodolfo Borges wrote:
>
> > cat <<EOF >> ~/.bashrc
> > function mv() {
> >     local target="${!#}"
> >     local dir
> >     if [[ "$target" =~ '/$' ]]; then
> >         dir="$target"
> >     else
> >         dir="$(dirname "$target")"
> >     fi
> >     test -d "$dir" || mkdir -vp "$dir"
> >     $(which mv) "$@"
> > }
> > EOF
> 
> Very good!  I see that you have a solution to your problem.
> 
> As a side comment I don't see the point of:
> >     $(which mv) "$@"
I think that's needed because otherwise the shell function would end 
up calling itself recursively, since it's named `mv' too.

> The 'which' command is another one of those simple but not very
> portable commands that does different things on different systems. 
Since Rodolfo is assuming bash as his shell, he could have used:
  $(type -P mv) "$@"
instead, which is more "portable" because it just uses bash builtins.

> In the simple case of reporting where the command is found on PATH
> the use here is redundant since the command would otherwise simply
> be found on PATH.
>   mv "$@"
No, this would call the `mv' function, since shell functions take 
precedence over external commands in bash.

Regards,
     Stefano

Message #28 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Rodolfo Borges <rodolfo.borges <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 5926 <at> debbugs.gnu.org, bob <at> proulx.com
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Sun, 25 Apr 2010 10:38:04 -0300

On Sun, Apr 25, 2010 at 10:29 AM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> Just a few obsevations on side issues...
>
>> >     $(which mv) "$@"
> I think that's needed because otherwise the shell function would end
> up calling itself recursively, since it's named `mv' too.

exactly.


>> The 'which' command is another one of those simple but not very
>> portable commands that does different things on different systems.
> Since Rodolfo is assuming bash as his shell, he could have used:
>  $(type -P mv) "$@"
> instead, which is more "portable" because it just uses bash builtins.

thanks, stefano.
didn't know about type -P

Message #31 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 5926 <at> debbugs.gnu.org, Rodolfo Borges <rodolfo.borges <at> gmail.com>,
	bob <at> proulx.com
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Mon, 26 Apr 2010 11:00:24 +0200

Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:

> Just a few obsevations on side issues...
>
> Bob Proulx writes:
>> Rodolfo Borges wrote:
>>
>> > cat <<EOF >> ~/.bashrc
>> > function mv() {
>> >     local target="${!#}"
>> >     local dir
>> >     if [[ "$target" =~ '/$' ]]; then
>> >         dir="$target"
>> >     else
>> >         dir="$(dirname "$target")"
>> >     fi
>> >     test -d "$dir" || mkdir -vp "$dir"
>> >     $(which mv) "$@"
>> > }
>> > EOF
>> 
>> Very good!  I see that you have a solution to your problem.
>> 
>> As a side comment I don't see the point of:
>> >     $(which mv) "$@"
> I think that's needed because otherwise the shell function would end 
> up calling itself recursively, since it's named `mv' too.

You use "command mv" for that.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #34 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 5926 <at> debbugs.gnu.org, Rodolfo Borges <rodolfo.borges <at> gmail.com>,
	bob <at> proulx.com
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Mon, 26 Apr 2010 11:32:27 +0200

Stefano Lattarini wrote:
> Just a few obsevations on side issues...
>
> Bob Proulx writes:
>> Rodolfo Borges wrote:
>>
>> > cat <<EOF >> ~/.bashrc
>> > function mv() {
>> >     local target="${!#}"
>> >     local dir
>> >     if [[ "$target" =~ '/$' ]]; then
>> >         dir="$target"
>> >     else
>> >         dir="$(dirname "$target")"
>> >     fi
>> >     test -d "$dir" || mkdir -vp "$dir"
>> >     $(which mv) "$@"
>> > }
>> > EOF
>>
>> Very good!  I see that you have a solution to your problem.
>>
>> As a side comment I don't see the point of:
>> >     $(which mv) "$@"
> I think that's needed because otherwise the shell function would end
> up calling itself recursively, since it's named `mv' too.
>
>> The 'which' command is another one of those simple but not very
>> portable commands that does different things on different systems.
> Since Rodolfo is assuming bash as his shell, he could have used:
>   $(type -P mv) "$@"
> instead, which is more "portable" because it just uses bash builtins.
>
>> In the simple case of reporting where the command is found on PATH
>> the use here is redundant since the command would otherwise simply
>> be found on PATH.
>>   mv "$@"
> No, this would call the `mv' function, since shell functions take
> precedence over external commands in bash.

Using env is the most portable, at the expense
of a fork (compared to bash's "command"):

  env mv "$@"

Message #37 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Jim Meyering <jim <at> meyering.net>
Cc: 5926 <at> debbugs.gnu.org, Rodolfo Borges <rodolfo.borges <at> gmail.com>,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>, bob <at> proulx.com
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Mon, 26 Apr 2010 12:14:57 +0200

Jim Meyering <jim <at> meyering.net> writes:

> Using env is the most portable, at the expense
> of a fork (compared to bash's "command"):

Note that command is also part of the POSIX shell.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #40 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 5926 <at> debbugs.gnu.org, Rodolfo Borges <rodolfo.borges <at> gmail.com>,
	bob <at> proulx.com
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Mon, 26 Apr 2010 12:07:07 +0200

At Monday 26 April 2010, Jim Meyering <jim <at> meyering.net> wrote:
> Using env is the most portable, at the expense
> of a fork (compared to bash's "command"):
> 
>   env mv "$@"
> 
Generally, this is true.  But Rodolfo was assuming bash as his shell 
anyway, and in this case the use of well-estabilished bash 
builtins/constructs (like "command", which was there since at least 
bash 2.0) can IMHO help to increase portability.  In fact, this way 
one doesn't have to remember the limits/idiosyncracies of many 
different shells and system utilities (and different versions thereof), 
but only those of one shell, i.e. bash (and I think that anyone who's 
read the section "Portable Shell Programming" in the autoconf manual 
could be easily convinced that this is a great advantage).

Regards,
    Stefano

Message #43 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 5926 <at> debbugs.gnu.org, Rodolfo Borges <rodolfo.borges <at> gmail.com>,
	bob <at> proulx.com
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Mon, 26 Apr 2010 11:07:39 +0200

At Monday 26 April 2010, Andreas Schwab <schwab <at> linux-m68k.org> wrote:
> > I think that's needed because otherwise the shell function would
> > end up calling itself recursively, since it's named `mv' too.
> 
> You use "command mv" for that.
> 
Good point, I forgot about that.  And it works for shell builtins too. 
Using "command mv" seems indeed the optimal choice.

Regards,
    Stefano
 

Message #50 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: f0rhum <f0rhum <at> free.fr>
To: 5926 <at> debbugs.gnu.org
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Sun, 19 Oct 2014 18:10:15 +0200

> ...is
mv 
> counter to The Unix Philosophy
?
>  Small is
> beautiful.  Make each program do one thing well.  Choose portability
> over efficiency.  Use shell scripts to increase leverage and
> portability.

Would mv be discarded to the benefit of cp + rm?
Ok, I know we can't because mv also does in place rename. But when it's time to real move who does use cp then rm?

Message #53 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: f0rhum <f0rhum <at> free.fr>
Cc: 5926 <at> debbugs.gnu.org
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Sun, 19 Oct 2014 17:09:37 -0600

f0rhum wrote:
> > ...is
> mv 
> > counter to The Unix Philosophy
> ?
> >  Small is
> > beautiful.  Make each program do one thing well.  Choose portability
> > over efficiency.  Use shell scripts to increase leverage and
> > portability.
> 
> Would mv be discarded to the benefit of cp + rm?
> Ok, I know we can't because mv also does in place rename. But when
> it's time to real move who does use cp then rm?

The mv command causes an atomic rename(2) to occur if on the same file
system.  That is not possible when using cp + rm.  Therefore mv is
required.

If mv'ing a file from one file system to another it is impossible to
have an atomic rename().  In that case mv falls back to effectively cp
plus rm.  That is mentioned in the mv documentation.

Bob

Message #56 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: f0rhum <at> free.fr
To: 5926 <at> debbugs.gnu.org
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Mon, 20 Oct 2014 13:20:03 +0200 (CEST)

> The mv command causes an atomic rename(2) to occur if on the same file
> system.  That is not possible when using cp + rm.  Therefore mv is
> required.
Hi Bob.
I am just trying to understand why this very request is refused with
the argument "small is beautiful", when the "-p" was accepted for cp:
I mean why wasn't refused "cp -p" request, saying "just use mkdir first".
This seems unfair for mv to be refused the ease of use cp was offered.
Maybe I have a problem with understanding this "atomic" word
which also stunned myself in iptables documentation. 

> If mv'ing a file from one file system to another it is impossible to
> have an atomic rename().  In that case mv falls back to effectively cp
> plus rm.  That is mentioned in the mv documentation.
The same "You have to know if the parent exists" argument that was opposed
to this request could have also been opposed: "You have to know if you are
moving in the same file system or an other,
so we stick to rename+cp+rm, no need for mv at all, small is beautiful,
do one thing and do it well".

That's not to argue. Just coming to GNU since 6 years from closed source
OSes where nobody wouldn't even have the idea to ask why this-and-that, I
realize here I can ask why, e.g. why we haven't some kind of uniformity in
commands parameters --long and -short for various commands. This would be
a great help for average users. Somebody once replied to me "it is because
many different people work(ed) on these commands, at different time...". Just
a pure fact we have to live with. Is it the same inside the coreutils 
team too?

Bye bye

Fabrice

Message #59 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Bob Proulx <bob <at> proulx.com>
Cc: 5926 <at> debbugs.gnu.org, f0rhum <f0rhum <at> free.fr>
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Mon, 20 Oct 2014 18:39:50 +0200

Bob Proulx <bob <at> proulx.com> writes:

> The mv command causes an atomic rename(2) to occur if on the same file
> system.  That is not possible when using cp + rm.  Therefore mv is
> required.

Also, you can rename a file that you cannot read.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #62 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: f0rhum <at> free.fr, 5926 <at> debbugs.gnu.org
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Tue, 21 Oct 2014 18:10:33 -0700

f0rhum <at> free.fr wrote:
> I mean why wasn't refused "cp -p" request, saying "just use mkdir first".

There seems to be a good deal of confusion here, as "cp -p" has nothing to do 
with "mkdir -p".

Message #65 received at 5926 <at> debbugs.gnu.org (full text, mbox):

From: f0rhum <at> free.fr
To: 5926 <at> debbugs.gnu.org
Subject: Re: bug#5926: feature request: mv -p to create missing target dir
Date: Wed, 22 Oct 2014 10:16:23 +0200 (CEST)

>> I mean why wasn't refused "cp -p" request, saying "just use mkdir first".

> There seems to be a good deal of confusion here, as "cp -p" has nothing to do 
> with "mkdir -p".

Oooops, sorry, I meant: why wasn't refused mkdir "-p" option request, saying "just use ls and mkdir first"?
Hmmm, ok, I see they are both about creating dirs, but aren't mkdir, cp, mv, touch... all involved in creating links in a file system? Hmmm... It seems I triggered an endless loop in my own mind: confusion was yet there. Let's call this ignorance, lazziness. Mum!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.