Currently, undefined alias references are replaced with the current lister path. This can cause problems or seemingly wacky behavior.
I recommend an option to throw an error, stop execution.
Currently, undefined alias references are replaced with the current lister path. This can cause problems or seemingly wacky behavior.
I recommend an option to throw an error, stop execution.
If an alias doesn't exist it should stay as-is without changing into anything.
Which context are you seeing this happen in?
This. User Script called from a button on the File menu.
cd /home
"/home\DopusRT.exe" /cmd Prefs BACKUP=all TO "/doBak\DopusBak_{date|yyyyMMdd}-{time|HHmmss}_RT" QUIET
That isn't replacing the unknown alias with the current path. (That would result in the backup being created directly inside the current folder.)
It's treating the doBak
as a normal, standalone folder name, i.e. a path relative to the current folder. You'll get a doBak
folder below the current folder, and the backup file inside of that.
Right, /doBak is ....\doBak which explains why I had \doBak folders all around my system. (looking forward to incorporating Everything into Dopus!)
What happened is, I copied the button to another system, without the alias.
This is a great place to put a stopper on mistakes / bugs / etc... If a non-existent alias is referenced, hold everything!
The problem is that "/doBak" might be an alias but it might also be a path or a command line argument for something. Blocking because anything after a "/" wasn't an alias name could cause more problems than it solves.
Maybe it would make sense for the more explicit {alias|...} code but you'd have to remember to use that, and it's almost never used outside of MS-DOS Batch buttons (where it's required for using aliases).
At the moment, you could add the checks via scripting, but it'd make everything a lot less concise.