bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: find: invalid expression


From: James Youngman
Subject: Re: find: invalid expression
Date: Sun, 12 Dec 2004 23:02:12 +0000
User-agent: Mutt/1.3.28i

On Sun, Dec 12, 2004 at 10:15:27AM +0800, Dan Jacobson wrote:
> I'm just saying that instead of always just saying "find: invalid
> expression", it could say "problem occurred here==>))<===" etc. like
> perl -w or gawk.  

find doesn't keep enough state information to make this possible at
the moment (DEBUG is not always set, and that's not quite enough
anyway, I think).  I have made the "invalid expression" messages more
illuminating for those cases where I can figure out how to get find to
issue that message.  There are some remaining cases which I couldn't
tickle.

If you can get find to issue an incomprehensible error message, then
please submit this as a _specific_ bug report along with clear
instructions for reproducing the problem.

Meanwhile, I attach below the patch to tree.c which I'm about to check
in.

> As with fancy find expressions, it gets surprisingly hard to dig
> thru all the backquotes to find what went wrong on one's own.

If you have trouble with backquotes, give serious thought to using the
POSIX construct $(...), which nests without any need for quoting.

Regards,
James.

--- cut here ---
Index: tree.c
===================================================================
RCS file: /cvsroot/findutils/findutils/find/tree.c,v
retrieving revision 1.14
diff -u -r1.14 tree.c
--- tree.c      12 Dec 2004 13:02:54 -0000      1.14
+++ tree.c      12 Dec 2004 22:55:25 -0000
@@ -65,12 +65,19 @@

   if (*input == NULL)
     error (1, 0, _("invalid expression"));
+
   switch ((*input)->p_type)
     {
     case NO_TYPE:
+      error (1, 0, _("invalid expression"));
+      break;
+
     case BI_OP:
+      error (1, 0, _("invalid expression; you have used a binary operator with 
nothing before it."));
+      break;
+
     case CLOSE_PAREN:
-      error (1, 0, _("invalid expression"));
+      error (1, 0, _("invalid expression; you have too many ')'"));
       break;

     case PRIMARY_TYPE:
@@ -89,7 +96,7 @@
       next = get_expr (input, NO_PREC);
       if ((*input == NULL)
          || ((*input)->p_type != CLOSE_PAREN))
-       error (1, 0, _("invalid expression"));
+       error (1, 0, _("invalid expression; I was expecting to find a ')' 
somewhere but did not see one."));
       *input = (*input)->pred_next;    /* move over close */
       break;

@@ -145,6 +152,9 @@
        case PRIMARY_TYPE:
        case UNI_OP:
        case OPEN_PAREN:
+         /* I'm not sure how we get here, so it is not obvious what
+          * sort of mistakes might give rise to this condition.
+          */
          error (1, 0, _("invalid expression"));
          break;

@@ -156,14 +166,16 @@
          break;

        case CLOSE_PAREN:
-         return (tree);
+         return tree;

        default:
-         error (1, 0, _("oops -- invalid expression type!"));
+         error (1, 0,
+                _("oops -- invalid expression type (%d)!"),
+                (int)(*input)->p_type);
          break;
        }
     }
-  return (tree);
+  return tree;
 }


 /* Optimize the ordering of the predicates in the tree.  Rearrange





reply via email to

[Prev in Thread] Current Thread [Next in Thread]