4 ms·

Why, for the love of Notch, do people keep porting everything that you're supposed to be doing in a real programming language to Bash? Yes, it's Turing complete

Why, for the love of Notch, do people keep porting everything that you're supposed to be doing in a real programming language to Bash? Yes, it's Turing complete, but the syntax is ugly and inconsistent, there is just about no support for data structures, and you have to fork a process to do practically anything!

sstephenson 15y ago
Bats isn't a port of anything, and sometimes Bash is the right tool for the job. I maintain two other projects written in Bash (rbenv and ruby-build). I looked, and couldn't find any suitable testing tools for Bash, so I created Bats. My criteria for deciding what to work on in the open-source world is: do I need something that doesn't yet exist, or something whose existing implementations are unsuitable? If yes, I try to fill the void as best I can, and package it up nicely so others can use it too.
- michielsikkes 15y ago
  I also like contributing to projects if the vision and implementation are not too far off from what I would build myself. Otherwise, I find it hard to contribute to a project that is just too far off but might be able to do the same.
- mlafeldt 15y ago
  Another test framework written in (pure) shell is Sharness: http://git.io/sharness http://git.io/sharness It was derived from the Git test harness. I'm already using it for a couple of my projects.
- abecedarius 15y ago
  FWIW here's a vaguely doctest-like tool I wrote: https://github.com/darius/tush https://github.com/darius/tush May be unsuitable for you, as you say -- it looks like it takes less typing/punctuation to write the example tests, though.
  - sstephenson 15y ago
    Wow, I really like the literate style. Great stuff.
    - abecedarius 15y ago
      Thanks!
lukesandberg 15y ago
I could see this being very useful for testing little scripts and even small c command line applications i have written. In the case of the small command line applications this is probably the ideal way to test them. Obviously if the application is even remotely complex you will want unit tests too which probably should be implemented in the language (so you can test your procedures directly) but there is a case for integration tests as well.
- sstephenson 15y ago
  If you structure your program in a certain way, there's no need to distinguish between procedures and commands. See git and rbenv, which expose a single meta-command to your $PATH but are comprised internally of many smaller commands that invoke each other and communicate over standard I/O. This is also known as the UNIX philosophy :)
  - lukesandberg 15y ago
    I doubt that all of git commit is implemented in main. So I'm sure that there is still plenty of use for unit tests.
    - mlafeldt 15y ago
      As a matter of fact, all automated tests of the Git project are powered by a shell-based TAP harness, which tests executable commands only. To be fair, there are some dedicated C tools driving unit tests via CLI, but most of the tests are based on the final plumbing and porcelain commands.

sstephenson 15y ago

Bats isn't a port of anything, and sometimes Bash is the right tool for the job. I maintain two other projects written in Bash (rbenv and ruby-build). I looked, and couldn't find any suitable testing tools for Bash, so I created Bats. My criteria for deciding what to work on in the open-source world is: do I need something that doesn't yet exist, or something whose existing implementations are unsuitable? If yes, I try to fill the void as best I can, and package it up nicely so others can use it too.

michielsikkes 15y ago
I also like contributing to projects if the vision and implementation are not too far off from what I would build myself. Otherwise, I find it hard to contribute to a project that is just too far off but might be able to do the same.
mlafeldt 15y ago
Another test framework written in (pure) shell is Sharness: http://git.io/sharness http://git.io/sharness It was derived from the Git test harness. I'm already using it for a couple of my projects.
abecedarius 15y ago
FWIW here's a vaguely doctest-like tool I wrote: https://github.com/darius/tush https://github.com/darius/tush May be unsuitable for you, as you say -- it looks like it takes less typing/punctuation to write the example tests, though.
- sstephenson 15y ago
  Wow, I really like the literate style. Great stuff.
  - abecedarius 15y ago
    Thanks!

lukesandberg 15y ago

I could see this being very useful for testing little scripts and even small c command line applications i have written. In the case of the small command line applications this is probably the ideal way to test them. Obviously if the application is even remotely complex you will want unit tests too which probably should be implemented in the language (so you can test your procedures directly) but there is a case for integration tests as well.

sstephenson 15y ago
If you structure your program in a certain way, there's no need to distinguish between procedures and commands. See git and rbenv, which expose a single meta-command to your $PATH but are comprised internally of many smaller commands that invoke each other and communicate over standard I/O. This is also known as the UNIX philosophy :)
- lukesandberg 15y ago
  I doubt that all of git commit is implemented in main. So I'm sure that there is still plenty of use for unit tests.
  - mlafeldt 15y ago
    As a matter of fact, all automated tests of the Git project are powered by a shell-based TAP harness, which tests executable commands only. To be fair, there are some dedicated C tools driving unit tests via CLI, but most of the tests are based on the final plumbing and porcelain commands.