You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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. 👍🏻
The usage of
os.system
for calling the compilation and execution commands poses several issues we need to address, such as:< input.txt
to be suffixed to the command string to send the input data to the compiled executable.stdin
andstdout
. 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:stdin
and out ofstdout
i. e. We read the data frominput.txt
, pass it into the subprocess call, obtain the data sent tostdout
and format and display it as desired. It enables us to choose i. e. Define customstdin
andstdout
for the subprocess call.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.subprocess
would require the parameters to be provided in a list.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.
The text was updated successfully, but these errors were encountered: