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
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
$ 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 `)' $
mv suggestion
when on interactive mode (maybe mv -I), ask for automatic creation of missing dirs. $ ls foo $ mv foo bar/ instead of giving the error: mv: target `bar/' is not a directory: No such file or directory ask: mv: target directory 'bar/' does not exist. create? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #18927] feature request: user defined format for ls output
Follow-up Comment #3, bug #18927 (project coreutils): Nor colorizing the output, print sizes in human-readable format, etc, etc. find != ls ___ Reply to this item at: http://savannah.gnu.org/bugs/?18927 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #1212] wishlist: ls sort case insensitive option
Follow-up Comment #4, bug #1212 (project coreutils): I found out that unsetting LANG fixes the case sensitivity (README is supposed to came before main.c, dammit!), but will it be missing UTF capability without the LANG=en_US.UTF-8 that was default in my distro? ___ Reply to this item at: http://savannah.gnu.org/bugs/?1212 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #18927] feature request: user defined format for ls output
URL:
http://savannah.gnu.org/bugs/?18927
Summary: feature request: user defined format for ls output
Project: GNU Core Utilities
Submitted by: barrett9h
Submitted on: Thursday 02/01/2007 at 11:30
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
___
Details:
ls --format=${FORMAT_STRING}
FORMAT_STRING is something like:
%u = owner
%g = group
%s = file size
%f = file name
%m = permission bits (mode)
etc.
Maybe a special char to designate a column separator, so the user can join
fields (eg. %u,%g).
___
Reply to this item at:
http://savannah.gnu.org/bugs/?18927
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
