I've just looked over the code and it's not that long. I could change the style and remove a few features and have it down to 2k lines.
The measure should be whether you can get your head around the whole script at once. I'm fairly sure I can do that. It's a clean example of getopt, makes full use of coreutils (and in an idiomatic way). It handles various OS and shell compatibility issues (and shows it has experience with where these arise). It does logging in a straightforward yet full-featured way.
As usual almost every comment here on HN is superficially critical.
The test file seems fun, but overall it's not that bad. Bash is a fairly simple to parse syntax-wise, so as long as you know your coreutils and you know what you're looking for, making simple changes is fairly easy.
It doesn't look so simple, but definitely looks quirky.
Take a look at how the tests are invoked :
for t in $(grep ^le_test_ $FILE_NAME | cut -d '(' -f 1)
do
if [ -z "$CASE" ] ; then
__green "Progress: "
[ "$_ret" = "0" ] && __green "$_ret" || __red "$_ret"
__green "/$num/$total"
printf "\n"
num=$(_math $num + 1)
fi
...
It basically parses the very same file and checks for functions with the name `le_test`. This means that a random comment containing `le_test_` will break the whole script. You need lots of discipline in order to make things work.
Bash works perfectly with "Write programs that do one thing and do it well". Wouldn't be so surprised if this was a bunch of small test cases separated by file.
Looks a bit nightmarish to maintain.
1 : https://github.com/Neilpang/acmetest/blob/master/letest.sh