Akshay Pandey · Oct 25, 2021

Running Python script from terminal vs studio

I have created on class method which execute below command

From terminal : _System account works fine where code=0

From Studio : _System account give syntax error where code=1

set code = $zf(-1,"python C:\keys\")

w !, code

Product version: IRIS 2020.1
$ZV: IRIS for Windows (x86-64) 2020.1 (Build 215U) Mon Mar 30 2020 20:14:33 EDT
3 0 20 240
Log in or sign up to continue

does it change using %cde instead of code  as variable ?

nope...code =0 means sucess

code =1 means syntax error

I am not sure how same method is behaving differently

studio is not a real terminal with an isolated session context.

Classmethod Test() {

set code $zf(-1,"python C:\keys\")

W ! , code


Classmethod Test2() {

set code $zf(-1,"echo hello>C:\keys\test.txt")

W ! , code


Studio Output Window

Do ##class(Test).Test()


Do ##class(Test).Test2()


Cache terminal

Do ##class(Test).Test()


Do ##class(Test).Test2()



this is what is happening

this looks like "python" is not recognized in the spawned process
You may try a full reference "C:\......python.exe...."   

Hello all,

I just wanted to emphasize this point by Robert, which I think is the most critical. Studio is not a real terminal. I understand it can be convenient to test small bits of code in the Studio window, but I would not expect everything to work.

Hi @Vic Sun , @Akshay Pandey :
Just to complete this discussion.

From Terminal I could run Py also from a JOB, and over CPIPE without problems.
From Studio Output all this FAILS.
Which makes clear that the process behind Studio is far away from being a normal
IRIS/Caché process and just good for editing and compiling.  FullStop.

I would even assume that running COS commands was not planned but rather an accident that happened 20 yerars ago.


Hi Akshay,

Robert is correct.

$ZF(-1,{os command}) is used to call commands from the underlying operating system.

The shell that you execute won't know where to find the python executable.

We can see this by trying to print the Windows PATH environment variable (below) as you would normally be able to do in a Windows CMD shell:

As we can see above the CMD shell can see the environment variable %PATH% but if we do the same echo %PATH% in terminal we see nothing.  


thanks for the clarification.   I had a similar experience with node.js before.
But was not so certain to know the reasoning.

I have tried with full path as well still not working 

d $zf(-1,"whoami > c:\temp\whoami.txt")

nt authority\system    ( i dont know which user is this


d $zf(-1,"whoami > c:\temp\whoami.txt")

give local user

Just an idea:
I assumed that you use a local installation of IRIS
Is this correct ? 
Or does it run on some instance separate from your local WIN.
whoami is equivalent to echo %USERDOMAIN%\%USERNAME%

write $zf(-1,"hostname > c:\temp\hostname.txt")

may clarify this.
If it's not the same machine you need a PY installation this server

this is local installation

I did tried with complete python.exe path as well. 

but when -ZF(-1) running from studio its not working

When you use 'Studio', you are recognised like an administrator (nt authority\system) and not a local user.

Don't use $ZF(-1) : $ZF(-1) is a deprecated function. All new code development should use $ZF(-100).

What about your python with the new recommendation?

I tried with $ZF(-100) as well still I get code=1 (Syntax error)

same method while running from cache terminal works fine

whereas running from studio gives error

I spent quite a while on the subject of python. Also the asynchronous $ZF(-2) + error log

write $zf(-2,"C:\Users\cemper\AppData\Local\Microsoft\WindowsApps\pythonw3.9.exe <c:\temp\ 1>c:\temp\5out.txt 2>c:\temp\5er.txt")

And the error from WINDOWS was always: the program can not be executed
A further reason to use
Embedded Python!

in.pyw is simply




Small suggest - use $zf(-100) rather than $zf(-1) as it is more secure and $zf(-1) is not supposed to be used anymore (it is kept in place for backward compatibility but it really is deprecated for use in new code)