[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse
Subject:    Re: [opensuse] BASH - better way to get total number of files
From:       Jon Clausen <jon () ymmv ! dk>
Date:       2010-05-28 7:32:14
Message-ID: 20100528073214.GA2458 () nx8220 ! ymmv ! dk
[Download RAW message or body]

On Fri, 28 May, 2010 at 00:50:56 +0200, Philipp Thomas wrote:
> On Thu, 27 May 2010 19:41:37 +0200, Jon Clausen <jon@ymmv.dk> wrote:
> 
> >So if one has to do 'file type' operations on the objects later, one would
> >have to amend the code with some [ -f ${array[$i]} ] -ish tests, which might
> >end up eating away whatever performance gain one got to begin with.
> 
> Why? Bash has test built in AFAIK so you'd still have the advantage of
> no subprocess.

CMIIW:

unless you explicitly call /usr/bin/test then the shell *will* use the
builtin 'test' will it not?

Looking only at:

array=( $path/$glob )
vs.
array=( $(ls $path/$glob) )

- where the resulting arrays should be more or less identical - then the
former would 'win' over the latter, in that there are no subprocesses
involved.
The (potential) trouble with this is that such lists might need to be
'sanitized', in order to avert trouble.

What I meant was that overall one *might* be better off using something like
'find' to generate the list in such a way that it only contains the desired
type of objects to begin with.

so it becomes:

1: fast, lightweight generation of a 'dirty' list that must be cleaned
vs.
2: slower and 'heavier' generation of a 'clean' list

I guess it depends on the situation, but at least in some cases I think that
taking the 'filtering' penalty up front might be worth it in the end...

/jon

-- 
YMMV
-- 
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse+help@opensuse.org

[prev in list] [next in list] [prev in thread] [next in thread]