I have my REBOL environment set up to my liking on our office network, where a script run on a desktop computer can "do" a common script on a network drive. This allows me to have the common scripts in a common place and not deployed on individual computers (with the possibility of older versions being used in certain situations). It works just fine on my Windows XP machine, but when I move the scripts to a Windows 7 machine it does not. I have installed REBOL/View on two computers (as administrator on Windows 7) and tried "do"-ing a common script from a command prompt (as administrator on Windows 7), to reduce the number of variables, and get the following result. I wonder if anyone has any ideas about where to look to fix this, if it can be fixed. Thank you. Windows XP computer: REBOL/View 2.7.8.3.1 1-Jan-2011 Copyright 2000-2011 REBOL Technologies. All rights reserved. REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM >> do %/L/COB_REBOL_modules/glb.r >> print glb-yyyymmdd 20120120 >> Windows 7 computer: REBOL/View 2.7.8.3.1 1-Jan-2011 Copyright 2000-2011 REBOL Technologies. All rights reserved. REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM >> do %/L/COB_REBOL_modules/glb.r ** Access Error: Cannot open /L/COB_REBOL_modules/glb.r ** Where: halt-view ** Near: do %/L/COB_REBOL_modules/glb.r >>
Vista and 7 shell are different (I'd say disable). I think you'd better install a new shell like http://classicshell.sourceforge.net/
I found, in a file properties box, a check-box for a "Windows XP compatibility" mode. I checked that for the REBOL intperpreter. Now I can "do " a script on the L: drive but not on another network drive (I. The L: drive is a common drive for everyone in the office. The I: drive is my own personal area on the network. This sounds to me like an issue of permissions, so I have tossed it over to the network administrator. If a solution comes out of that area, I will try to remember to report it.
For the sake of completeness, I will report what I have found. I had been setting REBOL up to run from a desktop shortcut, and so that I would not have to remember to change that shortcut with each new version of REBOL, I had been renaming the REBOL interpreter to a standard name (the various versions on the REBOL web site have different names, rebol-view-278-3-1 for example). It seems that the when I run a renamed version of the interpreter, I get the above problem, but if I download the interpreter and run it as I get it, without renaming it, it works. That sounds hard to believe, but I tried it a couple times. The next problem to move on to is that the REBOL "call" command, on Windows XP, can call a powershell script, but on Windows 7, I get a message that running scripts is not allowed. But it IS allowed because I can open a powershell command prompt and run them. I set the execution policy to unrestricted but still no luck. This last problem might beat me, but I might give up on REBOL anyway after the rumor that Carl is giving up working on REBOL except on weekends. There is a possibility that Python will work its way into the office as a configuration tool for one our software packages, and that would make it worthwhile to investigate Python as an office standard.
Others have tried this and suggest that this works for them: Code: do to-rebol-file "full windows path with mapped drive"
Again for completeness, here is a follow-up on the problem of using REBOL to call a powershell script. There is a hierarchy of execution policies. One can not just Set-Executionpolicy remotesigned and have things work. That sets only one of the four levels of execution policies. This is explained in get-help about_execution_policies. I don't follow it all at this time, but I got my particular application to work with Set-Executionpolicy bypass -scope currentuser