Is there a simple command, or string of commands to
quickly tell whether a directory is empty or not?
I can write a script, but I'd prefer a command
if there is one.
Thanks,
Argosy
Sent via Deja.com http://www.deja.com/
Before you buy.
>HI all,
>
>Is there a simple command, or string of commands to
>quickly tell whether a directory is empty or not?
>
>I can write a script, but I'd prefer a command
>if there is one.
There are a number of commands that will do this
ls and du are the ones that come first to my mind.
Of course, you've probably discarded ls as a choice, but it _does_
tell you whether the directory is empty or not.
OTOH, du can provide a simple answer
du -s directory
will show 1 if the directory is empty, and more than one if it has
members.
For instance:
srdscs05:~$ rm -rf temp
srdscs05:~$ mkdir temp
srdscs05:~$ mkdir temp/empty
srdscs05:~$ du -s temp
2 temp
srdscs05:~$ du -s temp/empty
1 temp/empty
srdscs05:~$
Lew Pitcher
Information Technology Consultant
Toronto Dominion Bank Financial Group
(Opinions expressed are my own, not my employer's.)
Or you can write a 'C' program yourself using scandir() and a function
which will drop "." and "..".
If you need additional info, E-Mail me.
-tony
--
Anti-spam filter: I am not root@localhost
trb@teleport dot com COM Public Access User --- Not affiliated with Teleport
argo...@my-deja.com wrote:
> HI all,
>
> Is there a simple command, or string of commands to
> quickly tell whether a directory is empty or not?
>
> I can write a script, but I'd prefer a command
> if there is one.
>
> Thanks,
>
> Argosy
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
============
#!/bin/sh
if [ -d $1 ]
then
if [ -f $1/* ]
then
:
else
echo $1 directory is empty
fi
else
echo $1 directory cannot be found
fi
============
--Kurt
External SW Du(1)?! Library function scandir(3)?! What if the above
directory has invisible (dot) files?
The appropriate function is:
#! /bin/echo error: only source
#*TAG:55702 1:Oct 31 1998:0644:isemptydir:
# Author: Brian Hiles <b...@iname.com>
# Copyright: (c) 1998
# Description: determine if a directory is empty
# Name: isemptydir
# Requires:
# Sccs: @(#)isemptydir.sh 1.1 1997/12 b...@iname.com (Brian Hiles)
# Usage: isemptydir dir...
# Version: 1.01
#01
isemptydir() # [dir]
{ test 0$# -gt 1 && echo 'usage: isemptydir [dir]' >&2 && return 2
( cd ${1:-.} || return 2
set +f
set -- .??* .[!.] *
case $#$* in
'3.??* .[!.] *')
return 0 ;;
*) return 1 ;;
esac
)
}
#02 EMBEDDED MAN-PAGE FOR "src2man"
: '
#++
NAME
isemptydir - determine if a directory is empty
SYNOPSIS
DESCRIPTION
RETURN CODE
0 if the directory argument is empty, 1 if not, and 2 if the
parameter is not a directory or does not have its executability
(chdir) bit set.
SEE ALSO
isnum(1S)
BUGS
Alright already! So if there are _exactly_ three files named
_exactly_ ".??*", ".[!.]", and "*", then isemptydir will fail.
(And pigs can fly.)
#--
'
This will not work. What if $1/* expands to more than 1 word? '[' will
complain that it's receiving too many parameters.
Moshe
--
jehsom@ angband.org cc.gatech.edu polter.net shaftnet.org nullity.dhs.org
wreck.org bellsouth.net resnet.gatech.edu burdell.org yo.dhs.org gooning.org
usa.net togetherweb.com resnet.gatech.edu; gte741e mj116 @prism.gatech.edu;
jacobsonconsulting@ usa.net; ICQ 1900670
So far, none of the answers address the possiblity of hidden files.
Neither du -s nor [ -f dir/* ] check for the existance of hidden
files. The -f method also neglects any files that are NOT ordinary
files. This includes links, directories, named pipes, etc.
One easy, but not so great method is to attempt to remove the directory
If it removed, it was empty and could be recreated. This does however,
change the time stamp of the directory.
if rmdir /path/to/dir
then
echo "/path/to/dir is empty"
mkdir /path/to/dir
else
echo "/path/to/dir is NOT empty:
fi
Another method might be:
([ -e /path/to/dir/.* ] || [ -e /path/to/dir/* ]) && echo NON empty || echo
empty
Yet another:
[[ $(ls -Ab |wc -l) -ne 0 ]] && echo NON empty || echo empty
- Matt
--
_______________________________________________________________________
Matthew Landt - AIX and HACMP Cert. Specialist - la...@austin.ibm.com
<< Comments, views, and opinions are mine alone, not IBM's. >>
>Is there a simple command, or string of commands to
>quickly tell whether a directory is empty or not?
How about:
ls -a | wc -w
2 if the directory is empty, more than that if it's not.
[and probably 0 if it's been deleted out from under you...]
--
-- Paul A. Sand | But let your communication be Yea, yea;
-- University of New Hampshire | nay, nay: for whatsoever is more than these
-- p...@unh.edu | cometh of evil. (Matthew 5:37)
-- http://pubpages.unh.edu/~pas |
That seems pretty easy to me
Lew Pitcher wrote:
> On Wed, 16 Aug 2000 15:49:40 GMT, argo...@my-deja.com wrote:
>
> >HI all,
> >
> >Is there a simple command, or string of commands to
> >quickly tell whether a directory is empty or not?
> >
> >I can write a script, but I'd prefer a command
> >if there is one.
>
There are lots of ways. The one I like best is rmdir.
if
rmdir $DIR
then
mkdir $DIR
echo "$DIR is empty"
else
echo "$DIR not empty"
fi
This has a race condition and a couple of other side
effects.
There is no actual way to tell if the directory is
really empty. You can use things like ls to see if
the directory was empty some (usually short) time ago
but you've got no reason to believe that it is still
empty since you've checked.
chris
>Is there a simple command, or string of commands to
>quickly tell whether a directory is empty or not?
You can use the find command on an dir and count the number of
output. If output is one (the dir itself only), it is empty.
#!/bin/sh
is_empty()
{
dir=$1
num=`find $dir | wc -l`
if [ $num -eq 1 ]
then return 0
else return 1
fi
}
if is_empty $1
then echo $1 empty
else echo $1 not empty
fi
>Is there a simple command, or string of commands to
>quickly tell whether a directory is empty or not?
You can use the ls command on an dir and count the number of
output. If output is two (./ and ../), it is empty.
#!/bin/sh
is_empty()
{
dir=$1
num=`ls -CFa1 $dir | wc -l`
if [ $num -eq 2 ]
Close.
#! /bin/bash
is_empty_dir() {
if [ $# -ne 1 -o ! -d "$1" ];then
echo "usage: $0 [directory]"
exit 1
fi
files=`ls -1A $1`
if [ "$files" ];then
# non-empty directory
return 1
else
# empty directory
return 0
fi
}
--
+----------------------------------------------------------------+
| Bob Taylor Email: brta...@inreach.com |
|----------------------------------------------------------------|
| [Concerning MSFT innovating their way out of a wet paper bag.] |
| "Maybe if it were a very very wet paper bag, but then they'd |
| face the insurmountable barrier of surface tension." |
| -- Geoffrey Tobin <G.T...@latrobe.edu.au> |
+----------------------------------------------------------------+
How about test -z "`ls -A directory`" ?
-WBE
Not necessarily, for either case:
$ mkdir foo
$ touch foo/bar
$ du foo
1 foo
$ # note that foo is not empty, but du reports 1
$ n=0; while ((n < 500)); do touch foo/bar$n; ((n+=1)); done
$ rm -f foo/*
$ du foo
8 foo
$ # now foo is empty, but reports more than 1
--Ken Pizzini
> Is there a simple command, or string of commands to
> quickly tell whether a directory is empty or not?
Why not use rmdir?
# rmdir $dir
# if [ $(?) -ne 0 ]; then
# echo "directory $dir is not empty"
# else
# mkdir $dir
# echo "directory $dir is empty"
# fi
Tschuess
Peter
This question comes up periodically and usually is a sign that the
asker has not thought out the problem clearly. In a multi-user,
multi-tasking system, the emptiness of a directory can only be tested
atomically by removing the directory with rmdir. This is rarely a
practical thing to do. In many cases this question is asked by people
who simply want to know if it is "safe" to remove a directory, as if
running rmdir on a directory with files would do some harm.
The following ksh function will determine if a directory is empty in the
transitory period when the for statement is processed:
function isEmptyDir
{
# Format: isEmptyDir [dirname] - default "."
typeset file dir=${1:-.}
[[ -d $dir ]] || { print -u2 "$0: $dir is not a directory"; return 2; }
for file in $dir/.* $dir/*
do
case ${file#$dir/} in
.|..) ;;
[*]) [[ -a $file ]];let $?;return;;
*) return 1;;
esac
done
}
If the directory is empty, the for loop will give values of
".", ".." and "*" to the case statement. If not, either
"*" will turn out to be a legitimate filename or some other
filename will match *).
This is doable in Bourne shell and is left as an exercise to the reader.
The real question is, Why do you want to know if the directory is
empty?
--
Dan Mercer
dame...@uswest.net
[snip]
> The real question is, Why do you want to know if the directory is
> empty?
I have a dynamic IP and run sendmail -q from a script via cron every
15 minutes. I don't want to bring up the PPP link if there is no
email. The problem is fetchmail will sometimes leave garbage in
/var/spool/mqueue. I use a combination of isdirempty and mailq. I
honestly can't think of any other reason except for other similar
problems. (shrug)
Bob
--
+----------------------------------------------------------------+
| Bob Taylor Email: brta...@inreach.com |
+----------------------------------------------------------------+
A legitimate reason. What is really needed are hooks into the OS
for file system events that you could capture - attaching to the open,
close,read and write and [un]link activities - that way you could
catch files being linked into or removed from a directory and keep a
count. It's the kind of dangerous utility I would restrict to
root, however. Tooltalk fudges some of this kind of thing but at
a large expense, and TT is hardly user friendly.
--
Dan Mercer
dame...@uswest.net
In that case you should stick with just sendmail -bp (== mailq) to check the
queue. If you expect the queue directory to be empty, your script will be
fooled by a df or xf file left lying around with no associated qf file. This
happens sometimes when a sendmail is killed while it is in the process of
queueing or delivering a message. You can then end up with files in
/var/spool/mqueue that don't represent valid queue jobs. These files will hang
around indefinitely until something else actually removes them; sendmail won't
touch them. Many OSes have a root cron job or startup script that removes old
files in the queue directory for this reason.
--
Jefferson Ogata : Internetworker, Antibozo
smtp: <og...@pobox-u-spam-u-die.com> http://www.antibozo.net/ogata/ ICQ: 19569681
whois: jo...@whois.networksolutions.com finger: og...@pobox-u-spam-u-die.com
This is why my ckmail script checks if the mailq returns "Mail queue
is empty" *and* isdirempty. I then rm the garbage files. Please
remember I am *not* on line 24/7.
--
+----------------------------------------------------------------+
| Bob Taylor Email: brta...@inreach.com |
Yes, that was clear from your post. What I don't understand is why you feel
compelled to mess with the queue directory at all. Why not just leave it alone?
There's no simple way to decide whether files in the queue directory are
"garbage files" other than that they are older than your bounce time, which is
five days by default. Run a daily cron job to remove files more than five days
old if you like. Any other tinkering with the queue directory exposes you to a
race condition in which you delete mail while it's being queued. If a sendmail
is in the process of queueing a message when your script fires off, the job may
not show up in your mailq results, yet it may place files in the queue
directory between your mailq check and your isemptydir check. You'll end up
nuking valid queue files, thinking they are "garbage".
Because rmdir+mkdir will not preserve the permissions on the
directory?
--Ken Pizzini
And besides, they'll fail if you're not the owner.
--
_ _ ___ ___ ___ ___ ___
unreal at fly dot srk dot fer dot hr / Y \/. |\/ __\/ -_)/ - \/ (_
http://unreal.srk.fer.hr/ \___/\|__/\_)\/\___/\_|_/\___/
gsm://+385.98.729.169/ Feel the Art.
If the system is set up correctly, running sendmail -q shouldn't bring up
the PPP link if there is no email queued.
mrc
--
Mike Castle Life is like a clock: You can work constantly
dal...@ix.netcom.com and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
I wanted to delete all empty directories. I ended up using
scripts like this a few minutes after I put the posting on.
find . -type d > file.txt
(I know that I don't need the .txt. But with it, I can tell
instantly what kind of file it is. Much faster than running
the file command.)
cat file.txt | while read DIRNAME
do
FILECOUNT=`ls -1 $DIRNAME | wc -l `
if [ $FILECOUNT -eq 0 ]
then
echo "removing " $DIRNAME
rmdir $DIRNAME
fi
done
It worked, but it was a few step process. Thanks for all your
suggestions. I'll try them next time I have lots of empty
directories to remove.
Thanks!
argo...@my-deja.com wrote:
> HI all,
>
> Is there a simple command, or string of commands to
> quickly tell whether a directory is empty or not?
>
OK. I'll see if this works. Thanks.
Because it doesn't work if you're not allowed to remove
the directory.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a- C++ UH++++$ UL++++ P+@ L+++ E(-) W+$@ N++ !K w !O
!M V PS(+) PE Y+ PGP(+) t- 5? !X R tv--- b+ DI? D G e+ h--- r+++ y+
"...cancel my subscription to the resurrection!" (Jim Morrison)
You should have said that in the first place... :-)
It would have prevented some second guessing.
> I ended up using
> scripts like this a few minutes after I put the posting on.
>
> find . -type d > file.txt
>
> cat file.txt | while read DIRNAME
> do
> FILECOUNT=`ls -1 $DIRNAME | wc -l `
> if [ $FILECOUNT -eq 0 ]
> then
> echo "removing " $DIRNAME
> rmdir $DIRNAME
> fi
> done
This can be simplified (without the "removing dir" part) thusly:
find . -type d | xargs rmdir
If your rmdir is gnu, try adding a "--verbose". Even better, if
find and xargs are also gnu:
find . -type d -print0 | xargs -0 rmdir --verbose
Now, these don't remove any directory (including the current dir)
that becomes empty during execution of the command. If you want
to do that, you could repeat the above until no directories are
removed, or use sort:
find . -type d -print0 | sort -rz | xargs -0 rmdir --verbose
The -r to sort reverses the order, the -z uses 0 instead of \n
for compatibility with -print0.
HTH,
--
Craig Peterein
mailto:`echo NniO...@aPpcAi.nMet | sed 's/[NOSPAM]//g'`
IRIX 5.x (and 6.x, presumably) had/has just such a feature. Wish I
could remember what the name was....
-Brian
Use the -depth switch as well if you want that to work.
Martien
--
Martien Verbruggen |
Interactive Media Division | The gene pool could use a little
Commercial Dynamics Pty. Ltd. | chlorine.
NSW, Australia |
I wanted to keep a list of all the directories that I did delete,
just in case the users came back to me.
In article <39A0099B...@aPpcAi.nMet>,
Craig Peterein <NniO...@aPpcAi.nMet> wrote:
> argo...@my-deja.com wrote:
> > argo...@my-deja.com wrote:
> > > HI all,
> > >
> > > Is there a simple command, or string of commands to
> > > quickly tell whether a directory is empty or not?
> >
> > I wanted to delete all empty directories.
>
> You should have said that in the first place... :-)
> It would have prevented some second guessing.
>
> > I ended up using
> > scripts like this a few minutes after I put the posting on.
> >
> > find . -type d > file.txt
> >
> > cat file.txt | while read DIRNAME
> > do
> > FILECOUNT=`ls -1 $DIRNAME | wc -l `
> > if [ $FILECOUNT -eq 0 ]
> > then
> > echo "removing " $DIRNAME
> > rmdir $DIRNAME
> > fi
> > done
>
> This can be simplified (without the "removing dir" part) thusly:
>
> find . -type d | xargs rmdir
>
> If your rmdir is gnu, try adding a "--verbose". Even better, if
> find and xargs are also gnu:
>
> find . -type d -print0 | xargs -0 rmdir --verbose
>
> Now, these don't remove any directory (including the current dir)
> that becomes empty during execution of the command. If you want
> to do that, you could repeat the above until no directories are
> removed, or use sort:
>
> find . -type d -print0 | sort -rz | xargs -0 rmdir --verbose
>
> The -r to sort reverses the order, the -z uses 0 instead of \n
> for compatibility with -print0.
>
> HTH,
>
> --
> Craig Peterein
> mailto:`echo NniO...@aPpcAi.nMet | sed 's/[NOSPAM]//g'`
>
I wanted to keep a file of what I had deleted, just in case the
users came back to me. My example is simplified.
NO! Have you tried it? I get:
$ cat t1
mkdir YY
touch "YY/.??*"
touch "YY/.[!.]"
touch "YY/*"
(
cd YY
/bin/ls -la
set -- .??* .[!.] *
echo "$#$*"
case "$#$*" in
'3.??* .[!.] *') echo "recognized as EMPTY" ;;
*) echo "recognized as NOT empty" ;;
esac
)
$ sh t1
total 4
-rw-rw---- 1 heiner drb 0 Aug 21 22:33 *
drwxrwx--x 2 heiner drb 1024 Aug 21 22:33 .
drwxrwx--x 3 heiner drb 1024 Aug 21 22:33 ..
-rw-rw---- 1 heiner drb 0 Aug 21 22:33 .??*
-rw-rw---- 1 heiner drb 0 Aug 21 22:33 .[!.]
4.??* .[!.] .[!.] *
recognized as NOT empty
$
Even with two files ".??* .[!.]" * I get:
total 4
-rw-rw---- 1 heiner drb 0 Aug 21 22:34 *
drwxrwx--x 2 heiner drb 1024 Aug 21 22:34 .
drwxrwx--x 3 heiner drb 1024 Aug 21 22:34 ..
-rw-rw---- 1 heiner drb 0 Aug 21 22:34 .??* .[!.]
3.??* .[!.] .[!.] *
recognized as NOT empty
$
However, when there is exactly one file ".??*", then:
total 4
drwxrwx--x 2 heiner drb 1024 Aug 21 22:41 .
drwxrwx--x 3 heiner drb 1024 Aug 21 22:41 ..
-rw-rw---- 1 heiner drb 0 Aug 21 22:41 .??*
3.??* .[!.] *
recognized as EMPTY
Bah :-(
Now, I propose to change your patterns:
set -- .??* .[!.] *
^--- star added
'3.??* .[!.]* *')
^--- star added
I'm currently not able to fool this one. But I am also not sure,
that it is not possible to fool it. So, it's your turn now. :-)
[ tested with /bin/sh on HP/UX 10.10 ]
Cheers,
--
Heiner Marxen hei...@drb.insel.de http://www.drb.insel.de/~heiner/
Er, I presume you mean:
set -- .??* .[!.]* *
so that it matches?:
> '3.??* .[!.]* *')
> ^--- star added
>I'm currently not able to fool this one. But I am also not sure,
>that it is not possible to fool it. So, it's your turn now. :-)
How about:
touch '.??* .[!.]*' '*'
or:
touch '.??* .[!.]* *'
?
My turn to propose a variation:
set .??* * .[!.]
case $#$* in
'3.??* * .[!.]') echo "current directory is EMPTY" ;;
*) echo "current directory DOES have entries" ;;
esac
And I'll even offer a proof of correctness: this script will
never print "EMPTY" for any directory that isn't empty at the
time of the "set" command, and will always print "DOES have
entries" when in a directory which does have entries:
1. We only need to consider files named:
a) .??*
b) .??* *
c) .??* * .[!.]
d) *
e) * .[!.]
f) .[!.]
as any other filename will wind up interpolated into the
$#$* case target in a manner which cannot match the
candidate case string. (Proof of this lemma: first, we only
need consider filenames which are nonempty substrings of
".??* * .[!.]", and then, assuming that the first character
of $IFS is a <space> (which this whole subthread has already
been implicity assuming), the only allowable substrings are
those bounded by an end of the full string and/or a space,
as otherwise the $IFS space winds up being interpolated at a
point which will cause the match to fail.)
Any other substring will immediately be accepted as evidence
that at last one directory entry.
2. The above individual possibilites can be reduced further to
the following combinations (using the labels from (1)):
adf
ae
bf
c
any other combination will fail to match the text after the
3 in the case glob --- all other combinations either yield
too long a string, too short a string, or a string with the
components in the wrong order.
Any other combination will be immediately accepted as
evidince that there is at least one directory entry
in the monitored.
3. Now the number of cases is small enough to directly enumerate:
adf --- declared non-empty because $#$* becomes '4.??* .[!.] * .[!.]'
ae --- declared non-empty because $#$* becomes '3.??* * .[!.] .[!.]'
bf --- declared non-empty because $#$* becomes '4.??* * .[!.] * .[!.]'
c --- declared non-empty because $#$* becomes '3.??* * .[!.] * .[!.]'
--Ken Pizzini
Wouldn't adding a simple "> file_of_what_I_had_deleted" to the
end of Craig's command-line satisfy that need?
--Ken Pizzini
Oops, yes, sorry for the confusion. You are right.
>>I'm currently not able to fool this one. But I am also not sure,
>>that it is not possible to fool it. So, it's your turn now. :-)
>
>How about:
> touch '.??* .[!.]*' '*'
Here the first file would expand twice, for the first and second pattern:
--> 3.??* .[!.]* .??* .[!.]* *
>or:
> touch '.??* .[!.]* *'
>?
Similar effect as above:
--> 3.??* .[!.]* * .??* .[!.]* * *
>My turn to propose a variation:
> set .??* * .[!.]
> case $#$* in
> '3.??* * .[!.]') echo "current directory is EMPTY" ;;
> *) echo "current directory DOES have entries" ;;
> esac
>
>And I'll even offer a proof of correctness:
I had thought about a proof, but was too lazy and too tired, already.
> this script will
>never print "EMPTY" for any directory that isn't empty at the
>time of the "set" command, and will always print "DOES have
>entries" when in a directory which does have entries:
> 1. We only need to consider files named:
> a) .??*
> b) .??* *
> c) .??* * .[!.]
> d) *
> e) * .[!.]
> f) .[!.]
> as any other filename will wind up interpolated into the
> $#$* case target in a manner which cannot match the
> candidate case string. (Proof of this lemma: first, we only
> need consider filenames which are nonempty substrings of
> ".??* * .[!.]", and then, assuming that the first character
> of $IFS is a <space> (which this whole subthread has already
> been implicity assuming), the only allowable substrings are
> those bounded by an end of the full string and/or a space,
> as otherwise the $IFS space winds up being interpolated at a
> point which will cause the match to fail.)
Ok so far.
> Any other substring will immediately be accepted as evidence
> that at last one directory entry.
>
> 2. The above individual possibilites can be reduced further to
> the following combinations (using the labels from (1)):
> adf
> ae
> bf
> c
> any other combination will fail to match the text after the
> 3 in the case glob --- all other combinations either yield
> too long a string, too short a string, or a string with the
> components in the wrong order.
Sorry, but no, that is not correct. Here is case a:
mkdir YY
touch 'YY/.??*'
(
cd YY
/bin/ls -la
set .??* * .[!.]
echo "$#$*"
case "$#$*" in
'3.??* * .[!.]') echo "recognized as EMPTY" ;;
*) echo "recognized as NOT empty" ;;
esac
)
total 4
drwxrwx--x 2 heiner drb 1024 Aug 22 17:09 .
drwxrwx--x 3 heiner drb 1024 Aug 22 17:09 ..
-rw-rw---- 1 heiner drb 0 Aug 22 17:09 .??*
3.??* * .[!.]
recognized as EMPTY
The first pattern matches a file of the same name, and the other patterns
just stay there, since they do not match anything.
The point of my added star was, that a file with the name of the first
pattern will also match the extended ".[!.]*" pattern, which then does
not stand for itself, anymore.
This way we can show, that ".??* .[!.]* *" cannot be fooled by an existing
file, the name of which starts with ".??*", since that string would
appear a second time, and cause a pattern mismatch.
Now, that appears to be half a proof, already.
> Any other combination will be immediately accepted as
> evidince that there is at least one directory entry
> in the monitored.
>
> 3. Now the number of cases is small enough to directly enumerate:
> adf --- declared non-empty because $#$* becomes '4.??* .[!.] * .[!.]'
> ae --- declared non-empty because $#$* becomes '3.??* * .[!.] .[!.]'
> bf --- declared non-empty because $#$* becomes '4.??* * .[!.] * .[!.]'
> c --- declared non-empty because $#$* becomes '3.??* * .[!.] * .[!.]'
I have not checked these.
For the next try I suggest to write a shell script, that really tries
the different cases... we humans err all too often :-)
Unfortunately, I'm too lazy to do it myself :-(
Also I found another case fooling all of the above patterns: just a single "*".
So my new proposition is: .??* .[!.]* * ?
Each of the four partial patterns as a file name would be matched by two
of the partial patterns, and the file name would appear twice, causing
a mismatch.
And if any partial pattern matches a file name with an embedded blank,
the expansion result should have too many embedded blanks.
Well, I expect this one to really work.
Amazingly subtle!
> --Ken Pizzini
In article <8ntijp$t9r$5...@brokaw.wa.com>,
Gack --- I thought I tested before posting; obviously I should
have gone to bed instead of trying to compose that post.
>>My turn to propose a variation:
>> set .??* * .[!.]
>> case $#$* in
>> '3.??* * .[!.]') echo "current directory is EMPTY" ;;
>> *) echo "current directory DOES have entries" ;;
>> esac
>>
>>And I'll even offer a proof of correctness:
Which I didn't finish checking before hitting send, so of course
(by the Rule of Murphy) it was wrong...
>I had thought about a proof, but was too lazy and too tired, already.
I should have followed your lead then. ;)
[vast snippage of deft refutation of my alleged "proof"]
>Also I found another case fooling all of the above patterns: just a single "*".
>So my new proposition is: .??* .[!.]* * ?
>Each of the four partial patterns as a file name would be matched by two
>of the partial patterns, and the file name would appear twice, causing
>a mismatch.
>And if any partial pattern matches a file name with an embedded blank,
>the expansion result should have too many embedded blanks.
>Well, I expect this one to really work.
At least my post prompted you to think more carefully about the
problem and come up with a solution. :)
--Ken Pizzini
I am not sure if posix requires . and .. entries to be listed.
To be really sure try:
ls -a1 | grep -v '^.$
^..$' | wc -l
If you get zero then it is empty.
--
Stephen Baynes CEng MBCS Stephen...@soton.sc.philips.com
Philips Semiconductors Ltd
Southampton SO15 0DJ +44 (0)23 80316431 *** NEW ***
United Kingdom My views are my own.
Careful --- "." in a re matches any character, so you'd get
reports of "empty" whenever there is no entry with three or
more characters. Try this instead:
ls -a1 | egrep -cv '^\.\.?$'
--Ken Pizzini
>> How about:
>>
>> ls -a | wc -w
>>
>> 2 if the directory is empty, more than that if it's not.
>I am not sure if posix requires . and .. entries to be listed.
They don't have to be real directory entries, as long as they
"work right" in pathnames.
>To be really sure try:
>ls -a1 | grep -v '^.$
>^..$' | wc -l
>If you get zero then it is empty.
You forgot to quote the "." metacharacter. Also, it can be made more
efficient by using "ls -f" instead of "ls -a" (so that ls doesn't sort
its output) and by having grep count the lines itself:
ls -f | grep -cv '^\.$
^\.\.$'
--
Geoff Clare g...@unisoft.com
UniSoft Limited, London, England. g...@root.co.uk