| That's why I am trying to come up with a method that detects
| the problem and changes the CWD before it is detected
| through another prompt.
| It's not a TCC issue, it's a Windows issue. You're hanging inside a
| Windows API, so you're going to have to seek relief from Microsoft.
Assume Z: is a mapped network drive. Does %@ready[z:] hang if the drive is currently not available, e.g., its system is powered down?
| I haven't researched it (I will) but I'd guess some sort of
| notification of a
| network disconnection (or unmapping) should be available, perhaps by
I just looked an NETMONITOR, and according to the help text, it monitors whether or not the local machine is connected to a particular network, not whether or not another machine is connected. There is no monitor command to keep track of the accessibility of other machines. That's what I would need to solve the problem.
| Even if it were, what should TCC do? Should currently executing commands or
| batch files, being likely to depend on the CWD (even existing!) be cancelled.
| Should TCC automatically change to some CWD guaranteed to exist (which one?),
| give a warning, and re-issue the prompt?
None of the above. The CWD path had to be was accessible when it became the CWD, so only its continued accessibility would need to be monitored so as to make it possible for the user to TEST current accessibility with no delays and no error message. The test could be done in POST_EXEC, or in the prompt itself, e.g, using @exec or @execstr, and appropriate action taken if needed as the user finds it suitable.