I've corrected the issue with the way @var@ is evaluated because with the above mentioned issue behavior was inconsistent when the command was preparsed. just like the out of order command issue when mixing raw commands with /commands that I previously fixed.
In this example @A@ was echoed to the console window as if it were executed but in reality it was just echoed and not actually performed, since this is very misleading I considered this behavior wrong.
Code:
/set @A@ /select -f *.txt
@A@
In this example the is performed as expected.
Code:
/set @A@ SITE HELP
@A@
The reason for the two different commands is that /crc32 displays the result directly in the status window using a predefined format.
Code:
[07:33:02] [L] [CMD] /crc32 flashfxp.log
[07:33:02] CRC32: a9ce9e68 File: F:\flashfxp.log (0.1 KB/s)
with $crc32(<filename>) it would return only the crc32 hash and this could be used to do things like create a sfv file.
Code:
# This will create a SFV file of all selected files
# using the standard SFV hash file format
# <filename> <crc32>
/writeln "%pverify.sfv" %f $crc32("%p%f")
I think your idea of allowing the user to set/get variables is a great idea and I wish I had thought of it
I will link to an updated build shortly with my latest changes.