Some tests failed when run using Docker because they assumed the
user would never be root. This is more of a band-aid solution.
An actual fix would be to test see if something like these tests
were to succeed when the user is root.
- adds conditional supports for unix domain sockets
- adds unix domain socket test
- adds Results to functions, removing unwraps
- uutils `cat` used to panic on broken stdout pipes (e.g. `cat
/dev/zero | head -c1`). this is fixed in this PR
- updated to exit 0 on success, and 1 if an error occurs.
- adds docstrings
- adds an error log on printing a directory
- adds categorization of other filetypes for extensible
differentiation of behaviors
- adds OutputOptions struct to replace params for extensibility
- adds correct status code on exit
`test_chmod_ugoa` and `test_chmod_many_options` both change umask, which
is global state. Since tests run concurrently, this might lead to
a situation where one of the tests changes umask to a value that screws
another test's checks. To prevent this, we introduce a mutex that should
be held by any test that changes umask.
Unfortunately, there's no way to hide umask behind this mutex and
enforce its usage: programmers will have to maintain the discipline
themselves.
* Add options -c, -F, -L, -l, -r, -R, -S, -t, -U, --color
* Fix options -a, -A
* Remove unused options
* Output in columns when not using -l
* Output date with -l
We now accept symbolic and numeric mode strings using the
--mode or -m option for install. This is used either when
moving files into a directory, or when creating component
directories with the -d option. This feature was designed
to mirror the GNU implementation, including the possibly
quirky behaviour of `install --mode=u+wx file dir`
resulting in dir/file having exactly permissions 0300.
Extensive integration tests are included.
This chnage required a higher libc dependency.
Add install utility skeleton source, based on
mv, including the getopts setup mirroring
GNU's `man install` documentation. Also
add a single test and build system code.
The main motivation is to move toward running those tests for a specific
target, that is, if a test won't run on Windows, then we shouldn't build
it. This was previously the default behavior and prevented a successful
run on AppVeyor.
I borrowed this pattern from the tests in the Cargo project.