- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Hello all,
Sorry this above post is locked I cannot add a question directly to it. But this *PowerShell script works for me perfectly from PowerShell prompt. *Y:\SAS\Sample_Code\kmj_test.ps1
%let machine = ir53; /* Machine name with admin privileges */
x 'C:\Windows\syswow64\Windowspowershell\v1.0\powershell.exe' -file "Y:\SAS\Sample_Code\kmj_test.ps1" &machine;
My only two questions are how are you determining the machine name if that is critical or just a file handle disregard? and is this solution still valid on SAS9.4 and win10? The process just opens the x window and sits there doing nothing, no prompt, no error, no log. (I also tried with fully qualified domain PC name same results.) I also checked the path of PowerShell program that is correct, and that I have admin rights on the PC. TIA for any pointers -KJ
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Ultimately I do not know if this posted original solution works or not for Win10 and newer versions of SAS (I could not get it to work for me). However I did find an acceptable method to start a PowerShell script with SAS not having to manually intervene with the script or SAS. I was going to give credit for the solution to Reeza for the idea, however Reeza declined and asked me to remove it. –KJ
The soultion I used:
/* example with hard coded path, no escape needed. */
data _null_;
CALL SYSTEM ('
powershell Set-ExecutionPolicy -Scope CurrentUser Bypass; D:\my_folder\My_PowerShell_Script.ps1
');
run;
/* or
[The trick is simple “call system” is treating this as one command, and you need to send two, first the call to “PowerShell & the security option(s) you desire” is treated as the first command, the actual script the second command but in this case SAS will attempt to interpret the semicolon (is the PowerShell command separator) and it will fail, thus the %str(;) ]
*/
data _null_;
CALL SYSTEM ("
powershell Set-ExecutionPolicy -Scope CurrentUser Bypass%str(;) &pname.My_PowerShell_Script.ps1
");
run;
Now every component is happy, System security should be happy on Windows, and PowerShell 'could' run without errors and exit cleanly back to SAS. Granted in this case the PowerShell script itself did not take any arguments but that is how I wrote the script. -KJ
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
What is the string you would pass to the command line to call this program? That's what you need. And then you can use CALL SYSTEM or %SYSEXEC() to run the program. I personally don't like the X statement because its hard to get the quotes correct.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
for after you read:
PowerShell is probably faster than the solution above but it's an option if you need it.
Oh, and verify that you have XCMD set up so that you can execute these commands, since you're seeing the cmd window pop up, I think you do though.
options xcmd;
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Reeza,
Thanks for the pointers. I went in a little different direction based on your suggestion.
This works fine. Where &pname. is your path...
Note the
%str(;)
powershell wants permission checked, so in this case it's actually two commands not one (first to set permissions, second the real comand I want to run), if you softcode your path you of course need to use double quotes and to prevent SAS from interpreting the semicolon you have to escape it... the escaped ';' is PowerShell's join commands option --similar to && for dos or | for unix type os.
data _null_;
CALL SYSTEM ("
powershell Set-ExecutionPolicy -Scope CurrentUser Bypass%str(;) &pname.your_script.ps1
");
run;*or;
data _null_;
CALL SYSTEM ('powershell Set-ExecutionPolicy -Scope CurrentUser Bypass; c:\my_path\my_script.ps1');
run;
TIA.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
If you can, you should change your answer to the correct solution, since that's the actual solution. My answers were really just comments or suggestions 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
You have a point, I just wanted a real way to call any PowerShell script and get it to work reliably, and even my solution does not address why I cannot get that other form to work. But your idea sparked the thought. -KJ PS ..and don't need anyone to look into this further. 😎 Done!
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Ultimately I do not know if this posted original solution works or not for Win10 and newer versions of SAS (I could not get it to work for me). However I did find an acceptable method to start a PowerShell script with SAS not having to manually intervene with the script or SAS. I was going to give credit for the solution to Reeza for the idea, however Reeza declined and asked me to remove it. –KJ
The soultion I used:
/* example with hard coded path, no escape needed. */
data _null_;
CALL SYSTEM ('
powershell Set-ExecutionPolicy -Scope CurrentUser Bypass; D:\my_folder\My_PowerShell_Script.ps1
');
run;
/* or
[The trick is simple “call system” is treating this as one command, and you need to send two, first the call to “PowerShell & the security option(s) you desire” is treated as the first command, the actual script the second command but in this case SAS will attempt to interpret the semicolon (is the PowerShell command separator) and it will fail, thus the %str(;) ]
*/
data _null_;
CALL SYSTEM ("
powershell Set-ExecutionPolicy -Scope CurrentUser Bypass%str(;) &pname.My_PowerShell_Script.ps1
");
run;
Now every component is happy, System security should be happy on Windows, and PowerShell 'could' run without errors and exit cleanly back to SAS. Granted in this case the PowerShell script itself did not take any arguments but that is how I wrote the script. -KJ