I wanted to take the output of 'ls' and pipe it into xargs to execute a command for each filename. It doesnt much matter which command I wanted to run so for example here I will just 'echo' the filenames to serve as a trivial example :

Create a test directory with a filename containing a single quote :

$mkdir amigo\'s_folder

Now run the example command for all files in the folder

$ls | xargs 'echo {}'
xargs: unmatched single quote; by default quotes are special to xargs unless you use the -0 option

As you can see I get the error message shown above. This is because the filename containing a single ' character confuses xargs which treats it as a special character. Using the '-0' option does not appear to solve the problem.

Is there a command in linux that will take an input string and escape any special characters found within it. e.g a command called 'esc' that I could use as follows :

$ls | esc | xargs 'echo {}'

Or is there a better solution?

Using `find` and -exec seem to work. I figured this out based on http://www.linuxquestions.org/questi...e-quote-99830/ which was the second result Google gave me when I searched for "single quote with xargs". Here's an example:

Hope this helps you and welcome to LQ!

Sasha

To pipe find to xargs without having problems do:

The '-print0' and '-0' options allow null terminating characters to delimit input and output, this avoiding any problems with whitespace or special characters.

Thanks for your replies but I think ive got an answer to my question :

First of all, the output of 'ls' is delimited by new line characters i.e. '\n'. Its a bit confusing because it seems that bash, by default, ignores them for ls and displays the results left to right. To prove this do the following :

$ls > ls.txt
$cat ls.txt

You will see that cat interprets the \n's as new lines

Is this valid reasoning?


So, given this we can use the delimiter option '-d' of xargs :

$ls | xargs -d\\n echo

Here note that since bash itself would escape '\n' as a literal 'n' character we need to make sure we pass the literal string '\n' to the command, therefore we must escape the backslash.

Hi!

Not sure I understand your reasoning in the first half of your post. Pretty much everything is terminated line-by-line with \n characters. Bash of course displays stuff L to R (unless you're using a R to L language), and, bash isn't ignoring the characters, it's interpreting them, as newlines. So this is normal behavior.

For the second half of your post: The real answer is, "Does it work? Using the -d option?", and if so, then you've got s solution that involves less typing than the previous suggestions

xargs is something I don't use much at all; I should try to use it more, is it's pretty handy.

Sasha

Well, you can see what I mean by doing a hex dump of the output of ls :

For the usual row and column listing using 'ls' you get :

andy@esprimo-ubuntu:~$ ls
Desktop Downloads Music projects Templates Videos
Documents examples.desktop Pictures Public test wxsmith

..and you can display this is a single column using 'ls -1' ... i.e.

andy@esprimo-ubuntu:~$ ls -1
Desktop
Documents
Downloads
examples.desktop
Music
Pictures
projects
Public
Templates
test
Videos
wxsmith


However, when you inspect the output for control characters both versions are byte-by-byte identical :

00000000 44 65 73 6b 74 6f 70 0a 44 6f 63 75 6d 65 6e 74 |Desktop.Document|
00000010 73 0a 44 6f 77 6e 6c 6f 61 64 73 0a 65 78 61 6d |s.Downloads.exam|
00000020 70 6c 65 73 2e 64 65 73 6b 74 6f 70 0a 4d 75 73 |ples.desktop.Mus|
00000030 69 63 0a 50 69 63 74 75 72 65 73 0a 70 72 6f 6a |ic.Pictures.proj|
00000040 65 63 74 73 0a 50 75 62 6c 69 63 0a 54 65 6d 70 |ects.Public.Temp|
00000050 6c 61 74 65 73 0a 74 65 73 74 0a 56 69 64 65 6f |lates.test.Video|
00000060 73 0a 77 78 73 6d 69 74 68 0a |s.wxsmith.|
0000006a
andy@esprimo-ubuntu:~$ ls -1 | hd
00000000 44 65 73 6b 74 6f 70 0a 44 6f 63 75 6d 65 6e 74 |Desktop.Document|
00000010 73 0a 44 6f 77 6e 6c 6f 61 64 73 0a 65 78 61 6d |s.Downloads.exam|
00000020 70 6c 65 73 2e 64 65 73 6b 74 6f 70 0a 4d 75 73 |ples.desktop.Mus|
00000030 69 63 0a 50 69 63 74 75 72 65 73 0a 70 72 6f 6a |ic.Pictures.proj|
00000040 65 63 74 73 0a 50 75 62 6c 69 63 0a 54 65 6d 70 |ects.Public.Temp|
00000050 6c 61 74 65 73 0a 74 65 73 74 0a 56 69 64 65 6f |lates.test.Video|
00000060 73 0a 77 78 73 6d 69 74 68 0a |s.wxsmith.|
0000006a

Therefore strange as it sounds, it must be bash that is interpreting the output?

How intiguing! Alternatively ls may behave differently depending on the output device. Here's a couple of excerpts from the ls man page suggesting that ls does adapt to the output device