refactoring: split helper functions into smaller scripts

[georglauterbach]

Description

This PR does not change any functionality of DMS, it just refactors the helper-function.sh script into smaller scripts in the earlier created helpers/ directory. helper-function.sh was a mess and all over the place. Now, a single script index.sh (which was already created before this PR) sources all helper functions, or one can individually source smaller helpers, somewhat sorted. Again, this is just a refactoring without functionality changes :)

One more thing: I changed . to source. As described in the commit message, source is idiomatic to Bash, and I find it easier to understand that a script is sourced here. I hope this is not a major problem for someone :)

Type of change

• Improvement (non-breaking change that does improve existing functionality)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (README.md or the documentation under docs/)
• If necessary I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[wernerfred]

TODO (I will add a proper description in a few minutes / hours) :D

Maybe put it as draft then 😄

[casperklein]

TODO (I will add a proper description in a few minutes / hours) :D

Just mark it as draft, until finished 😉 That way it's easier for the other maintainer to know, when to start reviewing.

Edit: @wernerfred was faster 😆

[georglauterbach]

I was just heading for lunch, the PR itself is finished and ready for review (I just didn't have enough time to write a proper description) 😆😆😆 That's why I did not mark it as a draft :)

[casperklein]

.

[polarathene]

I was under the impression that you usually want a blank line at the end of a file?

EDIT: There's a few examples here for why you might want to keep empty line at end of files.

Similar reason covered here noting many editors with feature to ensure the empty line on file save. And another citing roughly the same thing in a python community, but uses readline as an example.

I don't quite get the benefit of dropping them, but keen to know if there's a reason beyond preference 😅

FWIW, our own lint rules seem to prefer the empty line at end of file:

docker-mailserver/.editorconfig

Line 12 in 358df6a

insert_final_newline = true

---

In files I've worked on, I also have a habit of adding a double blank to better separate context/bounds visually, such as big functions which have their own single blank lines in the function body. That's just a personal preference thing so I don't mind that it was stripped, consistency is all good 👍

I tend to do similar for tests too, such as in the letsencrypt one I think I used it to group related functions and tests, although a recent PR may have also stripped that away.

[casperklein]

I think you mixed things up. There is a difference between a final new line, which as you stated is best-practice. But there is no good reason for an empty line.

Here is an example, that I hope helps to clarify things:

This writes hello with a final newline (0a in HEX) to the file world.

# echo hello > world
# hd world
00000000  68 65 6c 6c 6f 0a                                 |hello.|

This adds an additional empty line to the file world:

# echo >> world
# hd world
00000000  68 65 6c 6c 6f 0a 0a                              |hello..|

Notice the two 0a 0a at the end.

For completeness, here is a bad example:

This writes hello without a final newline (missing 0a at the end) to the file world.

# echo -n hello > world
# hd world
00000000  68 65 6c 6c 6f                                    |hello|

[casperklein]

Damn it. The web UI lied to me. I just verified the files and all is already fine (final new line, not empty lines).

[polarathene]

I think you mixed things up. There is a difference between a final new line, which as you stated is best-practice. But there is no good reason for an empty line.

Thanks for the clarification. It always seemed to render as an empty line to me in editors when I noticed it adding such on save. I guess that varies by editor presentation 😅

[georglauterbach]

Damn it. The web UI lied to me. I just verified the files and all is already fine (final new line, not empty lines).

Which of your suggestions should be commited now? I guess the one about errors.sh, but the other ones as well?

[casperklein]

Only the three unnecessary lines in error.sh. The rest is fine IMO. The webui pranked me into thinking, that there were empty lines. But there weren't.

I thought I deleted all wrong suggestions with the exception of one, but there were still two left. I deleted them now as well. So there is now only one wrong suggestion left, but only for the record, so that the following comments of polarathene and me makes sense.

[georglauterbach]

I realized that indeed there were two 0a's at the end of the files (not sure why the web-interface would maybe show something different). I removed them from the scripts - now all should be well:

$ for FILE in * ; do hd $FILE | tail -n 2 | head -n 1 ; done
00001640  20 66 69 0a 7d 0a                                 | fi.}.|
00000a30  69 61 73 65 73 5f 63 6f  6e 66 69 67 0a 7d 0a     |iases_config.}.|
00000bc0  0a 7d 0a                                          |.}.|
000009c0  6b 69 6c 6c 20 31 0a 7d  0a                       |kill 1.}.|
000003d0  63 72 69 70 74 73 0a                              |cripts.|
00000530  66 69 0a 7d 0a                                    |fi.}.|
00000380  0a 7d 0a                                          |.}.|
00000360  2a 2f 7d 22 0a 7d 0a                              |*/}".}.|
00000aa0  74 61 6c 69 61 73 2e 31  2e 68 74 6d 6c 0a        |talias.1.html.|
00001040  0a 20 20 66 69 0a 7d 0a                           |.  fi.}.|
000001a0  20 66 69 0a 7d 0a                                 | fi.}.|
000056b0  7d 0a                                             |}.|
000000e0  0a 7d 0a                                          |.}.|

[casperklein]

Interesting. When I checked out the branch to verify, all looked good. But maybe I did some mistake by doing that. I don't know. Then the web UI didn't lie to me in the first place 😆