How do you send the output of ls to mv?

Question

I know you can do it with a find, but is there a way to send the output of ls to mv in the unix command line?

Answer 1

One way is with backticks:

mv `ls *.boo` subdir

Edit: however, this is fragile and not recommended -- see @lhunath's asnwer for detailed explanations and recommendations.

Answer 2

You surround the ls with back quotes and put it after the mv, so like this...

mv `ls` somewhere/

But keep in mind that if any of your file names have spaces in them it won't work very well.

Also it would be simpler to just do something like this: mv filepattern* somewhere/

Answer 3

Not exactly sure what you're trying to achieve here, but here's one possibility:

The "xargs" part is the important piece everything else is just setup. The effect of this is to take everything that "ls" outputs and add a ".txt" extension to it.

$ mkdir xxx  # 
$ cd xxx
$ touch a b c x y z
$ ls
a  b  c  x  y  z
$ ls | xargs -Ifile mv file file.txt
$ ls
a.txt  b.txt  c.txt  x.txt  y.txt  z.txt
$

Something like this could also be achieved by:

$ touch a b c x y z
$ for i in `ls`;do mv $i ${i}.txt; done
$ ls
a.txt  b.txt  c.txt  x.txt  y.txt  z.txt
$

I sort of like the second way better. I can NEVER remember how xargs works without reading the man page or going to my "cute tricks" file.

Hope this helps.

Answer 4

Check out find -exec {} as it might be a better option than ls but it depends on what you're trying to achieve.

Answer 5

Backticks work well, as others have suggested. See xargs, too. And for really complicated stuff, pipe it into sed, make the list of commands you want, then run it again with the output of sed piped into sh.

Here's an example with find, but it works fine with ls, too:

http://github.com/DonBranson/scripts/blob/f09d24629ab6eb3ce509d4d3078818430306b063/jarfinder.sh

Answer 6

You shouldn't use the output of ls as the input of another command. Files with spaces in their names are difficult as is the inclusion of ANSI escape sequences if you have:

alias ls-'ls --color=always'

for example.

Always use find or xargs (with -0) or globbing.

Also, you didn't say whether you want to move files or rename them. Each would be handled differently.

edit: added -0 to xargs (thanks for the reminder)

Answer 7

/bin/ls | tr '\n' '\0' | xargs -0 -i% mv % /path/to/destdir/

"Useless use of ls", but should work. By specifying the full path to ls(1) you avoid clashes with aliasing of ls(1) mentioned in some of the previous posts. The tr(1) command together with "xargs -0" makes the command work with filenames containing (ugh) whitespace. It won't work with filenames containing newlines, but having filenames like that in the file system is to ask for trouble, so it probably won't be a big problem. But filenames with newlines could exist, so a better solution would be to use "find -print0":

find /path/to/srcdir -type f -print0 | xargs -0 -i% mv % dest/

Answer 8

#!/bin/bash

for i in $( ls * );
do
mv $1 /backup/$1
done

else, it's the find solution by sybreon, and as suggested NOT the green mv ls solution.

Answer 9

ls is a tool used to DISPLAY some statistics about filenames in a directory.

It is not a tool you should use to enumerate them and pass them to another tool for using it there. Parsing ls is almost always the wrong thing to do, and it is bugged in many ways.

For a detailed document on the badness of parsing ls, which you should really go read, check out: http://mywiki.wooledge.org/ParsingLs

Instead, you should use either globs or find, depending on what exactly you're trying to achieve:

mv * /foo
find . -exec mv {} /foo \;

---

The main source of badness of parsing ls is that ls dumps all filenames into a single string of output, and there is no way to tell the filenames apart from there. For all you know, the entire ls output could be one single filename!

The secondary source of badness of parsing ls comes from the broken way in which half the world uses bash. They think for magically does what they would like it to do when they do something like:

for file in `ls`  # Never do this!
for file in $(ls) # Exactly the same thing.

for is a bash builtin that iterates over arguments. And $(ls) takes the output of ls and cuts it apart into arguments wherever there are spaces, newlines or tabs. Which basically means, you're iterating over words, not over filenames. Even worse, you're asking bask to take each of those mutilated filename words and then treat them as globs that may match filenames in the current directory. So if you have a filename which contains a word which happens to be a glob that matches other filenames in the current directory, that word will disappear and all those matching filenames will appear in its stead!

mv `ls` /foo      # Exact same badness as the ''for'' thing.

Answer 10

None of the answers so far are safe for filenames with spaces in them. Try this:

for i in *; do mv "$i" some_dir/; done

You can of course use any glob pattern you like in place of *.

Answer 11

Just use find or your shells globing!

find . -depth=1 -exec mv {} /tmp/blah/ \;

..or..

mv * /tmp/blah/

You don't have to worry about colour in the ls output, or other piping strangeness - Linux allows basically any characters in the filename except a null byte.. For example:

$ touch "blah\new|
> "
$ ls | xargs file
blahnew|:                  cannot open `blahnew|' (No such file or directory)

..but find works perfectly:

$ find . -exec file {} \;
./blah\new|
: empty