Syntax error when redirecting eval

#1
Would someone please explain why I get a syntax error when I try to redirect the output from an alias for "echo %@eval[%$]"?
Code:
C:\>alias bc
echo %@eval[%$]
 
C:\>bc 2+2
4
 
C:\>bc 2+2 > clip:
TCC: Syntax error "2+2 > clip:"
 
C:\>alias foo=`echo %$`
 
C:\>foo bar+2
bar+2
 
C:\>foo bar+2 > clip:
 
C:\>ver
 
TCC  14.03.59  Windows Vista [Version 6.0.6002]
 
C:\>
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,588
46
Albuquerque, NM
prospero.unm.edu
#2
The > CLIP: is included in the alias arguments %$. Why? Because variable expansion (including aliases) is performed before redirection (so you can use a variable or expression as the filename or device name in a redirection.)

Your original alias will do what you expect if you call it like this:

Code:
( bc 2 + 2 ) > clip:
 
Feb 26, 2013
100
0
#3
Would someone please explain why I get a syntax error when I try to redirect the output from an alias for "echo %@eval[%$]"?
Code:
C:\>alias bc
echo %@eval[%$]
 
C:\>bc 2+2
4
 
C:\>bc 2+2 > clip:
TCC: Syntax error "2+2 > clip:"
The problem is the way you've defined the alias. Using %$ means all of the parameters to the alias are placed inside the @eval brackets. If you press Ctrl-F to expand the aliases on the command line you'll see what's happening, the command line you end up with is

echo %@eval[2+2 > clip:]

and not

echo %@eval[2+2] > clip:

which is what you were hoping for. In this case command grouping will help:

d:\>bc 2+2
4

d:\>(bc 2+2) > clip:

d:\>echo %@clip[0]
4


Dan
 
#6
Indded, AFAIK there is no alternative. Same as my nearly identical alias CALC for the same purpose (but I also use @COMMA to make the result more readable).

Note that for some commands, e.g., FOR and GLOBAL, you must also do the same if you want the whole output redirected into a single file, else each iteration is redirected either to its own separate file (if using a file in the CWD) , or it overwrites the single output file (assuming NoClobber=No), so only the last one's result remains... which is noted in their respective HELP pages.

Think of command groups as your friends, not as contortions...