starship: Test directory::home_directory fails

I just got this and one other similar test failure when building 0.11.0 on macOS

---- directory::directory_in_root stdout ----
thread 'directory::directory_in_root' panicked at 'assertion failed: `(left == right)`
  left: `"in \u{1b}[1;36m/etc\u{1b}[0m "`,
 right: `""`', tests/testsuite/directory.rs:81:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

---- directory::home_directory stdout ----
thread 'directory::home_directory' panicked at 'assertion failed: `(left == right)`
  left: `"in \u{1b}[1;36m~\u{1b}[0m "`,
 right: `""`', tests/testsuite/directory.rs:19:5


failures:
    directory::directory_in_root
    directory::home_directory

Huh, could have sworn I responded to this earlier…guess I imagined it.

@lilyball We do have such a construct in starship, but it’s only usable in the testing interface (which is good enough for what we need it for).

@chipbuster these two lines were added to the end of the previous output, after the patch:

 DEBUG starship::modules::directory > Found repository root at "/home/francisco/"
 DEBUG starship::modules::directory > Repo folder name is "francisco"

@chipbuster In my case, I do have a Unix FHS, but a combination of sandboxing and an intentionally-garbage HOME folder just means that the paths you’re trying to test don’t exist/aren’t reachable.

In any case, it seems like a legitimate bug that starship module directory --path=/something-that-doesn't-exist will panic regardless of what the filesystem looks like.

@oblitum Thanks, that’s some very useful info. I’m now thinking the error comes from something in the environment that we didn’t anticipate–possibly a difference in how environment variables are used.

Could you run one more test for me? Same deal, but we’re going to patch the code to dump a little more info:

   // line 33 in src/modules/directory.rs
    match &context.repo_root {
        Some(repo_root) if truncate_to_repo => {
            // Contract the path to the git repo root
            log::debug!("Found repository root at {:?}", repo_root);
            let repo_folder_name = repo_root.file_name().unwrap().to_str().unwrap();
            log::debug!("Repo folder name is {:?}", repo_folder_name);
            dir_string = contract_path(current_dir, repo_root, repo_folder_name);
        }
        _ => {
            // Contract the path to the home directory
            let home_dir = dirs::home_dir().unwrap();
            log::debug!("Contracting to home_dir: {:?}", home_dir);

            dir_string = contract_path(current_dir, &home_dir, HOME_SYMBOL);
        }
    };

Replace the block starting with match &context.repo_root (on line 33 in src/modules/directory.rs) with that, then rerun cargo build and the same test (starship module directory + logs) as before.

If you prefer .patch files, I’ve put one up on Box.

Actually maybe it does; in Nix I’m building in a sandboxed environment, and providing an invalid path to the --path parameter produces a similar exception. I bet the sandbox is preventing access to /etc:

$ RUST_LOG=trace HOME=/homeless-shelter target/x86_64-apple-darwin/release/starship module directory --path=/etdf
 DEBUG starship::config > STARSHIP_CONFIG is not set
 DEBUG starship::config > Using default config path: /homeless-shelter/.config/starship.toml
 DEBUG starship::config > Unable to read config file content: 
No such file or directory (os error 2)
thread 'main' panicked at 'Unable to read current directory: /etdf', src/context.rs:61:17
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.