[Top][All Lists]
[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