#!/bin/bash

# At first, experiments indicated (rather to my surprise) that the
# filename glob expansion of ".*" does not include "." nor ".."?  At
# least in /bin/sh on Debian (which is dash these days).  It seemed
# to be special-cased, too.  I ran 'touch ...; ls -ld .*' (note: in
# Bash) and saw the new "..." in the output but not "." nor "..".
# So apparently the rule was not simply "expanding * never generates a
# string with a leading dot that follows only dots" or something like
# that, but just "filename expansion shall not generate '.' or '..'".
# 
# This contradicted what https://unix.stackexchange.com/questions/1180/\
# is-the-behaviour-of-to-include-and-defined-in-lsb-or-posix-or-some-other
# says (that page is the closest I can find to an in-depth discussion
# of the matter), so I wasn't sure how much I wanted to depend on this
# behavior.  I have the option of setting GLOBIGNORE if I want to be
# cautious -- and caution seems to be warranted, because the globbing
# behaves differently when invoked from within this script (which at
# that time used /bin/sh, hence Dash) than when invoked manually on
# the command line (in Bash):
# 
#   @private>du -sh * .* | grep -F "G$(printf '\t')"
#   17G	backups
#   96G	bigdata
#   2.5G	infra
#   28G	work
#   4.2G	.svn
#   @private>~/bin/dub
#   17G	backups
#   96G	bigdata
#   2.5G	infra
#   28G	work
#   4.8G	.
#   85G	..
#   @private>cat du.out 
#   17G	backups
#   96G	bigdata
#   2.5G	infra
#   28G	work
#   4.8G	.
#   85G	..
#   @private>
#
# Notice how the ".svn" directory is missing from the Dash output too.
# 
# After I switched this script to /bin/bash, the inconsistency went
# away.  So there's something interesting going on with filename
# wildcard expansion in Dash; it might affect other scripts, and I
# should keep an eye out for it.  In the meantime, though, *this*
# script is definitely going to use /bin/bash!

du -sh * .* | grep -F "G$(printf '\t')" | tee du.out