4 ms·
I may be wrong but I think that this is actually spawning a subprocess and thus is not an exact translation of the python example. This bash script rewritten i
by tyrion 13y ago
I may be wrong but I think that this is actually spawning a subprocess and thus is not an exact translation of the python example.
This bash script rewritten in python should be something like this:
import subprocess, sys
inp = open(sys.argv[1], 'r')
out = open(sys.argv[2], 'w')
sys.exit(subprocess.call('sort', stdin=inp, stdout=out, stderr=sys.stderr))
(I don't know why but it seems that the performance of this version are worse than the original proposed example with writelines/readlines)
- greyfade 13y agoIt doesn't have to spawn a subprocess. Some shells (like those in Busybox and Toybox) reduce common POSIX userland tools to a function call.
- robotresearcher 13y agoRight. And even it was implemented as a subprocess, it's still idiomatic shell code, i.e. what you would Actually Do.
- reirob 13y agoSo what? The Unix Shell library consists of all the executables that are on the system - for me this is the beauty. There is not much of abstraction between the Unix Shell and the system under it. And shell is very tolerant to other programing languages as well - as long as they allow to represent data in text form and through streams or files ;)
- tyrion 13y agoYes, I know that this is the correct way of doing it in bash. I posted this because someone might test the speed of the two scripts and conclude "bash is faster" while they actually measured the speed of "sort" probably.
- judk 13y agoMicrobenchmarks are a distraction. Macrobenchmarks matter. The real problem with bash is the mess you get when you start needing whitespace or arrays or error handling or non tabular objects or a computation not already implemented as a system program.