Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
#!/usr/bin/env bash
|
|
|
|
|
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
# Author E-Mail - terminalforlife@yahoo.com
|
|
|
|
# Author GitHub - https://github.com/terminalforlife
|
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
Progrm=${0##*/}
|
|
|
|
|
|
|
|
Usage(){
|
|
|
|
while read; do
|
|
|
|
printf '%s\n' "$REPLY"
|
|
|
|
done <<-EOF
|
|
|
|
Usage: $Progrm [OPTS] [DIR_1 [DIR_2 ...]]
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
|
|
|
|
-h, --help - Display this help information.
|
|
|
|
-C, --no-color - Do not use ANSI color escape sequences.
|
|
|
|
-D, --no-subdirs - Ignore the 'sheets/_*' subdirectories.
|
|
|
|
-I, --no-lenchk-line - Ignore the special 'lenchk=.*' line.
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
-N, --no-preview - Omit the preview of each triggered line.
|
|
|
|
-P, --no-pager - Do not use less(1) or more(1) for paging.
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
-S, --no-summary - Omit the summary before $Progrm exits.
|
Add whitelisting functionality
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?
4 years ago
|
|
|
-W, --no-whilelist - Do not use the whitelist file.
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
-l, --limit [INT] - Override the limit of 80 columns.
|
Add whitelisting functionality
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?
4 years ago
|
|
|
-w, --wl-file [FILE] - Use an alternative whitelist file.
|
|
|
|
|
|
|
|
Additional directories can be appended to the argument string in
|
|
|
|
order to process directories otherwise not handled by $Progrm. You
|
|
|
|
can use '--' to let $Progrm know when to stop looking for flags.
|
|
|
|
|
Add whitelisting functionality
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?
4 years ago
|
|
|
Files to whitelist must be placed line-by-line; one path per line.
|
|
|
|
|
Add whitelisting functionality
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?
4 years ago
|
|
|
cheat.sheets/sheets/_perl/1line
|
|
|
|
cheat.sheets/sheets/find
|
|
|
|
|
|
|
|
The file paths to provide must begin with 'cheat.sheets/' to indicate
|
|
|
|
the root of the repository, otherwise this feature will fail.
|
|
|
|
|
Add whitelisting functionality
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?
4 years ago
|
|
|
The location of the whitelisting file ('$Progrm-excludes') must
|
|
|
|
remain in the same directory in which $Progrm is stored, unless
|
|
|
|
otherwise specified.
|
|
|
|
|
|
|
|
Alternatively, a file can be whitelisted by ensuring the very first
|
|
|
|
line contains only 'lenchk=disable', akin to a vim(1) modeline.
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
EOF
|
|
|
|
}
|
|
|
|
|
|
|
|
Err(){
|
|
|
|
printf 'ERROR: %s\n' "$2" 1>&2
|
|
|
|
[ $1 -gt 0 ] && exit $1
|
|
|
|
}
|
|
|
|
|
Add whitelisting functionality
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?
4 years ago
|
|
|
WLFile='lenchk-excludes'
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
MaxCols=80
|
|
|
|
|
|
|
|
while [ "$1" ]; do
|
|
|
|
case $1 in
|
|
|
|
--)
|
|
|
|
break ;;
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
--help|-h|-\?)
|
|
|
|
Usage; exit 0 ;;
|
|
|
|
--limit|-l)
|
|
|
|
shift; MaxCols=$1
|
|
|
|
|
|
|
|
if ! [[ $MaxCols =~ ^[0-9]+$ ]]; then
|
|
|
|
Err 1 'Invalid column maximum provided.'
|
|
|
|
fi ;;
|
Tighten Main(), and use pager by default
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.
4 years ago
|
|
|
--no-pager|-P)
|
|
|
|
NoPager='True' ;;
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
--no-preview|-N)
|
|
|
|
NoPreview='True' ;;
|
|
|
|
--no-color|-C)
|
|
|
|
NoColor='True' ;;
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
--no-summary|-S)
|
|
|
|
NoSummary='True' ;;
|
|
|
|
--no-subdirs|-D)
|
|
|
|
NoSubDirs='True' ;;
|
Add whitelisting functionality
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?
4 years ago
|
|
|
--no-whitelist|-W)
|
|
|
|
NoWhiteList='True' ;;
|
|
|
|
-I|--no-lenchk-line)
|
|
|
|
NoLenChkLine='True' ;;
|
Add whitelisting functionality
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?
4 years ago
|
|
|
--wl-file|-w)
|
|
|
|
shift
|
|
|
|
|
|
|
|
if [ -z "$1" ]; then
|
|
|
|
Err 1 'No alternative whitelist file provided.'
|
|
|
|
else
|
|
|
|
WLFile=$1
|
|
|
|
fi ;;
|
|
|
|
-*)
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
Err 1 'Incorrect option(s) specified.' ;;
|
|
|
|
*)
|
|
|
|
break ;;
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
|
|
|
|
# Thank you, Chubin. Feature apparently added in version 3.0 alpha, so should
|
|
|
|
# be OK, but if anyone is having issues, just `cd` to the 'tests' directory.
|
|
|
|
[ ${BASH_VERSINFO[0]:-0} -eq 3 ] || cd "${BASH_SOURCE[0]%/*}" &> /dev/null
|
|
|
|
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
# Confirm we are in the right place.
|
|
|
|
git rev-parse --is-inside-work-tree 1> /dev/null 2>&1 ||
|
|
|
|
Err 0 'Not inside a Git repository.'
|
|
|
|
|
|
|
|
case $PWD in
|
|
|
|
*/cheat.sheets/tests)
|
|
|
|
;;
|
|
|
|
'')
|
|
|
|
Err 1 'Unable to determine the CWD.' ;;
|
|
|
|
*)
|
|
|
|
Err 1 "Not within the 'cheat.sheets/tests' directory." ;;
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
esac
|
|
|
|
|
Tighten Main(), and use pager by default
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.
4 years ago
|
|
|
Dirs=(../sheets/*)
|
|
|
|
[ "$NoSubDirs" == 'True' ] || Dirs+=(../sheets/*/*)
|
Add whitelisting functionality
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?
4 years ago
|
|
|
|
|
|
|
# Add user's own directories to check, if they exist.
|
|
|
|
for ArgDir in "$@"; {
|
|
|
|
if [ -d "$ArgDir" ]; then
|
|
|
|
Dirs+=($ArgDir/*)
|
|
|
|
else
|
|
|
|
Err 1 "Directory '$ArgDir' not found."
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
Tighten Main(), and use pager by default
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.
4 years ago
|
|
|
# If the whitelist file exists, use it, unless whitelisting is disabled.
|
|
|
|
# Keeping this test outside of the loop to avoid unnecessary processing.
|
|
|
|
if [ "$NoWhiteList" != 'True' ] && [ -f "$WLFile" ]; then
|
|
|
|
# Read the whitelist file, line-by-line, generating an array thereof.
|
|
|
|
Whitelisted=()
|
|
|
|
while read; do
|
|
|
|
Whitelisted+=("../${REPLY#cheat.sheets/}")
|
|
|
|
done < "$WLFile"
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Using tput(1) for portability.
|
|
|
|
if type -fP tput &> /dev/null; then
|
|
|
|
C_Ellipses=`tput dim; tput setaf 7`
|
|
|
|
C_LineNums=`tput bold; tput setaf 2`
|
|
|
|
C_FileNames=`tput bold; tput setaf 1`
|
|
|
|
C_Reset=`tput sgr0`
|
|
|
|
else
|
|
|
|
Err 1 'Unable to colorize output -- tput(1) not found.'
|
|
|
|
fi
|
|
|
|
|
Tighten Main(), and use pager by default
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.
4 years ago
|
|
|
Main(){
|
|
|
|
for File in "${Dirs[@]}"; {
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
[ -f "$File" ] || continue
|
|
|
|
|
|
|
|
# Per chubin's desire to have an "in-bound flag"; see #134.
|
|
|
|
if [ "$NoLenChkLine" != 'True' ]; then
|
|
|
|
SkipFile='False'
|
|
|
|
|
|
|
|
readarray -t Buffer < "$File"
|
|
|
|
for BufferLine in "${Buffer[@]}"; {
|
|
|
|
if [[ $BufferLine == '# cheat.sh: '* ]]; then
|
|
|
|
CheatLine=${BufferLine#'# cheat.sh: '}
|
|
|
|
IFS=',' read -a Fields <<< "$CheatLine"
|
|
|
|
for Field in "${Fields[@]}"; {
|
|
|
|
[ "$Field" == "$Progrm=disable" ] && SkipFile='True'
|
|
|
|
}
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
[ "$SkipFile" == 'True' ] && continue
|
|
|
|
fi
|
|
|
|
|
Add whitelisting functionality
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?
4 years ago
|
|
|
# If the current file matches one which is whitelisted, skip it.
|
|
|
|
for CurWL in "${Whitelisted[@]}"; {
|
|
|
|
[ "$File" == "$CurWL" ] && continue 2
|
|
|
|
}
|
|
|
|
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
LineNum=0
|
|
|
|
HaveBeenHit='False'
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
while read; do
|
|
|
|
let LineNum++
|
|
|
|
|
|
|
|
# Ignore non-comment lines for '#' and '//'.
|
|
|
|
case $REPLY in
|
|
|
|
'#'*|'//'*)
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
continue ;;
|
|
|
|
esac
|
|
|
|
|
|
|
|
if [ ${#REPLY} -gt 80 ]; then
|
|
|
|
# We only need to be informed of a hit just the once, per file.
|
|
|
|
if [ "$HaveBeenHit" == 'False' ]; then
|
|
|
|
# The leading newline character, if needed.
|
|
|
|
[ "$NoPreview" == 'True' ] || printf '\n'
|
|
|
|
|
|
|
|
# The filename containing problematic line lengths.
|
|
|
|
[ "$NoColor" == 'True' ] || printf "$C_FileNames"
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
printf '%s\n' "${File#../}"
|
|
|
|
[ "$NoColor" == 'True' ] || printf "$C_Reset"
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
|
|
|
|
HaveBeenHit='True'
|
|
|
|
let Hits++
|
|
|
|
fi
|
|
|
|
|
|
|
|
if ! [ "$NoPreview" == 'True' ]; then
|
|
|
|
# The line number of the problematic length.
|
|
|
|
[ "$NoColor" == 'True' ] || printf "$C_LineNums"
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
printf ' %7d ' $LineNum # <-- allows for 9,999,999 lines.
|
|
|
|
[ "$NoColor" == 'True' ] || printf "$C_Reset"
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
|
|
|
|
# Cannot make this 80 columns long, due to the indentation
|
|
|
|
# and padding, but if you need to test this, for the sake
|
|
|
|
# of checking lenchk is doing its job, set the 70 to 80, -
|
|
|
|
# then make sure the terminal window is wide enough.
|
|
|
|
printf '%s' "${REPLY:0:70}"
|
|
|
|
|
|
|
|
# Cut-off ellipses.
|
|
|
|
[ "$NoColor" == 'True' ] || printf "$C_Ellipses"
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
printf '...\n'
|
|
|
|
[ "$NoColor" == 'True' ] || printf "$C_Reset"
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
fi
|
|
|
|
fi
|
|
|
|
done < "$File"
|
|
|
|
}
|
|
|
|
|
|
|
|
if [ ${Hits:-0} -gt 0 -a "$NoSummary" != 'True' ]; then
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
printf '\nFound %d file(s) with comment length >%d.\n'\
|
|
|
|
$Hits $MaxCols 1>&2
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
Tighten Main(), and use pager by default
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.
4 years ago
|
|
|
if [ -t 1 -a "$NoPager" != 'True' ]; then
|
|
|
|
# Prefer less(1), but have more(1) as a fallback.
|
|
|
|
if type -fP less &> /dev/null; then
|
|
|
|
Pager='less -R'
|
|
|
|
elif type -fP more &> /dev/null; then
|
|
|
|
Pager='more'
|
|
|
|
|
|
|
|
if [ "$NoColor" != 'True' ]; then
|
|
|
|
Err 1 'Only more(1) is available -- colors unsupported.'
|
|
|
|
fi
|
|
|
|
else
|
|
|
|
Err 1 'Neither less(1) nor more(1) were found.'
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Redirecting STDERR to address less(1) bug causing summary to display
|
|
|
|
# where it shouldn't; only seems to happen when colorization is enabled.
|
|
|
|
Main 2>&1 | $Pager
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
else
|
|
|
|
Main
|
|
|
|
|
|
|
|
# Testing line for use when checking the summary lines up with wc(1). When
|
|
|
|
# using this, be sure previewing is disabled and the summary is enabled.
|
Add lenchk (max_length functionality, and some)
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.
4 years ago
|
|
|
#printf '%d\n' $((`Main |& wc -l` - 2))
|
|
|
|
fi
|