I think it would be perfectly acceptable for /set @A@ to treat "/select -f *.txt" as a literal string and not re-evaluate it to allow your usage example at all. Commands by nature are expected to be at the beginning of the line for the most part (in this type of set up), and certainly that is ALWAYS the expectation for custom command scripting in flashfxp.
What I would generally expect is for "/set @A@ $something()" to evaluate $something() and store the resulting string literal as the value of @A@, meaning that NOT evaluating /select in that same manner would be inconsistent unless by design (that is, /cmd's must always be at the start of a line therefor a / will be treated as a string literal thereafter).
I can not really think of situations where you example would be used? All that comes to mind is the hash calculation commands, but then I am wondering how /crc32 "<filename>" is different to /echo $crc32("<filename>") or just $crc32("<filename>") on its own? and by extension is there actually a need for /crc32 etc. The only other design method I can think of at the moment would possibly be to not support your example of putting a /cmd in a @var@ and running it with just @var@... but rather set the result of said /cmd as the string literal value of @var@. In the latter I can at least come up with usage situations, though I doubt they would actually be utilized. That also keeps things at a decent level of consistency.
Again the suggestion of variables was an afterthought. Though they would be useful - it is clear they push against the boundaries of what one would expect from a basic command design interface and are a more complex thing to implement in the type of parser you have designed. Mostly continued this discussion because I happen to enjoy software 'engine' design and have written various low level 'engines' and parsers myself in the past.
Last edited by DayCuts; 12-26-2014 at 04:17 PM.
|
Threaded Mode