Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migration to "subprocess" for executing commands #33

Closed
paramsiddharth opened this issue Dec 2, 2020 · 1 comment · Fixed by #41
Closed

Migration to "subprocess" for executing commands #33

paramsiddharth opened this issue Dec 2, 2020 · 1 comment · Fixed by #41

Comments

@paramsiddharth
Copy link
Contributor

paramsiddharth commented Dec 2, 2020

The usage of os.system for calling the compilation and execution commands poses several issues we need to address, such as:

  • It executes the passed command in a subshell without any control over the process. It would require < input.txt to be suffixed to the command string to send the input data to the compiled executable.
  • As previously discussed in Not working on windows platform with cmd #21, it is error-prone in non-GNU systems, and also leads to errors with file/directory names with special characters and whitespace.
  • All we have access to is the return value once the process has finished executing. We can't examine or control the flow of data in stdin and stdout. It would also help if we want to automate the verification of right output to the given input.

The compilation command-executing strategy should therefore be migrated to subprocess, which is supported by the following points:

  • We control the flow of data into stdin and out of stdout i. e. We read the data from input.txt, pass it into the subprocess call, obtain the data sent to stdout and format and display it as desired. It enables us to choose i. e. Define custom stdin and stdout for the subprocess call.
  • Instead of executing the command in a subshell, a child process is created and executed, which is a safer and more efficient choice.
  • Unlike os.system, we have access to a lot more than just the return value. We receive an object for the subprocess, whereafter we can choose to wait for it to finish or continue. We can communicate with the subprocess during its lifetime.
  • We wouldn't need to worry about issues with quoting parameters that would contain special characters and/or whitespace, because a call made using subprocess would require the parameters to be provided in a list.
  • It would be convenient to handle the absence of gcc/g++ in PATH as well as improve the handling of Stop running output if compilation fails #25.

I would like to work on the issue, if approved.

@ankushbhardwxj
Copy link
Owner

@paramsiddharth - I like the idea of migrating to subprocess since its an improved version of system & also python docs advices us to use subprocess. Please go ahead & make a PR. 👍🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants