XPost: alt.comp.os.windows-10, alt.comp.os.windows-11   
   From: jj4public@outlook.com   
      
   On Wed, 29 Mar 2023 20:14:10 +0100, Andy Burnelli wrote:   
   >  *How can we programmatically distinguish between a failed VPN*   
   >   *connection attempt versus a successful VPN connection?*   
   >   
   > This is a general purpose solution _everyone_ can use instantly.   
   > For free. To connect to any one of _thousands_ of free VPN servers.   
   > Around the world. Perfectly legally. Maintained by a university in Japan.   
   >   
   > All the necessary free vpn files are provided in the request below   
   > such that anyone can test it out fully to use thousands of vpn servers.   
   >   
   >  *The question is what's a reliable test of whether the connection worked*   
   >  *or failed, so that the script can either sit still on the current vpn*   
   >  *server (if successful) or move to the next vpn server (if it failed)?*   
   [snip]   
      
   A reliable test will depend on how competent a software developer is. That   
   is, whether the software provide output/result which is usable for   
   determining the result of the connection or a task.   
      
   All programs have an exit code which can be checked with `errorlevel`, or   
   `%errorlevel%` variable (if under Windows NT's CMD). It should be set   
   according the result of the task given to the program, where zero is   
   commonly a successful result, and a specific non zero for specific error   
   code which are usually vendor specific.   
      
   If the software developer is not competent enough to set the program exit   
   code, we can try to use the program's console output to find a specific   
   keyword such as "connected", "successfully", etc. which is unique enough to   
   indicate a successful result. We can use the FIND (or FINDSTR if Windows NT)   
   tool to search for the keyword, where the tool will provide the result of   
   the search in form of program exit code.   
      
   Some programs generate logging outputs onto the console's standard error   
   handle, instead of the standard output handle. So, you'll have to check   
   first, from which console's standard handle should the keyword be searched   
   for.   
      
   Some programs only generate logging outputs into a file using an optional   
   command line switch. In ths case, the switch must be used and the keyword   
   should be searched from that file.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)