2217
Comment: put bash solutions at top, removed bash-specific non-array solution (what's wrong with arrays?), removed ls -A solutions (if you want to not use a specific shell you may as well TRY to be portable)
|
6177
more posix sh approaches
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
[[Anchor(faq4)]] == How can I check whether a directory is empty or not? How do I check for any *.mpg files? == ''I just deleted three completely '''wrong''' answers from this question. Please, people, make sure that when you add to the FAQ, your answers'' * answer the question that was asked, and * actually '''work''' ''Thanks. -- GreyCat'' |
<<Anchor(faq4)>> == How can I check whether a directory is empty or not? How do I check for any *.mpg files, or count how many there are? == In Bash, you can do this safely and easily with the `nullglob` and `dotglob` options (which change the behaviour of [[glob|globbing]]), and an [[BashFAQ/005|array]]: |
Line 8: | Line 5: |
In BASH, you can do this safely and easily with the nullglob option (which changes the behaviour of [:glob:globbing]), and arrays: {{{ shopt -s nullglob files=(*) (( ${#files[*]} )) || echo directory is empty shopt -u nullglob |
{{{#!highlight bash # Bash shopt -s nullglob dotglob files=(*) (( ${#files[*]} )) || echo directory is empty shopt -u nullglob dotglob |
Line 17: | Line 13: |
As you can see we unset the nullglob after using it, to prevent it affecting other globs in the script in unexpected ways. `nullglob` also simplifies various other operations: | Of course, you can use any glob you like instead of `*`. E.g. `*.mpg` or `/my/music/*.mpg` works fine. |
Line 19: | Line 15: |
{{{ shopt -s nullglob for i in *.zip; do blah blah "$i" # No need to check $i is a file. done shopt -u nullglob |
Bear in mind that you need [[Permissions|read permission]] on the directory, or it will always appear empty. Some people dislike `nullglob` because having unmatched globs vanish altogether confuses programs like `ls`. Mistyping `ls *.zip` as `ls *.zpi` may cause every file to be displayed (for such cases consider setting `failglob`). Setting `nullglob` in a SubShell avoids accidentally changing its setting in the rest of the shell, at the price of an extra `fork()`. If you'd like to avoid having to set and unset shell options, you can pour it all into a SubShell: {{{#!highlight bash # Bash if (shopt -s nullglob dotglob; f=(*); ((! ${#f[@]}))); then echo "The current directory is empty." fi |
Line 27: | Line 26: |
Without the {{{nullglob}}}, that would have to be: | The other disadvantage of this approach (besides the extra `fork()`) is that the array is lost when the subshell exits. If you planned to ''use'' those filenames later, then they have to be retrieved all over again. |
Line 29: | Line 28: |
{{{ for i in *.zip; do [[ -f $i ]] || continue # If no .zip files, i becomes *.zip blah blah "$i" done |
Both of these examples expand a glob and store the resulting filenames into an [[BashFAQ/005|array]], and then check whether the number of elements in the array is 0. If you actually want to ''see'' how many files there are, just print the array's size instead of checking whether it's 0: {{{#!highlight bash # Bash shopt -s nullglob dotglob files=(*) echo "The current directory contains ${#files[@]} things." |
Line 36: | Line 37: |
(You may want to use the latter anyway, if there's a possibility that the glob may match directories in addition to files.) | You can also avoid the `nullglob` if you're OK with putting a non-existing filename in the array should no files match (instead of an empty array): |
Line 38: | Line 39: |
In fact, you may wish to avoid the ''direct'' question altogether. Usually people want to know whether a directory is empty... ''because'' they want to do something involving the files therein, etc. Look to the larger question. For example, one of these [:UsingFind:find-based examples] may be an appropriate solution: {{{ find "$somedir" -type f -exec echo Found unexpected file {} \; find "$somedir" -maxdepth 0 -empty -exec echo {} is empty. \; # GNU/BSD find "$somedir" -type d -empty -exec cp /my/configfile {} \; # GNU/BSD |
{{{#!highlight bash # Bash shopt -s dotglob files=(*) if [[ -e ${files[0]} || -L ${files[0]} ]]; then echo "The current directory is not empty. It contains:" printf '%s\n' "${files[@]}" fi |
Line 46: | Line 49: |
If your script needs to run with various shell implementations, you can try using an external program like python, perl, or find as indicated above, or you can try something like: | Without `nullglob`, if there are no files in the directory, the glob will be added as the only element in the array. Since `*` is a valid filename, we can't simply check whether the array contains a literal `*`. So instead, we check whether the thing in the array ''exists'' as a file. The `-L` test is required because `-e` fails if the first file is a [[BashFAQ/097|dangling symlink]]. |
Line 48: | Line 51: |
{{{ if [ "`printf %s foo/*`" = 'foo/*' ] && [ ! -e 'foo/*' ] then echo "foo is empty" fi |
If your script needs to run with various non-Bash shell implementations, you can try using an external program like python, perl, or [[UsingFind|find]]; or you can try one of these: {{{#!highlight bash # POSIX # Clobbers the positional parameters, so make sure you don't need them. set -- * if test -e "$1" || test -L "$1"; then echo "directory is non-empty" fi |
Line 55: | Line 62: |
Yes, it's ugly, but it should be more portable than anything depending on ls output. | At this stage, the positional parameters have been loaded with the contents of the directory, and can be used for processing. If you just want to count files: {{{#!highlight bash # POSIX # Note: this will miss any "dot files" n=0 for f in *; do if test -e "$f" || test -L "$f"; then n=$((n+1)); fi done printf "There are %d files.\n" "$n" }}} In the Bourne shell, it's even worse, because there is no `test -e` or `test -L`: {{{#!highlight bash # Bourne # (Of course, the system must have printf(1).) if test "`printf '%s %s %s' .* *`" = '. .. *' && test ! -f '*' then echo "directory is empty" fi }}} Of course, that fails if `*` exists as something other than a plain file (such as a directory or FIFO). The absence of a `-e` test really hurts. If you need to process dot files as well as non-dot files, without bash's `dotglob`, it gets ''really ugly''. Here is one Trick [[UsingFind|using find]]: {{{#!highlight bash # POSIX # Note: do NOT let find print the filename! It may contain newlines. # This one will recurse. If that is not desired, see below. n=$(find . -type f -exec sh -c 'for f; do printf \\n; done' x {} + | wc -l) printf "There are %d files.\n" "$n" }}} If you want it not to recurse, then you need to tell find not to recurse into directories. This gets really tricky and ugly. GNU find has a `-maxdepth` option to do it. With standard POSIX find, you're stuck with `-prune`. This is left as an exercise for the reader. Never try to [[ParsingLs|parse ls output]]. Even `ls -A` solutions can break (e.g. on HP-UX, if you are root, `ls -A` does the exact ''opposite'' of what it does if you're not root -- and no, I can't make up something that incredibly stupid). In fact, one may wish to avoid the ''direct'' question altogether. Usually people want to know whether a directory is empty ''because'' they want to do something involving the files therein, etc. Look to the larger question. For example, one of these [[UsingFind|find-based examples]] may be an appropriate solution: {{{#!highlight bash # Bourne find "$somedir" -type f -exec echo Found unexpected file {} \; find "$somedir" -maxdepth 0 -empty -exec echo {} is empty. \; # GNU/BSD find "$somedir" -type d -empty -exec cp /my/configfile {} \; # GNU/BSD }}} Most commonly, all that's really needed is something like this: {{{#!highlight bash # Bourne for f in ./*.mpg; do test -f "$f" || continue mympgviewer "$f" done }}} In other words, the person asking the question may have ''thought'' an explicit empty-directory test was needed to avoid an error message like `mympgviewer: ./*.mpg: No such file or directory` when in fact no such test is required. Support for a nullglob-like feature is inconsistent. In ksh93 it can be done on a per-pattern basis by prefixing with ~(N)<<FootNote(From: [[http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/2058]], which contains some good discussion.)>>: {{{#!highlight bash # ksh93 for f in ~(N)*; do .... done }}} ---- CategoryShell |
How can I check whether a directory is empty or not? How do I check for any *.mpg files, or count how many there are?
In Bash, you can do this safely and easily with the nullglob and dotglob options (which change the behaviour of globbing), and an array:
Of course, you can use any glob you like instead of *. E.g. *.mpg or /my/music/*.mpg works fine.
Bear in mind that you need read permission on the directory, or it will always appear empty.
Some people dislike nullglob because having unmatched globs vanish altogether confuses programs like ls. Mistyping ls *.zip as ls *.zpi may cause every file to be displayed (for such cases consider setting failglob). Setting nullglob in a SubShell avoids accidentally changing its setting in the rest of the shell, at the price of an extra fork(). If you'd like to avoid having to set and unset shell options, you can pour it all into a SubShell:
The other disadvantage of this approach (besides the extra fork()) is that the array is lost when the subshell exits. If you planned to use those filenames later, then they have to be retrieved all over again.
Both of these examples expand a glob and store the resulting filenames into an array, and then check whether the number of elements in the array is 0. If you actually want to see how many files there are, just print the array's size instead of checking whether it's 0:
You can also avoid the nullglob if you're OK with putting a non-existing filename in the array should no files match (instead of an empty array):
Without nullglob, if there are no files in the directory, the glob will be added as the only element in the array. Since * is a valid filename, we can't simply check whether the array contains a literal *. So instead, we check whether the thing in the array exists as a file. The -L test is required because -e fails if the first file is a dangling symlink.
If your script needs to run with various non-Bash shell implementations, you can try using an external program like python, perl, or find; or you can try one of these:
At this stage, the positional parameters have been loaded with the contents of the directory, and can be used for processing.
If you just want to count files:
In the Bourne shell, it's even worse, because there is no test -e or test -L:
Of course, that fails if * exists as something other than a plain file (such as a directory or FIFO). The absence of a -e test really hurts.
If you need to process dot files as well as non-dot files, without bash's dotglob, it gets really ugly. Here is one Trick using find:
If you want it not to recurse, then you need to tell find not to recurse into directories. This gets really tricky and ugly. GNU find has a -maxdepth option to do it. With standard POSIX find, you're stuck with -prune. This is left as an exercise for the reader.
Never try to parse ls output. Even ls -A solutions can break (e.g. on HP-UX, if you are root, ls -A does the exact opposite of what it does if you're not root -- and no, I can't make up something that incredibly stupid).
In fact, one may wish to avoid the direct question altogether. Usually people want to know whether a directory is empty because they want to do something involving the files therein, etc. Look to the larger question. For example, one of these find-based examples may be an appropriate solution:
Most commonly, all that's really needed is something like this:
In other words, the person asking the question may have thought an explicit empty-directory test was needed to avoid an error message like mympgviewer: ./*.mpg: No such file or directory when in fact no such test is required.
Support for a nullglob-like feature is inconsistent. In ksh93 it can be done on a per-pattern basis by prefixing with ~(N)1:
From: http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/2058, which contains some good discussion. (1)