OSError occurs in Linux

Hello.
OSError occurs in Linux.

In Linux, OSError occurs.
What bug occurs in Linux in the code below?
Please Help me.

import subprocess
import os
import sys

exePath = “C:\subpro.exe” #<==This(subpro.exe) is an EXE developed in C#.
argument = “Apple”

process = subprocess.Popen([exePath, argument], stdin = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.PIPE);
stdout, stderr = process.communicate();
if process.returncode == 0:
print(“succeed, returned” + stdout.decode(“CP949”))
else:
print(“returned” + stdout.decode(“CP949”))
print(“failed, error” + str(process.returncode) + stderr.decode(“CP949”))
process.stdin.close();
if process.stderr is not None:
process.stderr.close()
process.wait()

exePath is a Windows file path
The backslash in the string requires escaping or a raw string (r“C:\subpro.exe”), and from the way the forum software has rendered your quotation marks, ensure they are as in r"" or r'' as Python string syntax requires
.
Even with executable permissions set, is it even possible to run a typical .exe file from a Linux command line? ‘.exe’ suggests it was compiled for Windows.

There’s no need to use Popen directly in this case, and even if there was I’m not sure assigning subprocess.PIPE to all three stdin/out/err works.

Just to run an executable, the last 11 lines can be replaced with a call to subprocess.run

Are you Korean? And if not, did you get ChatGPT to generate this code? I recommend starting from scratch and figuring out what you actually want to do, whether it’s running a C# program in Mono or running it through Wine or something else… and it almost certainly won’t be in C:\subpro.exe.

1 Like

On a Windows system, this means the file named subpro.exe which is located directly at the root of the C drive (absolute path)

On a Linux system, this means the file named C:\subpro.exe located in the current folder (relative path). Linux does not use \ symbols to separate paths, and it does not have drive letters (the entire filesystem has a common root, even if you use multiple physical hard drives, SSDs etc.).

It’s completely wrong. Things are named completely differently on Linux. Linux does not care about extensions like .exe, so programs will usually not have them. (Only the programs care, if they include their own logic to care about it.) Besides that, you would never store a program at the root of the filesystem like that. I’m not sure if it’s allowed, even with root (admin) access.

You will need to have the program on your Linux system (which means compiling it for Linux), and know the actual path to it. Even after that it will not make very much sense. CP949 is a windows-specific text encoding.

Even on Windows it is at least a bad idea to try to write the file path this way. In many cases it will break. You should use forward slashes instead. Reference:

It is not required in this case (although I think there are plans to deprecate the existing handling of such backslashes), since \s is not a recognized escape sequence and thus the \ is parsed literally:

>>> 'C:\subpro.exe'
'C:\\subpro.exe'

However, it’s certainly good style - but better yet for file paths is to use forward slash as a path separator, even on Windows.

The quotes look like that because OP did not format the code properly for the forum. In plain text, the forum software converts ' and " to “smart” quotes automatically (which may look different yet again when put back inside code formatting, depending on the font).

1 Like

Could you please explain it simply?
I really want to understand what you are saying.
Please Help me.

Q1) subpro.exe is an EXE developed in C#. <==Can’t subpro.exe developed C# for Windows run on Linux?

Do I get an error when I use stdout.decode(“CP949 ”), stderr.decode(“CP949 ”) in Linux ?

Question1) I want to migrate the code below to subprocess.run.

Question2) Can you migrate the above code to subprocess.run?

Question3) Can you do subprocess.Popen on Linux?

process = subprocess.Popen([exePath, argument], stdin = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.PIPE);
stdout, stderr = process.communicate();
if process.returncode == 0:
print(“succeed, returned” + stdout.decode(“CP949”))
else:
print(“returned” + stdout.decode(“CP949”))
print(“failed, error” + str(process.returncode) + stderr.decode(“CP949”))
process.stdin.close();
if process.stderr is not None:
process.stderr.close()
process.wait()

You can run an EXE program developed in C# (and other .NET
languages) on Linux. But you need to have “mono” installed on Linux.

When you have it installed, then you can run either:

mono /path/to/your/subpro.exe

or simply: /path/to/your/subpro.exe

The problem you seem to have is that you are giving the wrong path
(location, ie. directory and filename) of the EXE file within Linux.

On Linux, this is not going to work:

C:\subpro.exe

There is no C:\ in Linux.

So, where is your subpro.exe? Is is /home/anna/subpro.exe or is it
/media/windows/subpro.exe or is it somewhere else?

You need to tell subprocess.Popen() the correct path to that EXE or
it can’t find it.

As a first step, find out where on Linux that EXE is (ind which
directory?).

Once you know that, try to run it with the following command:

mono /path/to/your/subpro.exe

If you get an error, saying that the program ‘mono’ could not be
found, then you need to first install mono.

Once this step works, try to call it from python with the correct path:

python -c ‘import subprocess;subprocess.run(“/path/to/your/subpro.exe”)’

In general, it doesn’t matter what programming language was used. Windows and Linux have different formats for executable programs.

For C# programs, you can use mono to run the program, like @MirkoK describes.

But even then, you have to know where the program was actually put, and how to explain that location to your Python script.

No, but it is unlikely that a program that was made on Linux by Linux developers would choose this encoding. If the output is supposed to be Korean, then euc-kr is more likely. Many programs use utf-8, which is a general standard.

Anyway, the approach in this Python code for reading the output is more complicated than it needs to be. Instead of reading bytes and using a separate decode step, we can give an encoding parameter to the subprocess.Popen call. And we do not need to use subprocess.Popen directly; subprocess provides a run wrapper that can make this much simpler.

Here is the documentation:

Here is a reference for using subprocess:

hello

In Windows Python3.9 ====
There was no problem in Python3.12 Windows. but there is error Python3.9 Windows.

import os
import sys

savepath = “C:\User\” <== The C drive Users folder is not recognized.

SyntaxError: (unicode error) ‘unicodeescape’ codec can’t decode bytes in position 2-3: truncated \UXXXXXXXX escape

Please Help me

Please read:

==== In python3.9 =====
import os
import sys

savepath = “C:\User\” <== The C drive Users folder is not recognized. in Windows

SyntaxError: (unicode error) ‘unicodeescape’ codec can’t decode bytes in position 2-3: truncated \UXXXXXXXX escape

Please Help me

In Windows Python3.9 ====
There was no problem in Python3.12 Windows. but there is error Python3.9 Windows.

savepath = “C:\User\” <== The C drive Users folder is not recognized.

SyntaxError: (unicode error) ‘unicodeescape’ codec can’t decode bytes in position 2-3: truncated \UXXXXXXXX escape

Partially agree

… ‘.exe’ suggests it was compiled for Windows.

if you’d ever compile CPython source code into binary on MacOS, you would get an file python.exe

.exe is just a label of excutable binary file

MacOS is not used Here.
Here, This(subpro.exe) is an EXE developed in C# Windows.
I am trying to run subpro.exe(EXE developed in C# Windows) on Linux.

That’s impossible.

Are you primarily trying to learn python, or to run a windows program on linux?

If the former, this has nothing to do with python. Fundamentally, you can’t expect to run an executable built for one OS on another. It makes no difference that you’re trying to do it in python.

If the latter, try wine. Install wine then run wine subpro.exe and see if it works (not guaranteed).