bug#5926: feature request: mv -p to create missing target dir
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!
bug#5926: feature request: mv -p to create missing target dir
f0r...@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.
bug#5926: feature request: mv -p to create missing target dir
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
bug#5926: feature request: mv -p to create missing target dir
Bob Proulx b...@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, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
bug#5926: feature request: mv -p to create missing target dir
...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?
bug#5926: feature request: mv -p to create missing target dir
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
bug#5926: feature request: mv -p to create missing target dir
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
bug#5926: feature request: mv -p to create missing target dir
Stefano Lattarini stefano.lattar...@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, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
bug#5926: feature request: mv -p to create missing target dir
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 $@
bug#5926: feature request: mv -p to create missing target dir
Jim Meyering j...@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, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
bug#5926: feature request: mv -p to create missing target dir
At Monday 26 April 2010, Jim Meyering j...@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
bug#5926: feature request: mv -p to create missing target dir
At Monday 26 April 2010, Andreas Schwab sch...@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
bug#5926: feature request: mv -p to create missing target dir
On Sun, Apr 25, 2010 at 10:29 AM, Stefano Lattarini stefano.lattar...@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
bug#5926: feature request: mv -p to create missing target dir
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/saltabtab` 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
bug#5926: feature request: mv -p to create missing target dir
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
bug#5926: feature request: mv -p to create missing target dir
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
bug#5926: feature request: mv -p to create missing target dir
On Thu, Apr 15, 2010 at 8:13 PM, Bob Proulx b...@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/saltabtab` 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?
bug#5926: feature request: mv -p to create missing target dir
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
bug#5926: feature request: mv -p to create missing target dir
$ 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 `)' $
