Fixes Windows compilation

[colindean]

This works, although I'm not sure if it's the best way to do it.

Fixes #70

[sirwart]

Hmm, it looks like the Windows tests are failing for some reason. From looking at the test I don't see any obvious reasons why it should be failing when it does. Do you have a way to test locally? The only idea I have is that the test files have Unix line endings and not Windows.

[colindean]

I'm seeing tests fail against 9ee96d6 and v0.1.7 on WSL. It's might be a line endings problem but it might be some other escaping problem. I've taken some swings at it but coming up short.

These fail in one_per_line:

aws azure random

These fail in one_per_file:

pem_key private_key

If skip these files, it passes tests.

$ file test/one_per_line/aws
test/one_per_line/aws: ASCII text, with CRLF line terminators

If I run dos2unix on the random file, it passes. Then I ran it on them all, and removed the skip list, and it passed.

I'll bet you can reproduce it locally if you ran unix2dos on the test files.

[colindean]

Here's my kludgy modified test:

    #[test]
    fn no_false_negatives() {
        let skip_list = vec![
            /*"aws",
            "azure",
            //"random",
            "pem_key","private_key"*/];
        for maybe_entry in fs::read_dir("test/one_per_line").unwrap() {
            let entry = maybe_entry.unwrap();
            if skip_list.contains((&entry.path().file_name().unwrap().to_str().unwrap())) {
                continue
            }
            //let contents = fs::read_to_string(entry.path()).unwrap();
            //let actual = contents.matches(LINE_ENDING).count();
            let fh = File::open(entry.path()).unwrap();
            let con = BufReader::new(fh).lines();
            let ac = con.count();


            let res = find_secrets(
                &[entry.path()],
                &[],
                false,
                false,
                BufferWriter::stdout(ColorChoice::Never),
            );

            assert_eq!(
                res.unwrap(),
                ac,
                "{:?}",
                entry.file_name()
            );
        }
        for maybe_entry in fs::read_dir("test/one_per_file").unwrap() {
            let entry = maybe_entry.unwrap();
            if skip_list.contains((&entry.path().file_name().unwrap().to_str().unwrap())) {
                continue
            }
            let res = find_secrets(
                &[entry.path()],
                &[],
                false,
                false,
                BufferWriter::stdout(ColorChoice::Never),
            );
            assert_eq!(res.unwrap(), 1, "{:?}", entry.file_name());
        }
    }

[colindean]

Found it.

Gotta add \r? to the RANDOM_STRING_REGEX

[colindean]

After some more toggling, I'm able to reproduce the failure when pem_key is CRLF but I'm out of steam for tonight.

[colindean]

I've got myself convinced that this is a bug in how ripsecrets or grep_searcher is handling CRLF and d3197e2 has changes that should facilitate debugging. I want to refactor the find_secrets function but I'm holding off until you get a chance to take a look and greenlight what is likely to be really pulling apart that function.