Hoe werkt een wc-programma en hoe maak je het in Rust?

In deze hoofdstukuitdaging ga je een versie van het klassieke wc-programma maken, dat zijn oorsprong vindt in de eerste versie van AT&T Unix. Dit programma toont het aantal regels, woorden en bytes van tekst die van STDIN of één of meer bestanden afkomstig zijn. Ik gebruik het vaak om het aantal regels te tellen die door een ander proces worden geretourneerd. Dit is wat je leert in dit hoofdstuk:

• Gebruik de functie Iterator::all

• Maak een module voor eenheidstests

• Simuleer een bestandshandle voor testen

• Formatteer en print voorwaardelijk een waarde

• Compileer een module voor testen met voorwaardelijke compilatie

• Verdeel een tekstregel in woorden, bytes en karakters

Hoe werkt wc?

Om te begrijpen wat er van je verwacht wordt, begin ik met uitleggen hoe het wc-programma werkt. Dit komt uit de BSD-manpagina van wc. De basisfunctionaliteit van het programma is als volgt:

• Het wc-programma toont het aantal regels, woorden en bytes die in elk ingevoerd bestand staan, of standaardinvoer (indien geen bestand is opgegeven).

• Een regel wordt gedefinieerd als een reeks tekens, begrensd door een lijn-einde teken (zoals \n).

• Een woord wordt gedefinieerd als een reeks tekens, begrensd door witruimtes. Witruimtes omvatten spaties, tabs en nieuwe regels.

Er zijn verschillende opties die je kunt gebruiken:

• -c: Geeft het aantal bytes in elk invoerbestand weer.

• -l: Geeft het aantal regels weer.

• -m: Geeft het aantal karakters weer (voor systemen die meerdere bytes per karakter gebruiken).

• -w: Geeft het aantal woorden weer.

Standaard geeft het programma de drie waarden weer: regels, woorden en bytes.

Voorbeelden van wc in actie

Stel je voor dat je drie verschillende tekstbestanden hebt:

1. empty.txt: een leeg bestand.

2. fox.txt: een bestand met één regel tekst en verschillende spaties en een tab.

3. atlamal.txt: een bestand met het eerste vers van "Atlamál hin groenlenzku", een Oudnoords gedicht.

Als je wc uitvoert op een leeg bestand, wordt het volgende geretourneerd:

bash
Copy code
$ wc tests/inputs/empty.txt

0       0       0       tests/inputs/empty.txt

Dit betekent dat er 0 regels, 0 woorden en 0 bytes in het bestand staan.

Voor een bestand als fox.txt, dat een enkele regel bevat met verschillende tussenruimtes, krijg je:

bash
Copy code
$ wc tests/inputs/fox.txt
1       9       48      tests/inputs/fox.txt

Dit betekent dat er 1 regel, 9 woorden en 48 bytes in het bestand staan.

Bijvoorbeeld, een bestand als atlamal.txt bevat veel Unicode-tekens die meerdere bytes vereisen. Als je het commando wc uitvoert, krijg je:

bash
Copy code
$ wc tests/inputs/atlamal.txt

4       29      177     tests/inputs/atlamal.txt

Dit geeft aan dat er 4 regels, 29 woorden en 177 bytes zijn.

Je kunt ook specifieke informatie opvragen met de verschillende vlaggen. Wil je bijvoorbeeld alleen het aantal regels, gebruik dan de -l optie:

bash
Copy code
$ wc -l tests/inputs/atlamal.txt
4       tests/inputs/atlamal.txt

Op dezelfde manier kun je de andere statistieken opvragen, zoals het aantal woorden (-w) of het aantal bytes (-c).

Implementatie in Rust

In Rust kun je een dergelijk wc-programma maken door gebruik te maken van de kracht van iterators en filehandles. Het idee is om elke invoerlijn te lezen, deze op te splitsen in woorden, bytes of karakters en vervolgens de nodige tellers bij te houden. De BufRead::read_line methode kan worden gebruikt om regels te lezen en de Iterator::all functie helpt je om te controleren of een iteratie volledig is.

Daarnaast moet je de mogelijkheid implementeren om een bestandshandle te "faken" voor testen. Dit kan door het gebruik van een MockFile of door een module te maken die alleen beschikbaar is tijdens het testen met #[cfg(test)].

Wat is belangrijk om te begrijpen?

Verder moet je goed begrijpen hoe de as-operator werkt in Rust bij typeconversies, vooral wanneer je met verschillende typen (zoals u64 naar usize) werkt. Dit kan verwarrend zijn, maar met wat oefening en geduld zal het uiteindelijk logisch worden.

Een belangrijk concept om op te merken is hoe het programma omgaat met bestandspaden en het verschil tussen lezen van standaardinvoer en het openen van fysieke bestanden. Door dit goed te begrijpen, kun je je programma zowel flexibel als robuust maken.

Hoe om te gaan met voorwaardelijke compilatie en bestandsverwerking in Rust

In de testdirectory "tests/expected" vinden we paren van bestanden voor elke test. Dit betekent dat de test "name_a" twee mogelijke uitvoerbestanden heeft: een voor Unix en een voor Windows. Dit is te zien in de volgende bestandspaden:

bash
Copy code
$ ls tests/expected/name_a.txt*
tests/expected/name_a.txt
tests/expected/name_a.txt.windows

De test "name_a" is gedefinieerd als volgt:

rust
Copy code
#[test] 

fn name_a() -> Result<()> {     

    run(&["tests/inputs", "-n", "a"], "tests/expected/name_a.txt")

}

De functie run maakt gebruik van de functie format_file_name om de juiste bestandsnaam te creëren. Hierbij wordt gebruik gemaakt van voorwaardelijke compilatie om te bepalen welke versie van de functie gecompileerd wordt, afhankelijk van het besturingssysteem. Dit wordt bereikt door de annotaties #[cfg(windows)] en #[cfg(not(windows))].

Voor Windows wordt de volgende versie van de functie gebruikt om ".windows" toe te voegen aan de verwachte bestandsnaam:

rust
Copy code
#[cfg(windows)] 

fn format_file_name(expected_file: &str) -> Cow {
    format!("{}.windows", expected_file).into()
}

Wanneer de code niet op Windows wordt gecompileerd, wordt deze versie gebruikt, waarbij de originele bestandsnaam wordt teruggegeven:

rust
Copy code
#[cfg(not(windows))] 

fn format_file_name(expected_file: &str) -> Cow {     
    expected_file.into()
}

Verder wordt de test unreadable_dir geïllustreerd, die alleen op niet-Windows-platformen draait:

rust
Copy code
#[test] 
#[cfg(not(windows))] 

fn unreadable_dir() -> Result<()> {     

    let dirname = "tests/inputs/cant-touch-this";      
    if !Path::new(dirname).exists() {         
        fs::create_dir(dirname)?;     
    }     
    std::process::Command::new("chmod")          
        .args(&["000", dirname])         
        .status()         
        .expect("failed");     
    let cmd = Command::cargo_bin(PRG)?          
        .arg("tests/inputs")         
        .assert()         
        .success();     
    fs::remove_dir(dirname)?;      
    let out = cmd.get_output();      
    let stdout = String::from_utf8(out.stdout.clone())?;     

    let lines: Vec<&str> = stdout.split("\n").filter(|s| !s.is_empty()).collect();     

    assert_eq!(lines.len(), 17);      
    let stderr = String::from_utf8(out.stderr.clone())?;      
    assert!(stderr.contains("cant-touch-this: Permission denied"));     
    Ok(()) 
}

Naast het implementeren van dergelijke testcases, kunnen we verder gaan door andere handige functies toe te voegen, zoals de -max_depth en -min_depth opties, die bepalen hoe diep het programma in de directorystructuur moet zoeken. De WalkDir::min_depth en WalkDir::max_depth opties kunnen hierbij van pas komen.

Een andere interessante uitbreiding zou zijn om bestanden te vinden op basis van hun grootte. Het find-programma maakt gebruik van een specifieke syntaxis om bestanden te zoeken die kleiner, groter of exact gelijk zijn aan een opgegeven grootte:

bash
Copy code
-size n[ckMGTP]

Waarbij n een numerieke waarde is en de eenheid een van de volgende kan zijn: kilobytes (k), megabytes (M), gigabytes (G), terabytes (T), of petabytes (P).

Het find-programma kan ook actie ondernemen op de resultaten, bijvoorbeeld met de optie -delete, waarmee lege bestanden kunnen worden verwijderd:

bash
Copy code
$ find . -size 0 -delete

Een andere uitdaging zou kunnen zijn om een optie -count toe te voegen die aangeeft hoeveel items er zijn gevonden, zoals we eerder hebben gedaan met uniq -c. Dit zou een interessante toevoeging zijn aan het programma.

bash
Copy code
$ tree -P "*.csv"

Tot slot kan het nuttig zijn om je versie van het programma te vergelijken met fd, een andere Rust-implementatie van een vervanger voor find, om te zien hoe anderen dezelfde problemen hebben opgelost.