On Mon, Sep 22, 2008 at 1:04 AM, Ulrich Mueller <[EMAIL PROTECTED]> wrote:
>
> >>>>> On Sun, 21 Sep 2008, Steve Long wrote:
>
> > Vaeth wrote:
> >> let me remark that the more clever way to this is
> >> [ -n "${DOCS}" ] && eval "dodoc ${DOCS}"
>
> > [...]
> > BASH arrays will cope with *any* character apart from NUL, which
> > isn't allowed in filenames. Can you _guarantee_ the same?
>
> It seems to me that both bash arrays and "eval" are overkill here.
>
> After all, we are talking about a _default_ behaviour, and IMHO this
> should be kept as simple as possible. I doubt that there are many
> ebuilds installing files with strange names in /usr/share/doc. The few
> (if any) doing that might need a more complicated src_install anyway.
>
> My system may not be representative, but here are _no_ files
> containing spaces in /usr/share/doc:
>
> $ find /usr/share/doc | wc
>  104936  104936 7522127
>
> (Note that the number of lines and words are equal.)
>
> Ulrich
>

find /usr/share/doc/ -wholename "* *"
/usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2

And in case somebody gets space-phobic on a different directory :

find /usr/ -wholename "* *"
/usr/kde/4.2/share/applnk/Development/Web Development
/usr/kde/svn/share/applnk/Development/Web Development
/usr/share/applnk/Development/Web Development
/usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2
/usr/share/lcms/profiles/sRGB Color Space Profile.icm
/usr/share/mixxx/( Lots here )


 ¢¢ ( Apps that break on spaces are embarrasing )
--
Kent

ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil [EMAIL PROTECTED]"[(2*x)..(2*x+1)]}'

http://kent-fredric.fox.geek.nz

Reply via email to