| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This directory was created in commit 4c46c80, but its contents haven't
been linted with `vint` until now.
|
|
|
|
|
|
|
| |
This ensures that new plugin code gets tested before being released.
We don't add the new vim/doc directory, as it's plain text rather than
VimL.
|
|
|
|
|
| |
I'm going to pretend this is a crucially important production fix, in
order to try out the "hotfix" part of the "Git flow" workflow.
|
|
|
|
| |
Just for consistency.
|
|
|
|
|
| |
This makes them more consistent with the work already done on the check
and lint scripts for the other targets.
|
|
|
|
|
|
|
|
|
| |
Use a positive list of things to check rather than just excluding
`bundle`; it's a little clearer what it's doing that way, and easier to
add paths to check rather than paths to exclude.
We also correctly leverage `vint` accepting multiple arguments, like
`shellcheck`.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
Adding the option terminator "--" directly after the `set` call ensures
that all following arguments will be interpreted as new arguments for
the list.
This is probably not strictly applicable here, because the paths that
will be stacked up don't start with dashes by definition, but it's
likely good practice.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reduce each one to target only the dotfiles specifically for that shell,
as opposed to previously where for example the `check-sh` target was
checking shell shims in for `mpd` and `plenv`.
I'm still not completely sure that's the right approach, but it's at
least less conceptually muddy than what we had before.
Notably, the check and lint for Korn shell includes a single POSIX shell
script file in its `shrc.d` subdirectory, so that check is executed
separately.
|
|
|
|
| |
This is a little bit clearer and nicer to read, I think.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This applies the same stable approach to testing the actual built
games that are shebannged with #!/bin/sh as has been applied to the
shell scripts in the `check-bin` and `lint-bin` targets.
There are no GNU Bash games in these directories, so the latter block of
code from the `bin` analogues to check or lint those is not needed.
The same applies here; this is not as complete a checking or linting of
the games directory as it could be; ideally we would check the sed(1)
and awk(1) scripts too.
|
|
|
|
|
| |
Use consistent variable names, and strip the correct suffix from the
Bash scripts on iteration.
|
|
|
|
|
|
| |
Both blocks are analogues of the POSIX checks, but are wrapped in a
conditional so that bash(1) doesn't become a hard dependency of the
default `make install` target.
|
|
|
|
|
| |
We add an `|| exit` short-circuit for the case of `shellcheck` exiting
non-zero.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the `$(BINS)` target a prerequisite of `check-bin` so that all of
the scripts with a #!/bin/sh shebang are built, and then check them all
by iterating through a glob (and hence an order according to LC_COLLATE)
and stripping the `.sh` suffix to find the name of the matching
shebanged script.
Leverage `shellcheck`'s support of multiple check arguments to build an
argument list of the binscripts first before passing all of those to a
single call, simply for speed.
We don't have anything in this target to test the scripts of any other
type, such as the `.awk` or `.sed` scripts. `gawk` has a `--lint` mode
that might apply.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Since I know there's a usable tool for this now in vim-vint, I may as
well make a target for my own convenience later.
Updated the README.markdown documentation of the `lint-*` targets,
restructuring the paragraph into a nested list for clarity. Also updated
the `dotfiles(7)` manual page to reflect those changes.
|
| |
|
|
|
|
|
|
| |
This has been neglected. Switch to per-user mpd process instantiated on
login via .profile.d. Cut back ncmpcpp config until I have time to write
one that's compatible with 0.8.
|
|
|
|
| |
I never use it
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
As part of a foray into more active use of ksh and derivatives.
|
|
|
|
|
|
| |
I know almost nothing about Yash yet, but reading the manual page on its
startup behaviour implies a little coaxing is necessary to make it play
nicely with my file layout.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Because it prevents testing directories, of course
|
| |
|
| |
|
|
Much nicer than having them embedded in the Makefile. Might do this for
some of the more complex install targets too. Or maybe all of them ...
|