Llewellyn/exa
1
0
Fork 0
mirror of https://github.com/Llewellynvdm/exa.git synced 2024-11-18 18:25:10 +00:00
Code Issues Projects Releases Wiki Activity
f6b7b7f298
exa/Vagrantfile

577 lines
25 KiB
Ruby
Raw Normal View History

Fix Vagrantfile
2017-04-29 21:53:47 +00:00
require 'date'
Switch to an Ubuntu Vagrant image The non-contrib Debian one doesn’t come with guest additions, meaning it used rsync instead of Virtualbox shared folders to sync files, meaning edits made in the VM didn’t get propogated back to the host, meaning I got very confused for a while. Thanks to the parent commit, this shouldn’t be an issue at all: the default user name, which is now “ubuntu” instead of “vagrant” is specified in a lot fewer places, making it much easier to change.
2017-04-28 18:36:42 +00:00
Vagrant.configure(2) do |config|
config.vm.provider :virtualbox do |v|
v.name = 'exa'
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
v.memory = 1024
v.cpus = 1
end
Convert the aliases to actual files
2017-05-06 18:38:34 +00:00
developer = 'ubuntu'
Switch to an Ubuntu Vagrant image The non-contrib Debian one doesn’t come with guest additions, meaning it used rsync instead of Virtualbox shared folders to sync files, meaning edits made in the VM didn’t get propogated back to the host, meaning I got very confused for a while. Thanks to the parent commit, this shouldn’t be an issue at all: the default user name, which is now “ubuntu” instead of “vagrant” is specified in a lot fewer places, making it much easier to change.
2017-04-28 18:36:42 +00:00
# We use Ubuntu instead of Debian because the image comes with two-way
# shared folder support by default.
config.vm.box = 'ubuntu/xenial64'
config.vm.hostname = 'exa'
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Make the Vagrant provisioning process quieter
2017-04-30 10:06:52 +00:00
# Install the dependencies needed for exa to build, as quietly as
# apt can do.
Fish completions
2017-05-06 19:34:59 +00:00
config.vm.provision :shell, privileged: true, inline: <<-EOF
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
set -xe
Fish completions
2017-05-06 19:34:59 +00:00
apt-get install -qq -o=Dpkg::Use-Pty=0 -y \
Formalise exa-packaging script Every time I had to build exa, I copied the files manually and checked to make sure they all had the same name. There’s now a script that does all that stuff for me, so I don’t need to remember to do it anymore. It also does some things that weren’t being done before, including stripping the binary and listing its linked dependencies to we can tell if something like libhttp_parser has slipped in there (see #194)
2017-08-20 17:19:58 +00:00
git cmake curl attr libgit2-dev zip \
Bash completions
2017-05-06 20:56:40 +00:00
fish zsh bash bash-completion
Fish completions
2017-05-06 19:34:59 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Guarantee that the timezone is UTC -- some of the tests
# depend on this (for now).
config.vm.provision :shell, privileged: true, inline:
%[timedatectl set-timezone UTC]
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Install Rust.
# This is done as vagrant, not root, because it’s vagrant
# who actually uses it. Sent to /dev/null because the progress
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# bar produces a ton of output.
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
config.vm.provision :shell, privileged: false, inline:
%[hash rustc &>/dev/null || curl -sSf https://static.rust-lang.org/rustup.sh | sh &> /dev/null]
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Use a different ‘target’ directory on the VM than on the host.
# By default it just uses the one in /vagrant/target, which can
# cause problems if it has different permissions than the other
# directories, or contains object files compiled for the host.
Add some more helper scripts Also, add some welcoming text when the user logs in over SSH.
2017-08-19 16:59:52 +00:00
config.vm.provision :shell, privileged: true, inline: <<-EOF
echo 'PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/#{developer}/.cargo/bin"' > /etc/environment
echo 'CARGO_TARGET_DIR="/home/#{developer}/target"' >> /etc/environment
Fish completions
2017-05-06 19:34:59 +00:00
EOF
Add some more helper scripts Also, add some welcoming text when the user logs in over SSH.
2017-08-19 16:59:52 +00:00
# Create a variety of misc scripts.
Fish completions
2017-05-06 19:34:59 +00:00
config.vm.provision :shell, privileged: true, inline: <<-EOF
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
set -xe
Switch to the new options parser This commit removes the dependency on the ‘getopts’ crate entirely, and re-writes all its uses to use the new options parser instead. As expected there are casualties galore: - We now need to collect the options into a vector at the start, so we can use references to them, knowing they’ll be stored *somewhere*. - Because OsString isn’t Display, its Debug impl gets used instead. (This is hopefully temporary) - Options that take values (such as ‘sort’ or ‘time-style’) now parse those values with ‘to_string_lossy’. The ‘lossy’ part means “I’m at a loss for what to do here” - Error messages got a lot worse, but “--tree --all --all” is now a special case of error rather than just another Misfire::Useless. - Some tests had to be re-written to deal with the fact that the parser works with references. - ParseError loses its lifetime and owns its contents, to avoid having to attach <'a> to Misfire. - The parser now takes an iterator instead of a slice. - OsStrings can’t be ‘match’ patterns, so the code devolves to using long Eq chains instead. - Make a change to the xtest that assumed an input argument with invalid UTF-8 in was always an error to stderr, when that now in fact works! - Fix a bug in Vagrant where ‘exa’ and ‘rexa’ didn’t properly escape filenames with spaces in.
2017-07-26 16:48:18 +00:00
echo -e "#!/bin/sh\n/home/#{developer}/target/debug/exa \"\\$*\"" > /usr/bin/exa
echo -e "#!/bin/sh\n/home/#{developer}/target/release/exa \"\\$*\"" > /usr/bin/rexa
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
Add some more helper scripts Also, add some welcoming text when the user logs in over SSH.
2017-08-19 16:59:52 +00:00
echo -e "#!/bin/sh\ncargo build --manifest-path /vagrant/Cargo.toml" > /usr/bin/build-exa
ln -sf /usr/bin/build-exa /usr/bin/b
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
Quieten the test output
2017-08-19 22:25:51 +00:00
echo -e "#!/bin/sh\ncargo test --manifest-path /vagrant/Cargo.toml --lib -- --quiet" > /usr/bin/test-exa
Add some more helper scripts Also, add some welcoming text when the user logs in over SSH.
2017-08-19 16:59:52 +00:00
ln -sf /usr/bin/test-exa /usr/bin/t
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
Add some more helper scripts Also, add some welcoming text when the user logs in over SSH.
2017-08-19 16:59:52 +00:00
echo -e "#!/bin/sh\n/vagrant/xtests/run.sh" > /usr/bin/run-xtests
ln -sf /usr/bin/run-xtests /usr/bin/x
echo -e "#!/bin/sh\nbuild-exa && test-exa && run-xtests" > /usr/bin/compile-exa
ln -sf /usr/bin/compile-exa /usr/bin/c
Formalise exa-packaging script Every time I had to build exa, I copied the files manually and checked to make sure they all had the same name. There’s now a script that does all that stuff for me, so I don’t need to remember to do it anymore. It also does some things that weren’t being done before, including stripping the binary and listing its linked dependencies to we can tell if something like libhttp_parser has slipped in there (see #194)
2017-08-20 17:19:58 +00:00
echo "#!/bin/bash" > /usr/bin/package-exa
echo "set -e" >> /usr/bin/package-exa
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
Formalise exa-packaging script Every time I had to build exa, I copied the files manually and checked to make sure they all had the same name. There’s now a script that does all that stuff for me, so I don’t need to remember to do it anymore. It also does some things that weren’t being done before, including stripping the binary and listing its linked dependencies to we can tell if something like libhttp_parser has slipped in there (see #194)
2017-08-20 17:19:58 +00:00
echo 'echo -e "\nCompiling release version of exa..."' >> /usr/bin/package-exa
echo "cargo build --release --manifest-path /vagrant/Cargo.toml" >> /usr/bin/package-exa
echo "cargo test --release --manifest-path /vagrant/Cargo.toml --lib" >> /usr/bin/package-exa
echo "/vagrant/xtests/run.sh --release" >> /usr/bin/package-exa
echo "cp /home/ubuntu/target/release/exa /vagrant/exa-linux-x86_64" >> /usr/bin/package-exa
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
Formalise exa-packaging script Every time I had to build exa, I copied the files manually and checked to make sure they all had the same name. There’s now a script that does all that stuff for me, so I don’t need to remember to do it anymore. It also does some things that weren’t being done before, including stripping the binary and listing its linked dependencies to we can tell if something like libhttp_parser has slipped in there (see #194)
2017-08-20 17:19:58 +00:00
echo 'echo -e "\nStripping binary..."' >> /usr/bin/package-exa
echo "strip /vagrant/exa-linux-x86_64" >> /usr/bin/package-exa
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
Formalise exa-packaging script Every time I had to build exa, I copied the files manually and checked to make sure they all had the same name. There’s now a script that does all that stuff for me, so I don’t need to remember to do it anymore. It also does some things that weren’t being done before, including stripping the binary and listing its linked dependencies to we can tell if something like libhttp_parser has slipped in there (see #194)
2017-08-20 17:19:58 +00:00
echo 'echo -e "\nZipping binary..."' >> /usr/bin/package-exa
echo "rm -f /vagrant/exa-linux-x86_64.zip" >> /usr/bin/package-exa
echo "zip /vagrant/exa-linux-x86_64.zip /vagrant/exa-linux-x86_64" >> /usr/bin/package-exa
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
Formalise exa-packaging script Every time I had to build exa, I copied the files manually and checked to make sure they all had the same name. There’s now a script that does all that stuff for me, so I don’t need to remember to do it anymore. It also does some things that weren’t being done before, including stripping the binary and listing its linked dependencies to we can tell if something like libhttp_parser has slipped in there (see #194)
2017-08-20 17:19:58 +00:00
echo 'echo -e "\nLibraries linked:"' >> /usr/bin/package-exa
echo "ldd /vagrant/exa-linux-x86_64" >> /usr/bin/package-exa
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
Formalise exa-packaging script Every time I had to build exa, I copied the files manually and checked to make sure they all had the same name. There’s now a script that does all that stuff for me, so I don’t need to remember to do it anymore. It also does some things that weren’t being done before, including stripping the binary and listing its linked dependencies to we can tell if something like libhttp_parser has slipped in there (see #194)
2017-08-20 17:19:58 +00:00
echo 'echo -e "\nAll done!"' >> /usr/bin/package-exa
echo '/vagrant/exa-linux-x86_64 /vagrant/exa-linux-x86_64* -lB' >> /usr/bin/package-exa
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
Formalise exa-packaging script Every time I had to build exa, I copied the files manually and checked to make sure they all had the same name. There’s now a script that does all that stuff for me, so I don’t need to remember to do it anymore. It also does some things that weren’t being done before, including stripping the binary and listing its linked dependencies to we can tell if something like libhttp_parser has slipped in there (see #194)
2017-08-20 17:19:58 +00:00
chmod +x /usr/bin/{exa,rexa,b,t,x,c,build-exa,test-exa,run-xtests,compile-exa,package-exa}
Add some more helper scripts Also, add some welcoming text when the user logs in over SSH.
2017-08-19 16:59:52 +00:00
EOF
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
Use my patched verson of git2-rs Now, the Vagrant VM uses my patched version of git2-rs, which has a modified build.rs file in libgit2-sys, which blocks libhttp_parser from being linked. As you can see by the comment, I’m not a fan of the fix, but at least it works, right? See #194, and also #255.
2017-08-20 19:04:59 +00:00
# Download my patched version of git2-rs.
# This is basically a hack and we should get rid of it as soon as
# a better solution comes along.
# See https://github.com/ogham/exa/issues/194
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
if [ -d /home/ubuntu/git2-rs ]; then
cd /home/ubuntu/git2-rs
git pull https://github.com/ogham/git2-rs.git || echo "Failed to update git2-rs fork"
else
git clone https://github.com/ogham/git2-rs.git /home/ubuntu/git2-rs
fi
Use my patched verson of git2-rs Now, the Vagrant VM uses my patched version of git2-rs, which has a modified build.rs file in libgit2-sys, which blocks libhttp_parser from being linked. As you can see by the comment, I’m not a fan of the fix, but at least it works, right? See #194, and also #255.
2017-08-20 19:04:59 +00:00
mkdir -p /home/ubuntu/.cargo
echo 'paths = ["/home/ubuntu/git2-rs/libgit2-sys"]' > /home/ubuntu/.cargo/config
EOF
Don’t re-clone the git2-rs repo Apparently trying to clone a repository onto an already-cloned clone just errors
2017-08-26 14:13:19 +00:00
Use my patched verson of git2-rs Now, the Vagrant VM uses my patched version of git2-rs, which has a modified build.rs file in libgit2-sys, which blocks libhttp_parser from being linked. As you can see by the comment, I’m not a fan of the fix, but at least it works, right? See #194, and also #255.
2017-08-20 19:04:59 +00:00
# This fix is applied by changing the VM rather than changing the
# Cargo.toml file so it works for everyone because it’s such a niche
# build issue, it’s not worth specifying a non-crates.io dependency
# and losing the ability to `cargo publish` the exa crate there!
# It also isolates the hackiness to the one place I can test it
# actually works.
Add some more helper scripts Also, add some welcoming text when the user logs in over SSH.
2017-08-19 16:59:52 +00:00
# Write some welcoming text.
config.vm.provision :shell, privileged: true, inline: <<-EOF
rm -f /etc/update-motd.d/*
And again for LS_COLORS
2017-08-19 20:58:59 +00:00
Add some more helper scripts Also, add some welcoming text when the user logs in over SSH.
2017-08-19 16:59:52 +00:00
echo -e "" > /etc/motd
echo -e "\033[1;33mThe exa development environment!\033[0m" >> /etc/motd
Say where the target directory is too
2017-08-19 22:36:25 +00:00
echo -e "exa's source is available at \033[33m/vagrant\033[0m." >> /etc/motd
echo -e "Binaries get built into \033[33m/home/ubuntu/target\033[0m." >> /etc/motd
Add some more helper scripts Also, add some welcoming text when the user logs in over SSH.
2017-08-19 16:59:52 +00:00
echo -e "" >> /etc/motd
echo -e "\033[4mCommands\033[0m" >> /etc/motd
echo -e "\033[32;1mb\033[0m or \033[32;1mbuild-exa\033[0m to run \033[1mcargo build\033[0m" >> /etc/motd
echo -e "\033[32;1mt\033[0m or \033[32;1mtest-exa\033[0m to run \033[1mcargo test\033[0m" >> /etc/motd
echo -e "\033[32;1mx\033[0m or \033[32;1mrun-xtests\033[0m to run \033[1m/vagrant/xtests/run.sh\033[0m" >> /etc/motd
And again for LS_COLORS
2017-08-19 20:58:59 +00:00
echo -e "\033[32;1mc\033[0m or \033[32;1mcompile-exa\033[0m to run all three" >> /etc/motd
echo -e "\033[32;1mdebug on\033[0;32m|\033[1moff\033[0m to toggle printing logs" >> /etc/motd
echo -e "\033[32;1mstrict on\033[0;32m|\033[1moff\033[0m to toggle strict mode" >> /etc/motd
echo -e "\033[32;1mls-colors on\033[0;32m|\033[1moff\033[0m to toggle LS_COLORS\n" >> /etc/motd
Make debug mode switch-on-and-offable
2017-08-19 20:13:44 +00:00
# help banner
Add some more helper scripts Also, add some welcoming text when the user logs in over SSH.
2017-08-19 16:59:52 +00:00
echo 'echo -e "\\033[4mVersions\\033[0m"' > /home/ubuntu/.bash_profile
echo "rustc --version" >> /home/ubuntu/.bash_profile
echo "cargo --version" >> /home/ubuntu/.bash_profile
echo "echo" >> /home/ubuntu/.bash_profile
And again for LS_COLORS
2017-08-19 20:58:59 +00:00
Make debug mode switch-on-and-offable
2017-08-19 20:13:44 +00:00
# cool prompt
Include a fancy custom prompt
2017-08-19 19:23:37 +00:00
echo 'function nonzero_return() { RETVAL=$?; [ $RETVAL -ne 0 ] && echo "$RETVAL "; }' >> /home/ubuntu/.bash_profile
Make debug mode switch-on-and-offable
2017-08-19 20:13:44 +00:00
echo 'function debug_mode() { [ -n "$EXA_DEBUG" ] && echo "debug "; }' >> /home/ubuntu/.bash_profile
Do the same for strict mode
2017-08-19 20:20:14 +00:00
echo 'function strict_mode() { [ -n "$EXA_STRICT" ] && echo "strict "; }' >> /home/ubuntu/.bash_profile
And again for LS_COLORS
2017-08-19 20:58:59 +00:00
echo 'function lsc_mode() { [ -n "$LS_COLORS" ] && echo "lsc "; }' >> /home/ubuntu/.bash_profile
Make the prompt bold
2017-08-19 21:37:52 +00:00
echo 'export PS1="\\[\\e[1;36m\\]\\h \\[\\e[32m\\]\\w \\[\\e[31m\\]\\`nonzero_return\\`\\[\\e[35m\\]\\`debug_mode\\`\\[\\e[32m\\]\\`lsc_mode\\`\\[\\e[33m\\]\\`strict_mode\\`\\[\\e[36m\\]\\\\$\\[\\e[0m\\] "' >> /home/ubuntu/.bash_profile
And again for LS_COLORS
2017-08-19 20:58:59 +00:00
Make debug mode switch-on-and-offable
2017-08-19 20:13:44 +00:00
# environment setting
echo 'function debug () {' >> /home/ubuntu/.bash_profile
echo ' case "$1" in "on") export EXA_DEBUG=1 ;;' >> /home/ubuntu/.bash_profile
echo ' "off") export EXA_DEBUG= ;;' >> /home/ubuntu/.bash_profile
echo ' "") [ -n "$EXA_DEBUG" ] && echo "debug on" || echo "debug off" ;;' >> /home/ubuntu/.bash_profile
echo ' *) echo "Usage: debug on|off"; return 1 ;; esac; }' >> /home/ubuntu/.bash_profile
And again for LS_COLORS
2017-08-19 20:58:59 +00:00
Do the same for strict mode
2017-08-19 20:20:14 +00:00
echo 'function strict () {' >> /home/ubuntu/.bash_profile
echo ' case "$1" in "on") export EXA_STRICT=1 ;;' >> /home/ubuntu/.bash_profile
echo ' "off") export EXA_STRICT= ;;' >> /home/ubuntu/.bash_profile
echo ' "") [ -n "$EXA_STRICT" ] && echo "strict on" || echo "strict off" ;;' >> /home/ubuntu/.bash_profile
echo ' *) echo "Usage: strict on|off"; return 1 ;; esac; }' >> /home/ubuntu/.bash_profile
And again for LS_COLORS
2017-08-19 20:58:59 +00:00
echo 'function ls-colors () {' >> /home/ubuntu/.bash_profile
Add unnecessary hacker theme
2017-08-26 13:05:08 +00:00
echo ' case "$1" in ' >> /home/ubuntu/.bash_profile
echo ' "on") export LS_COLORS="di=34:ln=35:so=32:pi=33:ex=31:bd=34;46:cd=34;43:su=30;41:sg=30;46:tw=30;42:ow=30;43" ;;' >> /home/ubuntu/.bash_profile
echo ' "hacker") export LS_COLORS="di=32:ex=32:fi=32:pi=32:so=32:bd=32:cd=32:ln=32:or=32:mi=32" ;;' >> /home/ubuntu/.bash_profile
echo ' "off") export LS_COLORS= ;;' >> /home/ubuntu/.bash_profile
echo ' "") [ -n "$LS_COLORS" ] && echo "LS_COLORS=$LS_COLORS" || echo "ls-colors off" ;;' >> /home/ubuntu/.bash_profile
echo ' *) echo "Usage: ls-colors on|off"; return 1 ;; esac; }' >> /home/ubuntu/.bash_profile
And again for LS_COLORS
2017-08-19 20:58:59 +00:00
Add some more helper scripts Also, add some welcoming text when the user logs in over SSH.
2017-08-19 16:59:52 +00:00
# Disable last login date in sshd
sed -i '/PrintLastLog yes/c\PrintLastLog no' /etc/ssh/sshd_config
systemctl restart sshd
Give everybody dexa and rexa aliases Also, make it so the same line doesn’t get added to the .bashrc every time provisioning is run.
2017-05-06 18:07:29 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Fish completions
2017-05-06 19:34:59 +00:00
# Link the completion files so they’re “installed”.
config.vm.provision :shell, privileged: true, inline: <<-EOF
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
set -xe
Bash completions
2017-05-06 20:56:40 +00:00
test -h /etc/bash_completion.d/exa \
|| ln -s /vagrant/contrib/completions.bash /etc/bash_completion.d/exa
Zsh completions
2017-05-06 19:50:24 +00:00
test -h /usr/share/zsh/vendor-completions/_exa \
|| ln -s /vagrant/contrib/completions.zsh /usr/share/zsh/vendor-completions/_exa
test -h /usr/share/fish/completions/exa.fish \
Fish completions
2017-05-06 19:34:59 +00:00
|| ln -s /vagrant/contrib/completions.fish /usr/share/fish/completions/exa.fish
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# We create two users that own the test files.
Convert the aliases to actual files
2017-05-06 18:38:34 +00:00
# The first one just owns the ordinary ones, because we don’t want the
# test outputs to depend on “vagrant” or “ubuntu” existing.
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
user = "cassowary"
config.vm.provision :shell, privileged: true, inline:
%[id -u #{user} &>/dev/null || useradd #{user}]
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# The second one has a long name, to test that the file owner column
# widens correctly. The benefit of Vagrant is that we don’t need to
# set this up on the *actual* system!
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
longuser = "antidisestablishmentarienism"
config.vm.provision :shell, privileged: true, inline:
%[id -u #{longuser} &>/dev/null || useradd #{longuser}]
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Protect xtests against the passage of time There was a problem with the Vagrant tests where the year 2016 was hard-coded in as the modified date. This had to be done to make the --long tests use the correct date format, which varies depending on whether the timestamp is in the current year. Unfortunately, time progresses [citation needed], and what was once 2016 is now 2017, so the date format changed and the tests broke. Because the Vagrantfile is just a Ruby script, we can look up the current year at runtime and use that instead. There’s also a check added to the test runner that makes sure none of the files are more than 365 days old, because if any are, then it’s time to update the timestamps (or it’s the last day of a leap year)
2017-04-28 18:26:57 +00:00
# Because the timestamps are formatted differently depending on whether
# they’re in the current year or not (see `details.rs`), we have to make
# sure that the files are created in the current year, so they get shown
# in the format we expect.
current_year = Date.today.year
some_date = "#{current_year}01011234.56" # 1st January, 12:34:56
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# We also need an UID and a GID that are guaranteed to not exist, to
# test what happen when they don’t.
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
invalid_uid = 666
invalid_gid = 616
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# Delete old testcases if they exist already, then create a
# directory to house new ones.
test_dir = "/testcases"
config.vm.provision :shell, privileged: true, inline: <<-EOF
set -xe
rm -rfv #{test_dir}
mkdir #{test_dir}
chmod 777 #{test_dir}
EOF
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Awkward file size testcases.
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# This needs sudo to set the files’ users at the very end.
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/files"
for i in {1..13}; do
fallocate -l "$i" "#{test_dir}/files/$i"_bytes
fallocate -l "$i"KiB "#{test_dir}/files/$i"_KiB
fallocate -l "$i"MiB "#{test_dir}/files/$i"_MiB
done
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
touch -t #{some_date} "#{test_dir}/files/"*
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
chmod 644 "#{test_dir}/files/"*
sudo chown #{user}:#{user} "#{test_dir}/files/"*
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
# File name extension testcases.
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
# These aren’t tested in details view, but we set timestamps on them to
# test that various sort options work.
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
mkdir "#{test_dir}/file-names-exts"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/Makefile"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
touch "#{test_dir}/file-names-exts/IMAGE.PNG"
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/image.svg"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
touch "#{test_dir}/file-names-exts/VIDEO.AVI"
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/video.wmv"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/music.mp3"
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
touch "#{test_dir}/file-names-exts/MUSIC.OGG"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/lossless.flac"
touch "#{test_dir}/file-names-exts/lossless.wav"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/crypto.asc"
touch "#{test_dir}/file-names-exts/crypto.signature"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/document.pdf"
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
touch "#{test_dir}/file-names-exts/DOCUMENT.XLSX"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
touch "#{test_dir}/file-names-exts/COMPRESSED.ZIP"
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/compressed.tar.gz"
touch "#{test_dir}/file-names-exts/compressed.tgz"
Add extra types to compressed filetype filter. This adds a few more common compressed filetypes to the is_compressed fuction. Notably, xz, and two common package file formats, deb and rpm.
2017-08-07 03:04:24 +00:00
touch "#{test_dir}/file-names-exts/compressed.tar.xz"
touch "#{test_dir}/file-names-exts/compressed.txz"
touch "#{test_dir}/file-names-exts/compressed.deb"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/backup~"
touch "#{test_dir}/file-names-exts/#SAVEFILE#"
touch "#{test_dir}/file-names-exts/file.tmp"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/compiled.class"
touch "#{test_dir}/file-names-exts/compiled.o"
touch "#{test_dir}/file-names-exts/compiled.js"
touch "#{test_dir}/file-names-exts/compiled.coffee"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Add some awkward file name testcases
2017-05-01 11:22:57 +00:00
# File name testcases.
# bash really doesn’t want you to create a file with escaped characters
# in its name, so we have to resort to the echo builtin and touch!
#
# The double backslashes are not strictly necessary; without them, Ruby
# will interpolate them instead of bash, but because Vagrant prints out
# each command it runs, your *own* terminal will go “ding” from the alarm!
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/file-names"
echo -ne "#{test_dir}/file-names/ascii: hello" | xargs -0 touch
echo -ne "#{test_dir}/file-names/emoji: [🆒]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/utf-8: pâté" | xargs -0 touch
echo -ne "#{test_dir}/file-names/bell: [\\a]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/backspace: [\\b]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/form-feed: [\\f]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/new-line: [\\n]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/return: [\\r]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/tab: [\\t]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/vertical-tab: [\\v]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/escape: [\\033]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/ansi: [\\033[34mblue\\033[0m]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/invalid-utf8-1: [\\xFF]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/invalid-utf8-2: [\\xc3\\x28]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/invalid-utf8-3: [\\xe2\\x82\\x28]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/invalid-utf8-4: [\\xf0\\x28\\x8c\\x28]" | xargs -0 touch
Also escape characters in links and headings Doing this meant that the escaping functionality got used in three places, so it was extracted into a generalised function in its own module. This is slighly slower for the case where escaped characters are displayed in the same colour as the displayable characters, which happens when listing a directory’s name when recursing. Optimise this, yeah?
2017-05-01 20:54:53 +00:00
echo -ne "#{test_dir}/file-names/new-line-dir: [\\n]" | xargs -0 mkdir
echo -ne "#{test_dir}/file-names/new-line-dir: [\\n]/subfile" | xargs -0 touch
echo -ne "#{test_dir}/file-names/new-line-dir: [\\n]/another: [\\n]" | xargs -0 touch
Also escape characters in broken symlinks
2017-05-02 07:46:43 +00:00
echo -ne "#{test_dir}/file-names/new-line-dir: [\\n]/broken" | xargs -0 touch
Also escape characters in links and headings Doing this meant that the escaping functionality got used in three places, so it was extracted into a generalised function in its own module. This is slighly slower for the case where escaped characters are displayed in the same colour as the displayable characters, which happens when listing a directory’s name when recursing. Optimise this, yeah?
2017-05-01 20:54:53 +00:00
mkdir "#{test_dir}/file-names/links"
ln -s "#{test_dir}/file-names/new-line-dir"*/* "#{test_dir}/file-names/links"
Also escape characters in broken symlinks
2017-05-02 07:46:43 +00:00
echo -ne "#{test_dir}/file-names/new-line-dir: [\\n]/broken" | xargs -0 rm
Add some awkward file name testcases
2017-05-01 11:22:57 +00:00
EOF
Start adding some special file testcases
2017-04-28 22:24:19 +00:00
# Special file testcases.
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/specials"
sudo mknod "#{test_dir}/specials/block-device" b 3 60
sudo mknod "#{test_dir}/specials/char-device" c 14 40
sudo mknod "#{test_dir}/specials/named-pipe" p
Tests for classify and special file types
2017-04-29 08:21:31 +00:00
sudo touch -t #{some_date} "#{test_dir}/specials/"*
Start adding some special file testcases
2017-04-28 22:24:19 +00:00
EOF
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Awkward symlink testcases.
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/links"
Add tests for relative symlinks
2017-04-30 10:58:29 +00:00
ln -s / "#{test_dir}/links/root"
ln -s /usr "#{test_dir}/links/usr"
ln -s nowhere "#{test_dir}/links/broken"
Add some symlink testcases
2016-10-29 18:58:34 +00:00
ln -s /proc/1/root "#{test_dir}/links/forbidden"
Add tests for relative symlinks
2017-04-30 10:58:29 +00:00
touch "#{test_dir}/links/some_file"
ln -s "#{test_dir}/links/some_file" "#{test_dir}/links/some_file_absolute"
(cd "#{test_dir}/links"; ln -s "some_file" "some_file_relative")
(cd "#{test_dir}/links"; ln -s "." "current_dir")
(cd "#{test_dir}/links"; ln -s ".." "parent_dir")
(cd "#{test_dir}/links"; ln -s "itself" "itself")
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Awkward passwd testcases.
# sudo is needed for these because we technically aren’t a member
# of the groups (because they don’t exist), and chown and chgrp
# are smart enough to disallow it!
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/passwd"
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
touch -t #{some_date} "#{test_dir}/passwd/unknown-uid"
chmod 644 "#{test_dir}/passwd/unknown-uid"
sudo chown #{invalid_uid}:#{user} "#{test_dir}/passwd/unknown-uid"
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
touch -t #{some_date} "#{test_dir}/passwd/unknown-gid"
chmod 644 "#{test_dir}/passwd/unknown-gid"
sudo chown #{user}:#{invalid_gid} "#{test_dir}/passwd/unknown-gid"
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Awkward permission testcases.
xtests for higher order bits Finally, re-do the permissions extended tests to include the setuid, setgid, and sticky bits, and rename the last two existing ones to match the others (files with the same names as their permissions).
2017-05-30 14:32:11 +00:00
# Differences in the way ‘chmod’ handles setting ‘setuid’ and ‘setgid’
# when you don’t already own the file mean that we need to use ‘sudo’
# to change permissions to those.
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/permissions"
xtests for higher order bits Finally, re-do the permissions extended tests to include the setuid, setgid, and sticky bits, and rename the last two existing ones to match the others (files with the same names as their permissions).
2017-05-30 14:32:11 +00:00
mkdir "#{test_dir}/permissions/forbidden-directory"
chmod 000 "#{test_dir}/permissions/forbidden-directory"
touch -t #{some_date} "#{test_dir}/permissions/forbidden-directory"
sudo chown #{user}:#{user} "#{test_dir}/permissions/forbidden-directory"
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
xtests for higher order bits Finally, re-do the permissions extended tests to include the setuid, setgid, and sticky bits, and rename the last two existing ones to match the others (files with the same names as their permissions).
2017-05-30 14:32:11 +00:00
for perms in 000 001 002 004 010 020 040 100 200 400 644 755 777 1000 1001 2000 2010 4000 4100 7666 7777; do
touch "#{test_dir}/permissions/$perms"
sudo chown #{user}:#{user} "#{test_dir}/permissions/$perms"
sudo chmod $perms "#{test_dir}/permissions/$perms"
sudo touch -t #{some_date} "#{test_dir}/permissions/$perms"
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
done
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
EOF
Generate files with certain timestamps This is going to be used to test time formatting. Casualty here is that the “have you not ran the provisioning script in a year?” checker complained about there being files more than a year old, so that now has to ignore the times directory.
2017-07-03 07:46:38 +00:00
old = '200303030000.00'
Test the locale month name width stuff This commit modifies a specific file timestamp so we test both July (which is 5 characters in French) and December (which is 4 characters in Japanese). It’s also kind of a test for locales as well.
2017-08-06 21:25:00 +00:00
med = '200606152314.29' # the june gets used for fr_FR locale tests
new = '200912221038.53' # and the december for ja_JP local tests
Generate files with certain timestamps This is going to be used to test time formatting. Casualty here is that the “have you not ran the provisioning script in a year?” checker complained about there being files more than a year old, so that now has to ignore the times directory.
2017-07-03 07:46:38 +00:00
# Awkward date and time testcases.
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/dates"
# there's no way to touch the created date of a file...
# so we have to do this the old-fashioned way!
# (and make sure these don't actually get listed)
touch -t #{old} "#{test_dir}/dates/peach"; sleep 1
touch -t #{med} "#{test_dir}/dates/plum"; sleep 1
touch -t #{new} "#{test_dir}/dates/pear"
# modified dates
touch -t #{old} -m "#{test_dir}/dates/pear"
touch -t #{med} -m "#{test_dir}/dates/peach"
touch -t #{new} -m "#{test_dir}/dates/plum"
# accessed dates
touch -t #{old} -a "#{test_dir}/dates/plum"
touch -t #{med} -a "#{test_dir}/dates/pear"
touch -t #{new} -a "#{test_dir}/dates/peach"
Fix bug where accessed times were wrong! It used the mtime, rather than the atime. Copy and paste error. Whoops!
2017-07-05 21:07:03 +00:00
sudo chown #{user}:#{user} -R "#{test_dir}/dates"
Generate files with certain timestamps This is going to be used to test time formatting. Casualty here is that the “have you not ran the provisioning script in a year?” checker complained about there being files more than a year old, so that now has to ignore the times directory.
2017-07-03 07:46:38 +00:00
EOF
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Awkward extended attribute testcases.
Much more thorough xattr testing It now tests a lot more combinations of xattrs on files, as well as xattrs and files and errors as the children of directories. The recent code changes have touched the part where directories’ xattrs and children are displayed at the same tree level, and there weren’t enough tests for this.
2017-07-04 16:42:16 +00:00
# We need to test combinations of various numbers of files *and*
# extended attributes in directories. Turns out, the easiest way to
# do this is to generate all combinations of files with “one-xattr”
# or “two-xattrs” in their name and directories with “empty” or
# “one-file” in their name, then just give the right number of
# xattrs and children to those.
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/attributes"
Much more thorough xattr testing It now tests a lot more combinations of xattrs on files, as well as xattrs and files and errors as the children of directories. The recent code changes have touched the part where directories’ xattrs and children are displayed at the same tree level, and there weren’t enough tests for this.
2017-07-04 16:42:16 +00:00
mkdir "#{test_dir}/attributes/files"
touch "#{test_dir}/attributes/files/"{no-xattrs,one-xattr,two-xattrs}{,_forbidden}
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
mkdir "#{test_dir}/attributes/dirs"
Much more thorough xattr testing It now tests a lot more combinations of xattrs on files, as well as xattrs and files and errors as the children of directories. The recent code changes have touched the part where directories’ xattrs and children are displayed at the same tree level, and there weren’t enough tests for this.
2017-07-04 16:42:16 +00:00
mkdir "#{test_dir}/attributes/dirs/"{no-xattrs,one-xattr,two-xattrs}_{empty,one-file,two-files}{,_forbidden}
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
Much more thorough xattr testing It now tests a lot more combinations of xattrs on files, as well as xattrs and files and errors as the children of directories. The recent code changes have touched the part where directories’ xattrs and children are displayed at the same tree level, and there weren’t enough tests for this.
2017-07-04 16:42:16 +00:00
setfattr -n user.greeting -v hello "#{test_dir}/attributes"/**/*{one-xattr,two-xattrs}*
setfattr -n user.another_greeting -v hi "#{test_dir}/attributes"/**/*two-xattrs*
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
Much more thorough xattr testing It now tests a lot more combinations of xattrs on files, as well as xattrs and files and errors as the children of directories. The recent code changes have touched the part where directories’ xattrs and children are displayed at the same tree level, and there weren’t enough tests for this.
2017-07-04 16:42:16 +00:00
for dir in "#{test_dir}/attributes/dirs/"*one-file*; do
touch $dir/file-in-question
done
for dir in "#{test_dir}/attributes/dirs/"*two-files*; do
touch $dir/this-file
touch $dir/that-file
done
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
Much more thorough xattr testing It now tests a lot more combinations of xattrs on files, as well as xattrs and files and errors as the children of directories. The recent code changes have touched the part where directories’ xattrs and children are displayed at the same tree level, and there weren’t enough tests for this.
2017-07-04 16:42:16 +00:00
touch -t #{some_date} "#{test_dir}/attributes" # there's probably
touch -t #{some_date} "#{test_dir}/attributes"/* # a better
touch -t #{some_date} "#{test_dir}/attributes"/*/* # way to
touch -t #{some_date} "#{test_dir}/attributes"/*/*/* # do this
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
Much more thorough xattr testing It now tests a lot more combinations of xattrs on files, as well as xattrs and files and errors as the children of directories. The recent code changes have touched the part where directories’ xattrs and children are displayed at the same tree level, and there weren’t enough tests for this.
2017-07-04 16:42:16 +00:00
# I want to use the following to test,
# but it only works on macos:
#chmod +a "#{user} deny readextattr" "#{test_dir}/attributes"/**/*_forbidden
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Much more thorough xattr testing It now tests a lot more combinations of xattrs on files, as well as xattrs and files and errors as the children of directories. The recent code changes have touched the part where directories’ xattrs and children are displayed at the same tree level, and there weren’t enough tests for this.
2017-07-04 16:42:16 +00:00
sudo chmod 000 "#{test_dir}/attributes"/**/*_forbidden
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
sudo chown #{user}:#{user} -R "#{test_dir}/attributes"
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
EOF
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
Add xtests for existing Git implementation
2017-05-17 08:17:12 +00:00
# A sample Git repository
# This uses cd because it's easier than telling Git where to go each time
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/git"
cd "#{test_dir}/git"
git init
mkdir edits additions moves
echo "original content" | tee edits/{staged,unstaged,both}
echo "this file gets moved" > moves/hither
git add edits moves
git commit -m "Automated test commit"
echo "modifications!" | tee edits/{staged,both}
touch additions/{staged,edited}
mv moves/{hither,thither}
git add edits moves additions
echo "more modifications!" | tee edits/unstaged edits/both additions/edited
touch additions/unstaged
touch -t #{some_date} "#{test_dir}/git/"*/*
sudo chown #{user}:#{user} -R "#{test_dir}/git"
EOF
Override the names of . and .. There was a problem when displaying . and .. in directory listings: their names would normalise to actual names! So instead of literally seeing `.`, you’d see the current directory’s name, inserted in sort order into the list of results. Obviously this is not what we want. In unrelated news, putting `.` and `..` into the list of paths read from a directory just takes up more heap space for something that’s basically constant. We can solve both these problems at once by moving the DotFilter to the files iterator in Dir, rather than at the Dir’s creation. Having the iterator know whether it should display `.` and `..` means it can emit those files first, and because it knows what those files really represent, it can override their file names to actually be those sequences of dots. This is not a perfect solution: the main casualty is that a File can now be constructed with a name, some metadata, both, or neither. This is currently handled with a bunch of Options, and returns IOResult even without doing any IO operations. But at least all the tests pass!
2017-06-28 17:41:31 +00:00
# Hidden and dot file testcases.
# We need to set the permissions of `.` and `..` because they actually
# get displayed in the output here, so this has to come last.
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
shopt -u dotglob
GLOBIGNORE=".:.."
mkdir "#{test_dir}/hiddens"
touch "#{test_dir}/hiddens/visible"
touch "#{test_dir}/hiddens/.hidden"
touch "#{test_dir}/hiddens/..extra-hidden"
# ./hiddens/
touch -t #{some_date} "#{test_dir}/hiddens/"*
chmod 644 "#{test_dir}/hiddens/"*
sudo chown #{user}:#{user} "#{test_dir}/hiddens/"*
# .
touch -t #{some_date} "#{test_dir}/hiddens"
chmod 755 "#{test_dir}/hiddens"
sudo chown #{user}:#{user} "#{test_dir}/hiddens"
# ..
sudo touch -t #{some_date} "#{test_dir}"
sudo chmod 755 "#{test_dir}"
sudo chown #{user}:#{user} "#{test_dir}"
EOF
Test the locale month name width stuff This commit modifies a specific file timestamp so we test both July (which is 5 characters in French) and December (which is 4 characters in Japanese). It’s also kind of a test for locales as well.
2017-08-06 21:25:00 +00:00
# Set up some locales
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
# uncomment these from the config file
sudo sed -i '/fr_FR.UTF-8/s/^# //g' /etc/locale.gen
sudo sed -i '/ja_JP.UTF-8/s/^# //g' /etc/locale.gen
sudo locale-gen
EOF
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
# Install kcov for test coverage
# This doesn’t run coverage over the xtests so it’s less useful for now
if ENV.key?('INSTALL_KCOV')
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
test -e ~/.cargo/bin/cargo-kcov \
|| cargo install cargo-kcov
sudo apt-get install -qq -o=Dpkg::Use-Pty=0 -y \
cmake g++ pkg-config \
libcurl4-openssl-dev libdw-dev binutils-dev libiberty-dev
cargo kcov --print-install-kcov-sh | sudo sh
EOF
end
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
end
Reference in New Issue Copy Permalink