frustratingly, `golang.org/x/sys/unix` started importing from `slices`
and didn't cleanly put the go headers version support, so all libraries
that used this library needed to be updated and could not take the
update without also updating to `go1.24`. So dumb.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
POSIX explicitly requires "set -e" to NOT treat "! cmd" as an error even
if fails[1]:
> The -e setting shall be ignored when executing the compound list
> following the while, until, if, or elif reserved word, *a pipeline
> beginning with the ! reserved word*, or any command of an AND-OR list
> other than the last. *[emphasis added]*
And bash has similar documentation on this behaviour[2].
This means that our tests were completely ineffective at detecting error
codes from gomtree, and as a result we did not detect the regression in
commit 83c9fdb78b ("refactor: prefactor for adding new subcommands").
The simplest solution (as done in this patch) is to just wrap all of the
failing examples in a subshell, which causes the shell to no longer
consider them exempt from "set -e". A more complete solution would be to
either switch to something like bats entirely or at least use something
like their "run" helper function to test for exit status codes
correctly.
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set
[2]: https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html
Fixes: 5d7f6c36e0 ("walk: directory is expected to be walked. A file is not.")
Fixes: 2d841d54bf ("test: testing the double -f comparison")
Fixes: f6c295f2e9 ("test: cli: add unicode verification test")
Fixes: 071977cef6 ("test: cli: add xattr tests")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This was broken during the refactor for "gomtree validate" in commit
83c9fdb78b ("refactor: prefactor for adding new subcommands"),
resulting in any code that relied on our exit code to silently treat all
errors as non-fatal.
Our tests did not catch this due to a quirky POSIX-ism with regards to
"! cmd" and "set -e" which is fixed in a follow-up patch.
Fixes: 83c9fdb78b ("refactor: prefactor for adding new subcommands")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Update the README to show the validate subcommand by default.
This doesn't eliminate the default behavior of _not_ using the command,
but begins the visibility of using it by default.
Also copy one of the existing tests, to ensure the same behaviour works
as we add more subcommands and/or global flags.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
The spec[1] doesn't mention anything about cleaning paths, but it does
explicitly refer to the path containing a "/". Cleaning the path before
checking if the entry is a FullType would result in the simplest way of
forcing directories to be FullTypes (appending a "/" to the pathname of
any directory) not working with go-mtree.
[1]: https://man.netbsd.org/mtree.5
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
As per the spec[1], Full entries must not affect the current directory.
Handling this incorrectly caused us issues with certain manifests (ones
with mixed Relative and Full entries, which is something casync does by
accident).
This is a partial fix for the issues with verifying casync-mtree's
output but there are a few other issues to iron out (including one
within casync).
[1]: https://man.netbsd.org/mtree.5
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
oh dang, I released 0.5.2 and 0.5.3 without correctly setting the
version string :-\
Ideally this "-dev" is attempting to be like the git.
So, ditch the version in the library.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
It seems this may be the last update to urfave/cli for go1.17, as their
v2.25 uses generics of go1.18 and didn't partition it with build tags
😵😵😵
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
