How can I search through directories with spaces?

[Database Administrator]

Hi,

I'm trying to execute this command

find . -name "*.xml" | xargs grep -i 'fillInBlankTestItem'

in a directory where there are sub directories with spaces in the
names, for example "Grade 6" is a sub directory name. When I execute
the above command, I get many errors like

grep: ./Grade: No such file or directory
grep: 7/Skills: No such file or directory

It seems like these problems occur because I have spaces in the
directory titles. Without changing the directory naems, how can I
overcome this?

Thanks, - Dave

[Database Administrator]

On Thursday 6 November 2008 04:01, laredotornado wrote:

> Hi,
>
> I'm trying to execute this command
>
> find . -name "*.xml" | xargs grep -i 'fillInBlankTestItem'
>
> in a directory where there are sub directories with spaces in the
> names, for example "Grade 6" is a sub directory name. When I execute
> the above command, I get many errors like
>
> grep: ./Grade: No such file or directory
> grep: 7/Skills: No such file or directory
>
> It seems like these problems occur because I have spaces in the
> directory titles. Without changing the directory naems, how can I
> overcome this?

In addition to the other ways, you can do

find . -name "*.xml" | xargs -d '\n' grep -i 'fillInBlankTestItem'

that should work fine if you don't have newlines in filenames (which
hopefully is unlikely).

[Database Administrator]

laredotornado wrote:

> I'm trying to execute this command
>
> find . -name "*.xml" | xargs grep -i 'fillInBlankTestItem'
>
> in a directory where there are sub directories with spaces in the
> names, for example "Grade 6" is a sub directory name. When I execute
> the above command, I get many errors like
>
> grep: ./Grade: No such file or directory
> grep: 7/Skills: No such file or directory

The best solution, if your "find" accepts the "+" terminator for -exec,
is:

find . -name "*.xml" -exec grep -i 'fillInBlankTestItem' /dev/null {} +

The '+' makes find do the argument aggregation that xargs would have
done, and has been required by POSIX since 2001. (The /dev/null is to
ensure consistent output if the last grep happens to get called with
one pathname.)

Alternatively you can add quoting to the xargs input, e.g.:

find . -name "*.xml" | sed 's/[^[:alnum:]]/\\&/g' |
xargs -E "" grep -i 'fillInBlankTestItem' /dev/null

but this won't work in the unlikely event that it encounters a
filename with a newline in it.

--
Geoff Clare

[Database Administrator]

2008-11-7, 13:44(+00), Geoff Clare:
[...]
> Alternatively you can add quoting to the xargs input, e.g.:
>
> find . -name "*.xml" | sed 's/[^[:alnum:]]/\\&/g' |
> xargs -E "" grep -i 'fillInBlankTestItem' /dev/null

You could as well use sed 's/./\\&/g'

> but this won't work in the unlikely event that it encounters a
> filename with a newline in it.

In which case, you could use this as given in the xargs man page
from the heirloom toolchest:

find .//. -name '*.xml' -print | sed 's/./\\&/g' | awk '{
if (NR > 1) {
printf("%s", line)
if ($0 !~ /\\\/\\\//)
printf("\\")
printf("\n")
}
line = $0
}
END {
print(line)
}' | xargs -E '' grep -i fillInBlankTestItem /dev/null

--
Stéphane

[Database Administrator]

Stephane CHAZELAS wrote:

> 2008-11-7, 13:44(+00), Geoff Clare:
> [...]
>> Alternatively you can add quoting to the xargs input, e.g.:
>>
>> find . -name "*.xml" | sed 's/[^[:alnum:]]/\\&/g' |
>> xargs -E "" grep -i 'fillInBlankTestItem' /dev/null
>
> You could as well use sed 's/./\\&/g'

That will double the line length, increasing the risk of an input
line being too long for xargs. Although unlikely to be a problem
in practice, POSIX only requires xargs to accept lines up to
LINE_MAX (which can be as low as 2048) bytes in length.

Adding backslash before all non-alphanumerics is a compromise
which does increase this risk slightly, but avoids the quoting
contortions that are needed to add backslash before only the
characters that are special to xargs.

--
Geoff Clare

[Database Administrator]

2008-11-10, 13:49(+00), Geoff Clare:
> Stephane CHAZELAS wrote:
>
>> 2008-11-7, 13:44(+00), Geoff Clare:
>> [...]
>>> Alternatively you can add quoting to the xargs input, e.g.:
>>>
>>> find . -name "*.xml" | sed 's/[^[:alnum:]]/\\&/g' |
>>> xargs -E "" grep -i 'fillInBlankTestItem' /dev/null
>>
>> You could as well use sed 's/./\\&/g'
>
> That will double the line length, increasing the risk of an input
> line being too long for xargs. Although unlikely to be a problem
> in practice, POSIX only requires xargs to accept lines up to
> LINE_MAX (which can be as low as 2048) bytes in length.
>
> Adding backslash before all non-alphanumerics is a compromise
> which does increase this risk slightly, but avoids the quoting
> contortions that are needed to add backslash before only the
> characters that are special to xargs.

OK thanks.

Note that it will double the line length in number of characters
but not necessarily in number of bytes in multi-byte locales.

BTW, I don't think there's any guarantee that the output of find
will be valid in the user's charset. For instance, I've seen
many cases of file names encoded in latin1 while the user has a
UTF8 locale. I wonder how the above command line would behave in
such a case. Maybe a more robust version would be:


find . -name '*.xml' |
LC_ALL=C sed 's/[[:blank:]'\''\"]/\\&/g' |
user_locale=$(locale) LC_ALL=C xargs sh -ac '
eval "$user_locale"
exec grep -i fillInBlankTestItem /dev/null "$@"
' inline "$@"

Which has the adverse side effect of potentially having xargs or
sed display their error messages not in the user's language, so
you might want:

run_with_C_CTYPE() (
set -a
eval "$(locale | sed 's/^LC_CTYPE=.*/LC_CTYPE=C/')"
unset LC_ALL
exec "$@"
)
find . -name '*.xml' |
run_with_C_CTYPE sed 's/[[:blank:]'\''\"]/\\&/g' |
user_locale=$(locale) run_with_C_CTYPE xargs sh -ac '
eval "$user_locale"
exec grep -i fillInBlankTestItem /dev/null "$@"
' inline "$@"

At which point anyone sensible would probably start considering
alternatives to shell scripts...

--
Stéphane

[Database Administrator]

Stephane CHAZELAS wrote:

>>> find . -name "*.xml" | sed 's/[^[:alnum:]]/\\&/g' |
>>> xargs -E "" grep -i 'fillInBlankTestItem' /dev/null

[snip]
> BTW, I don't think there's any guarantee that the output of find
> will be valid in the user's charset. For instance, I've seen
> many cases of file names encoded in latin1 while the user has a
> UTF8 locale. I wonder how the above command line would behave in
> such a case.

GNU sed and xargs don't seem to care, but Solaris 10 produces:

xargs: Corrupt input file: Illegal byte sequence

(but no error from sed, strangely).

Yet another reason to avoid using find ... | xargs ...
(or any other use of xargs where the input contains pathnames).

> Maybe a more robust version would be:
>
>
> find . -name '*.xml' |
> LC_ALL=C sed 's/[[:blank:]'\''\"]/\\&/g' |
> user_locale=$(locale) LC_ALL=C xargs sh -ac '
> eval "$user_locale"
> exec grep -i fillInBlankTestItem /dev/null "$@"
> ' inline "$@"
>
> Which has the adverse side effect of potentially having xargs or
> sed display their error messages not in the user's language, so
> you might want:
>
> run_with_C_CTYPE() (
> set -a
> eval "$(locale | sed 's/^LC_CTYPE=.*/LC_CTYPE=C/')"
> unset LC_ALL
> exec "$@"
> )
> find . -name '*.xml' |
> run_with_C_CTYPE sed 's/[[:blank:]'\''\"]/\\&/g' |
> user_locale=$(locale) run_with_C_CTYPE xargs sh -ac '
> eval "$user_locale"
> exec grep -i fillInBlankTestItem /dev/null "$@"
> ' inline "$@"
>
> At which point anyone sensible would probably start considering
> alternatives to shell scripts...

Or would vow to always use "find ... -exec ... {} +" instead
(which means either avoiding old systems whose native find doesn't
support the '+' terminator, or installing GNU find on them).

--
Geoff Clare

[Database Administrator]

Geoff Clare wrote:

> Or would vow to always use "find ... -exec ... {} +" instead
> (which means either avoiding old systems whose native find doesn't
> support the '+' terminator, or installing GNU find on them).

or AST find (from AT&T/D.Korn at al) [1], large toolchest;
or the Heirloom toolchest (Gunnar Ritter) [2], large toolchest,
additionally researching portability (SUS, SVRx, 4BSD);
or sfind (from Jörg Schilling) [3], just the find utility.

[1] http://www.research.att.com/sw/download/
[2] http://heirloom.sourceforge.net/tools.html
[3] ftp://ftp.berlios.de/pub/sfind/

[HENARRY JAYA]

Just ensure that you are inserting the proper disk. CD+R medias are different from the DVD. You drive is just working fine. It happens that it detects a CD+R media on the drive that is why it change into DVD+RAM into CD Drive.
I think you should change another better one, but at first you should note, you can't upload .mswmm video to you tube, .mswmm is windows movie maker project file, not video file, so you should publish the video as wmv video in WMM, and you should note you tube only support some video formats, not all, so you should convert you videos to right you tube video format before upload..