5 ms·

Many years ago I learned myself Bash by writing this: https://github.com/louwrentius/PPSS https://github.com/louwrentius/PPSS It's a huge bash script for paral

Many years ago I learned myself Bash by writing this: https://github.com/louwrentius/PPSS https://github.com/louwrentius/PPSS It's a huge bash script for parallel processing of work. It was great fun and I'm proud of it as I don't see myself as a programmer of any sort. But gosh since I learned Powershell and Python, I would never ever ever ever ever use Bash for anything substantial. If you ever feel like you grow 'fond' of Bash or Shell scripting, it's time to seek a doctor. Please learn Python or some equivalent instead. ----------------- Edit: reading the code of this web server project: Let's be absolutely clear: this is a joke project. DO NOT USE THIS FOR # ANYTHING, ESPECIALLY ON A PUBLIC FACING SERVER.

DyslexicAtheist 8y ago
nice one. this is my favorite way of learning languages. find it really hard going step by step through a book from scratch and my fingers get really itchy and want to skip ahead into solving real problems. my result is usually a lot worse than what you built there. seems a lot of effort and iterations went into this? I have seen quite a bit of legacy plumbing like this in production / automation until better (or at least standardized) tooling came along with the agile/devops movement. A lot of this plumbing survived surprisingly long (which is also scary). Often code like this matures over long periods into stable solutions that could even deal with errors well. Makes them hard to replace. I agree it doesn't belong in production but it looks pretty neat for small internal stuff even in 2019.
- louwrentius 8y ago
  It was a lot of work but it was my first real attempt at programming and the topic itself was motivating enough to bring it to completion. Learning from books doesn't work, you need to have a project with a goal to apply it in. The horrible honest truth is that the world actually doesn't run on bash, python, C or Java. It runs on Excel macro's.
  - aloisamae 8y ago
    This. Some of my Structural engineering professors have invested so much time in Excel they practically have an instance of their mind in it. Really fancy systems too that could do just about anything they needed. Always impressed me. Your project is a great read!
rocqua 8y ago
Ive found it harder than expected to simply port over a bash script to python. Mostly because the syntax for 'run command c with arguments x y is much worse than bash. And that is before you want to handle output from the command.
- semi-extrinsic 8y ago
  It would be super nice if there was a package offering "native" shell experience in python. Say from pyshell import sh, ShellError def func(a,b) output, retcode = sh("df -k | awk '{print $5}'") if retcode == 0: return output else: raise ShellError(output,retcode)
  - mkesper 8y ago
    https://shell.readthedocs.io/en/latest/ https://shell.readthedocs.io/en/latest/ looks promising, will try next time before writing "just a small script" in bash (small scripts always grow and you pile on dirt on them when starting in bash).
    - flagada 8y ago
      This looks great, thanks! It looks very easy compared to subprocess.run and friends. I hope it'll help convincing my colleagues to default to python instead of bash (or, heavens forbid, csh)
  - amelius 8y ago
    Isn't this what os.system(...) does? By the way, why not put the raise inside sh? EDIT: Ok, the difference is that os.system does not return stdout. But you can use the subprocess package to capture stdout (and stderr as well). If you want pipe syntax, you can invoke e.g. bash -c "...", where the dots are your command. But the problem with this is that it's prone to injection attacks, unless you are very careful. I guess the same warning applies in your original "sh" example.
  - pushpop 8y ago
    I disagree. If I’m porting a shell script to another language then I would want to use as much native code as possible rather than shelling out. Sure, it takes a little more effort, but the output is more idiomatic code that runs faster (fork() is slow).

DyslexicAtheist 8y ago

nice one. this is my favorite way of learning languages. find it really hard going step by step through a book from scratch and my fingers get really itchy and want to skip ahead into solving real problems. my result is usually a lot worse than what you built there. seems a lot of effort and iterations went into this? I have seen quite a bit of legacy plumbing like this in production / automation until better (or at least standardized) tooling came along with the agile/devops movement. A lot of this plumbing survived surprisingly long (which is also scary). Often code like this matures over long periods into stable solutions that could even deal with errors well. Makes them hard to replace. I agree it doesn't belong in production but it looks pretty neat for small internal stuff even in 2019.

louwrentius 8y ago
It was a lot of work but it was my first real attempt at programming and the topic itself was motivating enough to bring it to completion. Learning from books doesn't work, you need to have a project with a goal to apply it in. The horrible honest truth is that the world actually doesn't run on bash, python, C or Java. It runs on Excel macro's.
- aloisamae 8y ago
  This. Some of my Structural engineering professors have invested so much time in Excel they practically have an instance of their mind in it. Really fancy systems too that could do just about anything they needed. Always impressed me. Your project is a great read!

rocqua 8y ago

Ive found it harder than expected to simply port over a bash script to python. Mostly because the syntax for 'run command c with arguments x y is much worse than bash. And that is before you want to handle output from the command.

semi-extrinsic 8y ago
It would be super nice if there was a package offering "native" shell experience in python. Say from pyshell import sh, ShellError def func(a,b) output, retcode = sh("df -k | awk '{print $5}'") if retcode == 0: return output else: raise ShellError(output,retcode)
- mkesper 8y ago
  https://shell.readthedocs.io/en/latest/ https://shell.readthedocs.io/en/latest/ looks promising, will try next time before writing "just a small script" in bash (small scripts always grow and you pile on dirt on them when starting in bash).
  - flagada 8y ago
    This looks great, thanks! It looks very easy compared to subprocess.run and friends. I hope it'll help convincing my colleagues to default to python instead of bash (or, heavens forbid, csh)
- amelius 8y ago
  Isn't this what os.system(...) does? By the way, why not put the raise inside sh? EDIT: Ok, the difference is that os.system does not return stdout. But you can use the subprocess package to capture stdout (and stderr as well). If you want pipe syntax, you can invoke e.g. bash -c "...", where the dots are your command. But the problem with this is that it's prone to injection attacks, unless you are very careful. I guess the same warning applies in your original "sh" example.
- pushpop 8y ago
  I disagree. If I’m porting a shell script to another language then I would want to use as much native code as possible rather than shelling out. Sure, it takes a little more effort, but the output is more idiomatic code that runs faster (fork() is slow).