To whomever wrote this originally: please check I didn't acidentally
order something in the wrong place. Awesome cheat sheet, by the way.
I did away with the table format as it just wasn't going to work
properly in keeping with the line length limit of 80.
Your BASH version is checked; if it's 3, you will have to ignore this
commit, unfortunately. To be fair, if you're on 3 (major), you have
more pressing matters. :P
The use of `[ -t 1 ]` won't check for interactivity, rather, whether
STDOUT is viable? If so, it might be best to check the `$-` variable
(I think that's it) for the `i` character, like the standard default
Debian `.bashrc` interactivity checks. Or, my preference, check the
`$PS1` is not empty, which works well in my own `.bashrc` file.
The `Main()` function was spread a bit too far, but is now more
appropriate; has no real impact, just clarify when reading.
Although the use of less(1) pager is enabled by default, it can be
disabled now with the `--no-pager|-P` flags.
We can now specify our own whitelisting file, overriding the default of
'lenchk-excludes' which must stay in the same directory as lenchk, at
least for now. The custom file can be wherever you want it, however.
I'd like to use the `readarray`/`mapfile` BASH built-in for populating
the array variable, but it didn't seem to want to work, so I just went
for another `while read` loop. It's working very nicely as-is, though.
I've changed the required whitelist format to one of simplicity: one
filename per line. Why the previous format? Because of files which may
have a newline character in them, but I realised in this environment
that's just not going to happen; force of habit, I guess.
I'd like to allow users to be able to whitelist entire directories, but
I don't see that being so high on the priority list, for now.
What do you think?
Hope this helps. I wish I'd known this is what you were after, but I
guess it didn't click! This is an area I love and excel at, so I
hoped to put that to use here.
* The colorization flag might help when there are a lot of results.
* By far, the indented line number and preview of the offending lines
is the most useful aspect of lenchk, making it much easier to track
down troublesome lines, especially for the inexperienced.
* I've accounted for `//` lines (C languages), although some like
Javascript, HTML, and CSS I've yet to get around to.
* There's a summary, which is probably pointless, but it might help to
keep track of our progress in getting through the files.
* It's ever-so-slightly more efficient and portable, but ultimately, -
I'd say making it use just /bin/sh would be better, but Bash is
pretty common-place these days, and has features which make lenchk
much cleaner.
Ideally, I'd have written this in Perl, due to the limited lifespan
of this tester, because a shell can only handle so much data before
it starts to chug. I figured, however, that not everyone will have
Perl.
If this commit isn't accepted, no worries, as I'm sure I can repurpose
it for use elsewhere.
Want it, but have issues? Let me know, and I'll get on that ASAP.
Note that I've removed max_length in this commit, to avoid confusion.
I realise it's a built-in, and that its operation can wildly differ,
depending on the shell used, which is why I've added that the sheet is
for the Bash built-in. I'm not sure how this project handles multiple
different tools by the same name; worth looking into, @chubin?
Without knowledge of this, people trying out an Ubuntu- or Debian-based
distribution will be frustrated when trying to use udisksctl(1). I ran
into this situation myself, so discovering this was a relief.
Igor Chubin
terminalforlife
Meisam