A bug in the TEST command? - Unix

This is a discussion on A bug in the TEST command? - Unix ; Hi All, I have this line of codes and found some pretty strange results (or I am just dumb): if [ 20051101000000 -gt 20051031220000 ] then echo T fi NOTE: I think it is obvious that the first operand is ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: A bug in the TEST command?

  1. A bug in the TEST command?

    Hi All,
    I have this line of codes and found some pretty strange results (or I
    am just dumb):

    if [ 20051101000000 -gt 20051031220000 ]
    then
    echo T
    fi

    NOTE: I think it is obvious that the first operand is greater than the
    second. However, when I run it on sh or ksh, no "T" is printed.

    I did a few more tests and found:

    if [ 21051101000000 -gt 21051031220000 ]
    then
    echo T
    fi

    NOTE: This time "T" is printed.

    REMARK: This time with an additional zero at the back of the figures.
    if [ 200511010000000 -gt 200510312200000 ]
    then
    echo T
    fi

    NOTE: "T" is printed as well.

    Please advice. I am so confused now. Thanks.


  2. Re: A bug in the TEST command?

    On 2005-11-09, danielyeap@gmail.com wrote:
    > Hi All,
    > I have this line of codes and found some pretty strange results (or I
    > am just dumb):
    >
    > if [ 20051101000000 -gt 20051031220000 ]
    > then
    > echo T
    > fi
    >
    > NOTE: I think it is obvious that the first operand is greater than the
    > second. However, when I run it on sh or ksh, no "T" is printed.


    It all depends on the size of integer in the shell you are using.
    Recent versions of bash and ksh use 64-bit integers; older ones
    use 32-bit, and your numbers overflow.

    --
    Chris F.A. Johnson | Author:
    | Shell Scripting Recipes:
    Any code in this post is released | A Problem-Solution Approach,
    under the GNU General Public Licence | 2005, Apress

  3. Re: A bug in the TEST command?

    Hi Chris,
    Thanks for your reply.

    I do not know if I got this right, but one of my examples showed that
    the comparison is ok if I add a zero behind the originally 14-digits
    number.

    If the problem is caused by the overflow, wouldn't that the new
    15-digits number will face the same fate as well?

    Appreciate if you can explain further. Thanks.


  4. Re: A bug in the TEST command?

    On 2005-11-09, danielyeap@gmail.com wrote:
    > Hi Chris,
    > Thanks for your reply.
    >
    > I do not know if I got this right, but one of my examples showed that
    > the comparison is ok if I add a zero behind the originally 14-digits
    > number.


    Please read: .

    > If the problem is caused by the overflow, wouldn't that the new
    > 15-digits number will face the same fate as well?
    >
    > Appreciate if you can explain further. Thanks.


    Try doing some shell arithmetic with large numbers and see what
    happens, e.g.:

    echo $(( 20051101000000 + 0 ))


    --
    Chris F.A. Johnson | Author:
    | Shell Scripting Recipes:
    Any code in this post is released | A Problem-Solution Approach,
    under the GNU General Public Licence | 2005, Apress

  5. Re: A bug in the TEST command?

    On 2005-11-09, danielyeap@gmail.com wrote:
    > Hi Chris,
    > Thanks for your reply.
    >
    > I do not know if I got this right, but one of my examples showed that
    > the comparison is ok if I add a zero behind the originally 14-digits
    > number.
    >
    > If the problem is caused by the overflow, wouldn't that the new
    > 15-digits number will face the same fate as well?


    The number with the zero behind it may be getting interpreted as octal,
    maybe?

    > Appreciate if you can explain further. Thanks.
    >


+ Reply to Thread