[SOLVED] testing if a directory is empty

BW-userx · 03-11-2020, 12:46 PM

Quote:

Originally Posted by petelq

I did a brief test with "$(ls -A)=0" and it worked. But your way's good also.

I'd think that the -z in if [ -z "$(ls -A)" ]; then is basically doing what "$(ls -A)=0" is doing behind the scenes. it checks if empty somehow then pits it against the condition, returns true or false.

rknichols · 03-11-2020, 05:53 PM

Quote:

Originally Posted by petelq

I did a brief test with "$(ls -A)=0" before my original post and it worked. But your way's good also.

What happens if you have a single file named "0" there?

BW-userx · 03-11-2020, 08:49 PM

Quote:

Originally Posted by rknichols

What happens if you have a single file named "0" there?

Quote:

Originally Posted by bash page

string comparison

=

is equal to

if [ "$a" = "$b" ]

Caution

Note the whitespace framing the =.

if [ "$a"="$b" ] is not equivalent to the above.
==

is equal to

if [ "$a" == "$b" ]

This is a synonym for =.

Note

The == comparison operator behaves differently within a double-brackets test than within single brackets.

[[ $a == z* ]] # True if $a starts with an "z" (pattern matching).
[[ $a == "z*" ]] # True if $a is equal to z* (literal matching).

[ $a == z* ] # File globbing and word splitting take place.
[ "$a" == "z*" ] # True if $a is equal to z* (literal matching).

# Thanks, Stéphane Chazelas

---------------
A binary comparison operator compares two variables or quantities. Note that integer and string comparison use a different set of operators.

integer comparison

-eq

is equal to

if [ "$a" -eq "$b" ]

source:
https://tldp.org/LDP/abs/html/comparison-ops.html

rknichols · 03-11-2020, 10:46 PM

@BW-userx: Yes, I am well aware of that. I was wondering if @petelq had considered that $(ls -A) could return "0" for a non-empty directory.

BW-userx · 03-12-2020, 11:39 AM

Quote:

Originally Posted by rknichols

@BW-userx: Yes, I am well aware of that. I was wondering if @petelq had considered that $(ls -A) could return "0" for a non-empty directory.

yeah I gave thought to who I was posting that too after the fact. it was like wait a min he should know that ... but decided to leave it for others.

rtmistler · 03-12-2020, 11:44 AM

Quote:

Originally Posted by Skaperen

the purpose is simply to increase efficiency in a file scan generator, to avoid trying to read the list of names if there are none. it appears that the filesytem code or kernel reads at least one empty 4k block from the directory when trying to read names. that is probably good evidence that there is no way to determine that, at least for filesystems i have tried (ext2,ext3,ext4,btrfs,reiserfs). it's not a critical need. i can just go ahead and read the list of names and see if it is empty, or just not deal with being empty.

this project is a generator in python3 that yields each path in name sorted order with the file type (regular file vs directory, etc) included in the yielded tuple.

@Skaperen,

I've seen this thread as active a lot, but haven't followed along.

Is this solved, or are you still making a determination as to what your next move is?

dugan · 03-12-2020, 02:50 PM

This is how "find -empty" is implemented. The implementation just lists the directory and checks if it's empty:

https://git.savannah.gnu.org/cgit/fi...nd/pred.c#n349

GazL · 03-14-2020, 06:27 PM

for (dp = readdir (d); dp; dp = readdir (d))

That duplication of readdir(d) calls looks funky; I wonder what the author has against while ( )?

POSIX has this to say regarding readdir():

Quote:

If entries for dot or dot-dot exist, one entry shall be returned for dot and one entry shall be returned for dot-dot; otherwise, they shall not be returned.

I couldn't find anywhere where it says that the entries *must* exist, so checking for only two entries, as I did above, is likely making unsafe assumptions about the filesystem implementation, and is why they're doing it the way they are in the code dugan linked.

MadeInGermany · 03-15-2020, 08:13 AM

The for (dp = readdir (d); dp; dp = readdir (d)) is shorter than a
dp = readdir (d); while (dp) {
...
dp = readdir (d);
}
Further, there is code that sorts out . and ..
so it only finds other entries.
--
I still don't believe that
[ $(ls -A)=0 ]
can work. It is a conatenation of $(ls -A) and the string "=0".
Where the latter makes it always non-empty so the [ ] gives always true.
I only can imagine there might be a [ version out there stat can give error "two many arguments".

GazL · 03-15-2020, 11:08 AM

Quote:

Originally Posted by MadeInGermany

The for (dp = readdir (d); dp; dp = readdir (d)) is shorter than a
dp = readdir (d); while (dp) {
...
dp = readdir (d);
}

Yes, but it's not shorter than:

Code:

while ( dp = readdir(d) ) {
...
}

... which was what I was getting at.

MadeInGermany · 03-15-2020, 03:11 PM

That is indeed shorter!
Perhaps to be augmented with a comment "assign to dp and test for nonzero".

GazL · 03-16-2020, 06:34 AM

Quote:

Originally Posted by MadeInGermany

That is indeed shorter!
Perhaps to be augmented with a comment "assign to dp and test for nonzero".

Personally, I wouldn't comment that. If you want to be more explicit then you could write it as:

Code:

while ( (dp = readdir(d)) != NULL ) {
...
}

... but the implicit comparison in my previous example is unlikely to throw any experienced C programmers a curveball. gcc does prefer you to wrap the assignment in an additional but unnecessary set of parenthesis(when using the implicit form), otherwise it will throw out a warning: supposedly, it helps catch common '=' vs '==' substitution errors.

I know some folks prefer for() over while() because a "while(something);" when looked at out of context can be confused with the end of a "do/while(something);", but that's always struck me as a pretty weak-minded rationale. I am genuinely interested in why they chose a for() there.

pan64 · 03-16-2020, 07:10 AM

Quote:

Originally Posted by Skaperen

the purpose is simply to increase efficiency in a file scan generator, to avoid trying to read the list of names if there are none.

That is just nonsense. You need to read the directory to know if there were any object inside. If something found you can walk thru, if not you can just skip the given dir.
Any attempt to calculate the number of objects will slow down the execution: if there was anything inside (because that would be just a superfluous extra step) and will not speed up anything if that dir was empty.

Skaperen · 03-26-2020, 01:10 AM

if there was a way to determine that a directory is empty from its inode, then that would avoid reading the directory's data block(s) for instances of an empty directory. what if this is a huge tree with millions of directories that could be empty. my intent was to determine this from a stat() or the like, which would get the inode from the cache if not reading it for the very first time. since the inode does not record this information, this is all a moot effort.

pan64 · 03-26-2020, 03:05 AM

still nonsense: creating an external counter/status info will be a huge overhead on directory handling (not to speak about the concurrent access to it) - just to make directory reading slightly and occasionally faster.
But anyway: you are allowed to design your own filesystem.