* add $env:APPVEYOR_CHOCO_PESTER_OPTIONS to the `choco` install command for the `pester`
test runner within the "appveyor.yml" config file
* NOTE: AppVeyor testing will issue advisory note when the variable is non-NULL
* allows customization of `pester` install, eg, version pinning, without requiring any
further, future changes to "appveyor.yml", avoiding log noise
* mitigates test failures due solely to the test runner
.# Discussion
This change was implemented in response to multiple automated test failures which
occurred due to a regression within the `pester` test runner. The change adds the ability
to specify the `pester` version (aka, "version pinning") on AppVeyor via the "test-time"
configurable environment variable, $env:APPVEYOR_CHOCO_PESTER_OPTIONS.
By using this configurability, no changes to the project code base are needed when testing
with a specific test runner version is needed, eg, when "pester@latest" is bugged. This
avoids adding commits, which are otherwise irrelevant to development, to the project
history.
To pin a specific version of `pester`, set the "APPVEYOR_CHOCO_PESTER_OPTIONS" environment
variable to "--version=M.m.b" (eg, "--version=3.3.11") via the AppVeyor project settings
web page; a NULL or missing value will cause the usual installation of "pester@latest".
Notably, this does add a semi-hidden testing dependency. But, if testing is successful for
a given setting of the environment variable (eg, empty/NULL or "--version=M.m.b"), it will
continue to succeed for tests on subsequent commits. The only caveat is that if some added
functionality of a "pester@later" version is used, the remote automated testing might fail
due to `pester` being pinned to an earlier version. Because of this, the testing code
issues an advisory notation that the test runner installation has been customized whenever
the environment variable contains a non-NULL value.
* fixes tests by coercing the `test-unzip` return value back into a valid path string
* fixes#476
.# Discussion
For Win10 machines, `test-unzip` returns a bugged value, causing test failures.
Investigation shows that the combination of Pester, COM (used within unzip_old), and
Win10 leads to the odd/bugged return value. The return value contains the correct
string, but it is prefaced with a leading space which arises de-novo during the
execution return process from `test-unzip`. The value is correct and usable at the end
of `test-unzip` but is bugged upon receiving the value at the caller. Removing the COM
call from within `unzip_old` or using a Windows version earlier than Win10 fixes the
problem, but are obviously not useful as solutions.
Given the nature of the returned value and COM involvement, the real problem is likely
stack corruption. But it's not clear whether the issue is with Pester, Win10/PowerShell,
or possibly even some subtle bug within unzip_old.
This, admittedly hacky, coercion fixes the problem for all Windows versions and also
keeps Appveyor satisfied.
* Scoop-Alias: remove erroneous output from dot-sourcing the source file
* Scoop-Alias: using "TestDrive:\" for mocked shimdir
- reduced cleanup
- improved robustness; excution is now independent of CWD
* Scoop-Core: corrected directory location code
- improved robustness; execution is now independent of CWD
.# Discussion
These tests help to maintain five style constraints:
1. files have no utf-8 byte-order-marks (BOM)
2. all files have CRLF EOLNs (*required* for correct operation of BAT/CMD script files)
3. all files end with a newline
4. any leading whitespace consists solely of spaces
5. no trailing whitespace
By using these constraints, whitespace noise between commits is reduced to a minimum.
* change files to be in accordance with .editorconfig
* files in this commit are separate from the initial whitespace commit to check for testing code breakage
* NOTE: whitespace changes *only* (`git diff -b` shows no changes)
* remove BOM from all repo files that contain one
* changes all files to utf-8 (specifically, utf-8 *without* BOM)
* improves compliance with ".editorconfig"
.# Discussion
This is an example of the semi-invisible changes which can creep into patches
via various editors. Any such changes are *very* difficult to figure out from
a diff output and just add visual noise to commits. Hence, ".editorconfig" (added
in a previous commit) is used to minimize this kind of confusing patch noise.
* makes changes to almost all main repo files to be in accordance with .editorconfig
* some files in "test\fixtures\..." were left alone to avoid breaking tests
* NOTE: whitespace changes *only* (`git diff -b` shows no changes)
* re-enforce requested project file formats and basic character-level coding style
* emphasize the Win/DOS requirement that BAT/CMD files *must* have CRLF line endings
.# Discussion
Using [EditorConfig](http://editorconfig.org) style rules helps devs to
maintain the file formatting and style of the project, even while using different
editors. This minimizes the semi-invisible, but, paradoxically, visually noisy,
whitespace differences between commits. It can also help enforce file format
requirements (such as the Win/DOS CMD shell requiring CRLF line endings for
correct functioning of BAT/CMD files).
* change file encoding of the basic shim to be in a normal ASCII character set
.# DISCUSSION
Within PowerShell, `echo STRING > FILE` generates a file encoded in UCS-2-BOM format
(or "Unicode", in PowerShell terminology). UCS-2 later morphed into the similar
UTF-16 encoding format, and, within PowerShell, is treated as a "fuzzy equivalent"
encoding. Problematically, these UCS-2 files are misinterpreted by CMD, which expects
files using the ASCII (or "extended-ASCII") character encoding. And, in general, the
UCS-2 format has many drawbacks when interpreted outside of a narrow PowerShell
window. So, in general, it's best to stick to pure ASCII (or UTF-8, *without BOM*)
encoded files, if at all possible.
NOTE: ASCII (not "extended-ASCII") and UTF-8 (non-BOM) encoded files are exactly equivalent.
NOTE: "Extended-ASCII" is poorly defined, requiring an associated Windows Code Page designation to firmly establish the encoding.
ref: [Unicode UTF and BOM] http://www.unicode.org/faq/utf_bom.html @@ https://archive.is/TKnyk
ref: [Unicode and NET] http://csharpindepth.com/Articles/General/Unicode.aspx @@ https://archive.is/czs89
.# Discussion
Appveyor doesn't have partial `appveyor.yml` suppression. So, unless the
`appveyor.yml` configuration file is completely suppressed, non-primary devs
receive notification errors with every build/test of the application. By
removing the user-specific notifications, other devs can now build/test the
application code (via the recipe specified within `appveyor.yml`) without
receiving notification errors.
For any given developer, personalized notification settings can be added on
top of the repo `appveyor.yml` project settings via the "Settings / Notifications"
section.
* create the `etc` directory (if needed)
.# DISCUSSION
`bash` requires the `etc` directory for startup. However, `etc` is missing
from the GOW repo. There are current pull requests fixing this issue (see
bmatzelle/gow#192). But, this fixes the the issue while waiting for the GOW
repo to be updated. The fix here is compatible with all of the current possible
future GOW repo fixes.
* change method of generating gow.bat to generate a normal ASCII character file
.# DISCUSSION
At the PowerShell command line, using `echo STRING > FILE` will generate a
UTF-8-BOM or UTF-16-BOM encoded file. But, CMD interprets files as using the
128-character ASCII character set (character codes 0 to 127). CMD will tolerate
files using the full 256 character "extended-ASCII" set (or even larger
dual-byte character sets). But, in this circumstance, interpretation/display
is dependent on the currently selected code page. It's best to stick to pure
ASCII files if at all possible.
Using `STRING | Set-Content FILE` instead creates the correct ASCII character file.
NOTE: ASCII (not "extended-ASCII") and UTF-8 (non-BOM) encoded files are exactly equivalent.
ref: [Unicode UTF and BOM] http://www.unicode.org/faq/utf_bom.html @@ https://archive.is/TKnyk
ref: [Unicode and NET] http://csharpindepth.com/Articles/General/Unicode.aspx @@ https://archive.is/czs89
* disable the File::HomeDir override performed by Portable.pm
- achieved by removing the HomeDir section from "portable.perl" via post_install
- ref: https://rt.cpan.org/Ticket/Display.html?id=105395 @@ https://archive.is/q7BYq
.# DISCUSSION
Strawberry Portable Perl is written to be usable from a non-privileged
storage location, such as a plug-in USB drive. So, it is designed to be
usable without access to the host filesystem beyond it's own directory.
As part of the machinations making this possible, Portable.pm overrides
File::HomeDir to return resultant paths which are within the perl installation
directory (specifically, "<INSTALL_DIR>/data"). Obviously, this obscures the
user's true home directory and can be very inconvenient for common perl
scripts which depend on access to data within the user's home directory
(i.e., reading ".netrc").
This override/redirection is unnecessary for an installation by the user
into the usual host filesystem (such as is done via `scoop`). Such an
install has user level privileges and will be able to access any
user-accessible portion of the file system.
Roy Ivy III