Support and feedback request (from BPKG)

[francescobianco]

I want to use the first two words in this issue to thank all the contributors to the BPKG project, having discovered it gave me the start of all my BASH activity.

I apologize if I mention you all in this post, causing some spam. My intention is to make you aware of the LCOV(dot)SH project. Which wants to be the native tool to generate coverage of BASH projects. Unlike the alternatives, it does not require additional tools written in third-party language or compiled binarys; he does his job without external dependencies from a processing point of view.

I ask for your support in any way, but in particular, being able to have feedback and input to improve it would be the best.

• @jwerle
• @Potherca
• @humanshell
• @sschuberth
• @ccarpita
• @juanpabloaj
• @alexdantas
• @jclaveau
• @felixrabe
• @cha87de
• @nfischer
• @monkeywithacupcake
• @drefixs
• @brandonocasey
• @BenoitHiller
• @yorkie
• @thoward
• @stephenmathieson
• @reduxionist
• @razerbann
• @philippbosch
• @kba
• @gregorynicholas
• @coderaiser
• @benkogan
• @adjohnson916
• @AdrieanKhisbe

In the hope that this will become an important project like InstabulJS is in the JavaScript world

Thank you very much, even just for reading this message.

[Potherca]

First: I do not mind the ping in the slightest!

Second: Great work! And very brave to openly ask for feedback from the community! 🤩

Finally: Some thoughts after a first brief review.

Please don't be too afraid/annoyed at the sheer amount of feedback!

Some of it is just a lot of words in order to explain a simple thing, other things are just opinions or questions.

Don't feel pressured to use any of this! Or, if you want to but would like some help, don't hesitate to ask!

So... since you asked for it... Here is my feedback:

• Github actions
  Are all the linters enabled in the superlinter workflow really needed? BASH, JSON, and YAML I can understand but do you really need all the others?

• Versioning
  The package.json states "version": "0.0.1" I think that should be 0.1.0 in the very least. Also, don't forget to git tag (and git push --tags) any version!

• .editorconfig Looks good 🎉

• .gitignore
  The gitignore file contains entries for non-project code (.idea/ and .vscode/). Don't do that! You don't want all the ignores for every available IDEs, OS', etc. in you project ignore file. Put non-project ignores in your global ignore file.

• .travis.yml
  The travis CI currently only runs against trusty. You might consider creating a matrix to run against different shells and OS'. Especially as the docker file uses slim

• Dockerfile No comments. Looks awesome! 🐳

• LICENSE Text states Copyright (c) 2019 Javanile, should be Copyright (c) 2019-2020 Javanile as changes were made in 2020 as well.

• Makefile The editorconfig file states indent_style = tab for Makefiles but the Makefile uses spaces and tabs for indentation? Or is that the GitHub web UI messing with things?

• README

  • Is there a reason for using https://git.io/lcov.shinstead of the more explicit https://javanile.github.io/lcov.sh/lcov.sh? Saves the user an unneeded redirect.
  • Check if it working => Check if it works or Check if it is working (common mistake to make, don't worry)
  • Instead of on top of source file you want in a coverage report => on top of source files ... or on top of any source file...
  • Instead of see below example: just say for example:
  • Don't use #!/bin/bash (in either code or examples). For portability, use #!/usr/bin/env bash.
  • I'm not sure what is meant with the Short url section. Adding some explanation would be helpful.
  • You might want to make it clear that the todo is explaining how to run tests, as there are already some tests present.

• RELEASE 😂

• Tests

  • I am not sure how wise it is to use (and have created) pipetest.sh. It might be smarter to support on of the existing bash test/assert efforts rather than splintering the landscape further by creating yet another one.
  • lcov_done-test.sh and some other(s) says source lcov.sh lcov.sh. As this is not obvious to everyone what you are doing here (especially as both the filename and positional parameters are the same) you might want to add a comment explaining.
  • The test fixtures use #!/bin/bash you might want to change that to #!/usr/bin/env bash

• _config.yml Looks fine. Jekyll!

• codecov.yml Also good

• docker-compose.yml Five stars! Would read again!

• package.json Also good.

And then now... the main attraction:

lcov.sh

• License # Copyright (c) 2020 Francesco Bianco <[email protected]> should also be 2019-2020
• List of available options You might want to sort (the important) flags alphabetically for easier scanning (and to follow common conventions)
• export PS4='+:${BASH_SOURCE}:${LINENO}:${FUNCNAME[0]}: ' 🥇 I wish more people would do this!. Love it! 😍
• ** parameter while / case** These should definitely be sorted by alphabet
• return 0 I see several functions do this. Not sure it is needed but then, I am also not sure I mind them that much...
• commented out code There is still some commented-out debug code in some places. 🤷
• lcov_done Instead of multiple cuts you could just split the string to an array and uses indexes. Might not be worth the effort...
• Missing doc blocks Almost all of the functions have a doc block. Really well done! They add some much-needed context for us humans. Why not make the set complete and also fill them in for run_wait and run_step?
• run_test is a bit deeply nested (6 indents). It might be worth looking into reducing this by moving part of the code into separate functions, for the sake of readability. That said, if attempting this makes the code less readable, just leave it.

And that's all I've got!

The code was really well structured and very easy to read. You done good. Great work!

I hope my feedback was helpful, don't hesitate to reach out here on GitHub if you want any other help.

👋

[BenoitHiller]

Something I've been wondering about is if there is a fun solution to getting rid of the manual [[ -z "${LCOV_DEBUG}" ]] || set -x.

One interesting option is to make use of the BASH_ENV variable. The file it points to gets loaded up by all non interactive bash instances. So you can export it in your script to get something closer to real instrumentation.

Other fun stuff you may want to give a look:

• BASH_XTRACEFD would let you direct the trace output to a separate file so that you don't have to worry about it getting redirected if you are willing to only support versions of bash released this decade(I'm kidding. You can't drop osx support just yet). This would prevent issues where something was redirecting stderr to a log file like inside a subshell or nested script.
• BASH_REMATCH you can use a regex to split up your strings into capture groups. Compared to all the cut usage it may actually manage to be cleaner

As for the actual code I agree that the tests could use a bunch of polish. There should be at least one integration test that looks like what a normal user calling the program would do. That would help getting feedback a lot too because it would be easier to figure out the quirks of how it runs without spending as much time looking at it.

Also that run_test is way too dense. Even some more spacing and some "obvious" comments in it would help legibility.

[jwerle]

cc @vipyne 🙃

[l3laze]

Hi :) I wasn't tagged, but felt like it would be worth participating as someone who is trying to use this.

How are we supposed to test anything that takes commandline arguments, or scripts that are run by a test script? I'm working on a project that runs test.sh (not using BATS, etc, just it's filename) which contains 6 tests that each run ./script.sh with args -- it is considered only one test and only the final line is output (6/6 passed. Finished in 1+seconds). Trying to run script.sh itself through lcov.sh, it tries to eat the args meant for the script and fails.

On top of that I've got the "$LCOV_DEBUG" line in both test.sh and the script, and it's only producing coverage for test.sh.

I have tried -i|--including the script as a path, sourcing it into test and running it that way since it can still work, and have retried lcov.sh ./test.sh more times than I care to remember in less than 10 hours.

I see that your coverage is also not quite working, so I figure it's just not there yet, but thought it would be worth asking.

And this is still freaking awesome even if it only works on one file yet. Thank you very much for sharing :D