Czy kolorowe wyjście może być przechwycone przez przekierowanie powłoki? [duplikat]

Przekierowanie nie powoduje rozbierania kolorów, ale wiele poleceń wykrywa, kiedy wysyłają dane wyjściowe do terminala, a jeśli nie, domyślnie nie generuje kolorów. Na przykład, w Linuksie ls --color=auto (który jest aliasowany do zwykłego ls w wielu miejscach) nie będzie generował kodów kolorów, jeśli zostanie wysłany do rury lub pliku, ale ls --color będzie. Wiele innych narzędzi ma podobne flagi nadpisywania, aby zmusić je do zapisania kolorowych danych wyjściowych do pliku, ale wszystko jest specyficzne dla danego narzędzia.

Nawet gdy masz kody kolorów w pliku, aby je zobaczyć, musisz użyć narzędzia, które pozostawia je nienaruszone. less posiada flagę -r do wyświetlania danych pliku w trybie "raw"; wyświetla kody kolorów. edit: nieco nowsze wersje mają również flagę-r, która jest szczególnie świadoma kodów kolorów i wyświetla je poprawnie, z lepszym wsparciem dla rzeczy takich jak owijanie/przycinanie linii niż tryb raw, ponieważ mniej może powiedzieć, które rzeczy są kodami kontrolnymi, a które faktycznie są znakami przechodzącymi na ekran.

Niektóre programy usuwają koloryzację, gdy zdają sobie sprawę, że wyjście nie jest TTY (tj. gdy przekierowujesz je do innego programu). Możesz powiedzieć niektórym z nich, aby używali kolorów na siłę, i powiedzieć pagerowi, aby włączył koloryzację, na przykład użyj less -R

Odkryłem, że używanie script do zachowania kolorów podczas rurociągu do less naprawdę nie działa (less jest cały popaprany, a przy wyjściu bash jest cały popaprany), ponieważ less jest interaktywny. script wydaje się, że naprawdę psuje wejście pochodzące z stdin nawet po wyjściu.

Więc zamiast biegać:

script -q /dev/null cargo build | less -R

Przekierowuję /dev/null do niego przed orurowaniem do less:

script -q /dev/null cargo build < /dev/null | less -R

Więc teraz script nie zadziera z stdin i dostaje dokładnie to, czego chcę. Jest odpowiednikiem command | less, ale zachowuje kolory, jednocześnie kontynuując czytanie nowej zawartości dołączonej do pliku(inne metody, które próbowałem, nie zrobiłyby tego).

Zainspirowany innymi odpowiedziami, zacząłem używać script. Musiałem użyć -c, aby go uruchomić. Wszystkie inne odpowiedzi, w tym tee, różne przykłady script nie działały dla mnie.

Kontekst:

• Ubuntu 16.04
• Uruchamianie testów zachowania z behave i uruchamianie komend powłoki podczas testu z subprocess.check_call()

Rozwiązanie:

script --flush --quiet --return /tmp/ansible-output.txt --command "my-ansible-command"

Wyjaśnienie dla przełączników:

• --flush było potrzebne, ponieważ w przeciwnym razie wyjście nie jest dobrze widoczne na żywo, przychodzi w dużych kawałkach
• --quiet wyłącza własne wyjście narzędzia skryptowego
• -c, --command bezpośrednio dostarcza polecenie do wykonania, przekierowanie z mojego polecenia do skryptu nie działało dla mnie (brak kolorów)
• --return aby skrypt propagował kod wyjścia mojego polecenia, abym wiedział, czy moje polecenie nie powiodło się

To pytanie na superuser pomogło mi, gdy moja inna odpowiedź (z udziałem tee) nie zadziałała. Polega ona na użyciu unbuffer, aby Komenda myślała, że działa z powłoki.

Zainstalowałem go używając sudo apt install expect tcl zamiast sudo apt-get install expect-dev.

Musiałem użyć tej metody podczas przekierowywania wyjścia apt, Jak na ironię.

Używam tee: przekieruj wyjście polecenia do teefilename i utrzyma kolor. A jeśli nie chcesz widzieć wyjścia na ekranie (do czego służy tee: wyświetlanie i przekierowywanie wyjścia w tym samym czasie), po prostu wyślij wyjście tee do /dev/null:

command| teefilename> /dev/null