path: root/lint/urxvt.sh
Commit message (Collapse)AuthorAgeFilesLines
* Remove diagnostic messages from check/lint scriptsTom Ryder2018-12-191-1/+0
| | | | So that `make -s` works nicely.
* Check and lint URxvt Perls correctlyTom Ryder2017-10-311-1/+6
| | | | | | Require that the URxvt Perls are built correctly. There's only one at the moment, so I'll make that the single prerequisite for the `check-urxvt` target.
* Revert "Drastically simplify `lint` scripts"Tom Ryder2017-10-311-2/+1
| | | | | | | | | | | | I forgot that the `lint` tools here need to check the *built* files, and that that's the reason the `perlcritic` check against the source .pl file was failing. While it's still true that it would be preferable to test the files found in a deterministic order, this branch's attempt to address that issue is pretty much nonsense and can be abandoned. This reverts commit 196155499c04b2c2050302e6575f1bcbbed052f1.
* Drastically simplify `lint` scriptsTom Ryder2017-10-311-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using find(1) to run the appropriate lint program over a set of files allows us to be terse and deal a little more dynamically with new files placed in the directories, but the downsides are that it's error-prone and that the order of testing is not predictable, and we'd ideally like the testing to be a little more deterministic than that. Case in point: writing the code for this commit unintentionally uncovered a longstanding issue where the URxvt Perl script `select.pl` was actually not being checked at all, due to an unneeded exclamation mark inverting the `-name` test for `*.pl` files. `select.pl` is presently not passing `perlcritic --brutal` on my machine, and likely has not been compliant since as early as commit 5000365 in March this year: >commit 500036564541ff2d65a7b2f6f6f556202d72d6ce >Author: Tom Ryder <tom@sanctum.geek.nz> >Date: Fri Mar 24 11:01:05 2017 > > Lots of Makefile tidying > > ... > * Favour find(1) calls over shell loops > ... This commit also more clearly delineates between the language being "linted" and the target for which it's being linted. The latter is likely more desirable. This needs clarification.
* More sh flexibility (check/lint scripts)Tom Ryder2017-04-051-0/+1