Bugfix: Storing an empty key via batch/nbatch did not work (OOPS!)
Major overhaul: (For some time it's probably more safe to use the 0.8.2!)
- import and export commands.
- "Advanced timeout" which closes DB while in blocking reads/writes.
- Also little change in "bget" command to be more intuitive.
- "bdel" now can check for the data value like "delete".
CygWin Bugfix:
Open may break on EBUSY for some reason.  In this case the timeout was not effective.
The sleep time for timeouts now is seeded by rand() to distribute the waiting.

<b>Import/Export:</b>

XML like import and export allow easy copy of a DB contents:
<pre>dbm create DB2; dbm export DB1 | dbm import DB2</pre>
You can see this as a replacement for the missing "reorg" under CygWin.

<b>Option -a for advanced timeout added:</b>

This works like -q, but keeps the DB closed during most operations.
It has a higher overhead, as it must open the DB for each operation,
though, but it allows a better batch integration, for example:

<pre>
# Most missing feature in BASH are piped coprocesses
# (open zillions of pipes to zillions of coprocess each)
# You cannot help with <(proc) and >(proc) as this needs /dev/fd
# Idea:
# 3| creates a pipe from FD3 to STDIN
# |5 creates a pipe from STDOUT to FD5
# exec 3| process |4 exec 2|5 exec
# creates a coprocess, listening on FD3, writing to FD4 and FD5

{
# Save STDOUT to FD3; Note the unintuitive IO-redirection below:
exec 3>&1

find dir -type f -print |
dbm -a-1 filter DB/check |
while read -r a
do
	if check "$a"
	then
		echo "$a" >&4
	else
		echo "$a" >&5
	fi
# Trick: Bring back STDOUT from FD3
done 4>&1 >&3 |

# Pipe to "ok" was saved to FD4
dbm -a-1 nbatch DB/check ok 5>&1 >&3 |

# PIPE to "ko" was saved to FD5
dbm -a-1 nbatch DB/check ko
}
</pre>

Alternatively with files with filenames without TABs:

<pre>
find dir -type f -print |
dbm -a-1 filter DB/check |

# Read files from STDIN and output
# FILENAME TAB ok|ko
check |

# The character in '' is a TAB
dbm -a-1 brep DB/check '	'
</pre>

<b>The "bget" change is as follows:</b>

Previously following did not print anything:
<pre>dbm list DB | dbm bget DB</pre>
As "list" did not print out the lat LF the correct script was:
<pre>{ dbm list DB; echo; } | dbm bget DB</pre>
Now both work identically.  However if the last line is empty
it must terminate on an LF else "bget" ignores it.

Note that the old behavior is intended and still is present on
bget0 (so a line not terminated by 0 is considered invalid).

<b>Important Windows bug with online virus scanners</b>

The virus scanners can prohibit dbm to open the file.  In such cases
there is no other way than to switch off the virus scanner.

It seems to happen when the virus scanner is too slow to keep up the
pace with DBM, while DBM processes try to open the DB concurrently.
In this case as the online protection does a first virus scan on the
file and keeps it open such that it cannot be locked by another DBM
process in the meanwhile.  These other process sleeps and reopens the
file later.  However for this open the virus scanner starts a
second(!) parallel virus scan on the file (it must do so before the
open, else it would not be able to protect).  But when the sleep time
is not long enough for the first virus scan to finish, we now have a
deadlock, as no DBM can successfully lock the DBM file ever: It simply
always is open by one or more processes scanning the file against
viri.  This is even more complicated if the virus scanner runs under
the thread priority of the process, as then slow processes can lead to
hours (literally!) of unusable DBMs.

<b>Thats not a bug of DBM.  It's a fundamental design flaw of online
virus scanners under Windows.</b> So the only advice I can give is:
Under windows never even try to open DBM files concurrently while an
online virus scanner is active.  Period.

Side-Advice: <b>If you do not have a virus</b> but some computer
problem, then try to switch off the online virus scanner first.  Often
the problem vanishes.  For example, switching off my virus scanner
improves the "find.exe" from CygWin by factor 1000 or even much more.
(This is because the Virus scanner *must* scan all files find.exe
touches.  Again this is a fundamental flaw of online virus scanner
technology under Windows.)
