Date: Thu, 27 Jul 2006 15:34:57 -0400 From: John Baldwin <jhb@freebsd.org> To: Yar Tikhiy <yar@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/bin/test test.1 Message-ID: <200607271534.58605.jhb@freebsd.org> In-Reply-To: <200607271908.k6RJ8Los011463@repoman.freebsd.org> References: <200607271908.k6RJ8Los011463@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 27 July 2006 15:08, Yar Tikhiy wrote: > yar 2006-07-27 19:08:21 UTC > > FreeBSD src repository > > Modified files: > bin/test test.1 > Log: > Document that both sides of -a or -o are always evaluated. This > "feature" doesn't seem to be in the standards or elsewhere, and > it is against what we are used to in C and sh(1), so put the > paragraph under BUGS. > > Pointed out by: dougb > MFC after: 3 days This isn't a bug, it's the only way it can work. What you are missing is that the shell has to evaluate the arguments and then pass them to test(1). Thus, when you do: if [ foo ] && [ bar ]; then ... fi The shell runs evaluates all of '[ foo ]' as needed and runs it. It then decides whether to evaluate and run '[ bar ]' after the first command runs. When you do: if [ foo -a bar ]; then ... fi The shell has to evaluate all of '[ foo -a bar ]' and run the single command and make the decision based on what it returns. I don't think this is really a bug, it's more the fact of realizing that even if [ maybe optimized to be a built-in, when you are using it, you have to treat it as the shell executing a separate program, just as you would expect: if grep -q ${FOO} < ${BAR}; then ... fi To evaluate both ${FOO} and ${BAR} before running grep. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607271534.58605.jhb>