4 ms·

I still write and maintain a surprisingly large amount of sh code (it used to be bash, but when Ubuntu switched to defaulting to ash, I had to remove the bashis

I still write and maintain a surprisingly large amount of sh code (it used to be bash, but when Ubuntu switched to defaulting to ash, I had to remove the bashisms). Sometimes a shell script is still the shortest line from point A to point B, and it's always there. But, whenever I work on that code after a long time of not reading it, I'm always afraid I'm breaking something, introducing new bashisms, etc. and have to test it thoroughly across multiple systems to be sure I didn't break something. There is checkbashisms which catches most bashisms, but there's still a lot of weird stuff in shell scripts, and without block or function scope it can be challenging to stay on top of a large shell codebase. In short, I've been working on more automatic testing (i.e. tests without explicitly written unit tests) of my code lately, and the shell stuff is pretty hard to do that for, compared to Perl and JavaScript. So, this is probably awesome.

uaygsfdbzf 12y ago
What are you using for Perl and JavaScript?
- mitchty 12y ago
  Some help on spellcheck like stuff in perl would be perl-critic and perl-tidy. Beware using this on old code though. http://search.cpan.org/~thaljef/Perl-Critic-1.123/lib/Perl/Critic.pm http://search.cpan.org/~thaljef/Perl-Critic-1.123/lib/Perl/C... http://search.cpan.org/~shancock/Perl-Tidy-20140711/lib/Perl/Tidy.pod http://search.cpan.org/~shancock/Perl-Tidy-20140711/lib/Perl... I know nothing on javascript.
- pronoiac 12y ago
  For JavaScript, I like jshint: http://jshint.com http://jshint.com , as I heard jslint was too opinionated.
- SwellJoe 12y ago
  I'm still working on it, but Perl::Critic is good (I've been using it in vim for a while, which checks every time you save), strict and warnings is good (which would be enabled on any new Perl program, but I'm working with a 15 year old codebase, so enabling these automatically creates a bunch of new failing "tests" that need fixing). There's a few different ways to use Perl::Critic in tests, the most promising seems to be Test::Perl::Critic::Progressive, which allows gradual introduction of Critic-friendly code without turning your whole smoker page red. (Which for me, is a problem...we'd have hundreds of failing tests, which would be overwhelming and make it hard to spot tests that will affect users.) Devel::NYTProf is great for spotting performance regressions. And, since we're pushing out HTML as the result of our application scripts running, I've been working on integrating HTML::Lint (I had to patch it to allow HTML::Pluggable::HTML5 to work, but I've sent a pull request to Andy, so the next version will likely support HTML5) into our test suite. This will tell us if any script breaks in such a way that it produces invalid HTML. For JavaScript, jslint and jshint exist. I haven't started integrating or experimenting with either, yet. Our JavaScript is pretty minimal at the moment (a few thousand lines vs 500k+ lines of Perl), so it's not a priority compared to the Perl, and the Perl stuff is still in progress. JavaScript also has strict, which can catch some common problems, like the global scope "this".
- diff_sky 12y ago
  For javascript, eslint (http://eslint.org/ http://eslint.org/) is now what I use. It's more configurable than what has come before it and has good, clear documentation.
rcthompson 12y ago
My approach to bashisms is to put "#/bin/bash" on the first line unless I'm specifically trying to avoid them. It acts as a declaration of "yes I'm using bash, there are probably bashisms in this code".
- SwellJoe 12y ago
  That kinda defeats the purpose of my scripts, which are written in sh in order to run on any of our supported systems without any need to install any dependencies first. We can know that there will be a POSIX compatible sh on every system we support. If I'm willing to make uses install something first (i.e. if it is used after an installation script runs rather than during), I build it in Perl.

uaygsfdbzf 12y ago

What are you using for Perl and JavaScript?

mitchty 12y ago
Some help on spellcheck like stuff in perl would be perl-critic and perl-tidy. Beware using this on old code though. http://search.cpan.org/~thaljef/Perl-Critic-1.123/lib/Perl/Critic.pm http://search.cpan.org/~thaljef/Perl-Critic-1.123/lib/Perl/C... http://search.cpan.org/~shancock/Perl-Tidy-20140711/lib/Perl/Tidy.pod http://search.cpan.org/~shancock/Perl-Tidy-20140711/lib/Perl... I know nothing on javascript.
pronoiac 12y ago
For JavaScript, I like jshint: http://jshint.com http://jshint.com , as I heard jslint was too opinionated.
SwellJoe 12y ago
I'm still working on it, but Perl::Critic is good (I've been using it in vim for a while, which checks every time you save), strict and warnings is good (which would be enabled on any new Perl program, but I'm working with a 15 year old codebase, so enabling these automatically creates a bunch of new failing "tests" that need fixing). There's a few different ways to use Perl::Critic in tests, the most promising seems to be Test::Perl::Critic::Progressive, which allows gradual introduction of Critic-friendly code without turning your whole smoker page red. (Which for me, is a problem...we'd have hundreds of failing tests, which would be overwhelming and make it hard to spot tests that will affect users.) Devel::NYTProf is great for spotting performance regressions. And, since we're pushing out HTML as the result of our application scripts running, I've been working on integrating HTML::Lint (I had to patch it to allow HTML::Pluggable::HTML5 to work, but I've sent a pull request to Andy, so the next version will likely support HTML5) into our test suite. This will tell us if any script breaks in such a way that it produces invalid HTML. For JavaScript, jslint and jshint exist. I haven't started integrating or experimenting with either, yet. Our JavaScript is pretty minimal at the moment (a few thousand lines vs 500k+ lines of Perl), so it's not a priority compared to the Perl, and the Perl stuff is still in progress. JavaScript also has strict, which can catch some common problems, like the global scope "this".
diff_sky 12y ago
For javascript, eslint (http://eslint.org/ http://eslint.org/) is now what I use. It's more configurable than what has come before it and has good, clear documentation.

rcthompson 12y ago

My approach to bashisms is to put "#/bin/bash" on the first line unless I'm specifically trying to avoid them. It acts as a declaration of "yes I'm using bash, there are probably bashisms in this code".

SwellJoe 12y ago
That kinda defeats the purpose of my scripts, which are written in sh in order to run on any of our supported systems without any need to install any dependencies first. We can know that there will be a POSIX compatible sh on every system we support. If I'm willing to make uses install something first (i.e. if it is used after an installation script runs rather than during), I build it in Perl.