Hi wisecracker,
In my defense, you originally stated:
I see that you said that you used bash (twice), but I don't see any requirement that alternative proposals should use bash nor that they should only use shell built-ins. The INTEGER specification was in the title, but not in the text of the message. I missed that point, so I admit that I did cheat.

Moving on to your later question:
I provided a similar degree of INPUT error correction with added checking to avoid rounding errors that could arise from processing floating point input values such as:

Code:

perfect_square 1.44
1.44 is the perfect square of 1.19999999999999996...

With your bash script using 64-bit signed integer arithmetic, I would expect that the largest square your script could process would be:

Code:

perfect_square 9223372030926249001
9223372030926249001 is the perfect square of 3037000499...

(i.e., the largest perfect square <= 9223372036854775807 [2**63 - 1]). With ksh93 and awk there could be some issues due to floating point artifacts with operands greater than 15 digits when performing floating point operations (only square root calculation in this script uses floating point arithmetic), but since the check at the end was using integer arithmetic, I thought the test should still be valid. But, going back and checking what was going on, I seem to have found a bug in the ksh test -eq operator on OS X (version sh (AT&T Research) 93u+ 2012-08-01). When testing integer numeric values that fit in a long int (64-bit signed int on OS X), the command:

Code:

[ $square -eq $number ]

should be performing an integer test for comparison. But, I found that the commands:

Code:

[ 9223372030926249001 -eq 9223372030926249000 ]
               and
[ 9223372030926249001 -eq 9223372030926249002 ]

both evaluate to true (which means it must be testing those values with a floating point comparison that has lost low end details due to the number of significant digits).

And I realized that the way I was testing could give false negatives when using int(xxx.9999xxx) would truncate to an integer when I needed to round to an integer. (I see other people have also commented on this while I was debugging my code last night and this morning.)

So, coding around my bug and the ksh bug, the following modified script should give you correct results for any value for which your original version would give correct results (and the runtime is not noticeably different from my earlier version):

Code:

#!/bin/ksh
# perfect_square <number>
number=$1
if [ "$number" -eq "$((int(number)))" ] > /dev/null 2>&1 
then
	if [ "$number" -lt 0 ]
	then
		echo "Warning! Integer is negative!!!"
		echo "Set input integer to the DEMO value of 99..."
		number=99
	fi
else
	echo "Invalid Argument! Set input integer to the DEMO value of 100..."
	number=100
fi
root=$((int(sqrt(number) + .5))) # Fix my bug...
square=$((root * root))
if [ $square = $number ] # "=" not "-eq" to avoid ksh bug
then
	echo "$number is the perfect square of $root..."
	exit 0
else
	echo "Integer $number is not a perfect square..."
	exit 1
fi

With the .5 added to the int() argument, that takes care of my bug. Note that square=$((root * root)) may yield a floating point value if and only if the result overflows a signed long int. And, if that happen, there will be a decimal point in the result. This will cause the script to report that the result is not a square even if it happens to be a square (such as with 100000000000000000000), but that cannot happen for any 63 bit integer value that it a perfect square that could be processed by your bash script. I should add a test at the start to check for input larger than LONG_MAX, but I'm not going to try to do that (when I can't trust the test -gt operator) until I get some sleep.

Please read all of the above carefully. It has been a while since I put in an all-nighter to track down a coding bug... It is now 7:20am and I'm going to bed.