The `-r` flag isn't best here. Per the less(1) man page, it's best to
use `-R` to only display the ANSII color escape sequences.
It seems like more(1) doesn't support color escape sequences, or at
least not properly. The display is messed up when using more(1), so
I've just accounted for that. In this situation, just use the `-C`
flag(s).
This is in regards to a request by Chubin on #134.
I didn't use grep(1), because it wound up being a lot slower than my
method. Relying on tools like that isn't always the best choice, which
is why I often just write in pure-shell, and have done for a couple of
years now. There's a time and a place for those external tools, but I
feel this was not it.
Tested and worked well. I've actually seen no noteworthy slowdowns, -
despite pre-processing the files -- YMMV.
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.
terminalforlife
Igor Chubin