Kiedy należy używać kolorów w aplikacji wiersza polecenia?

Obecnie mam aplikację wiersza polecenia w języku C o nazwie btcwatch. Ma -Copcję, którą może otrzymać jako argument, który porównuje aktualną cenę Bitcoin z ceną, która była wcześniej przechowywana -S. Przykładowe dane wyjściowe z tą opcją to:

$ btcwatch -vC  # -v = verbose
buy: UP $ 32.000000 USD (100.000000 -> 132.000000)
sell: UP $ 16.000000 USD (100.000000 -> 116.000000)

Dylemat polega na tym, czy użyć koloru dla łańcucha UPlub DOWNłańcucha (odpowiednio zielony i czerwony). Większość aplikacji wiersza poleceń, które znam (oprócz git), z dala od koloru w swoich wynikach. W moim pragnieniu, btcwatchaby wyglądać i być „standardowym” (używaniem getopt, Makefile itp.), Nie jestem pewien, czy kolor wyglądałby nie na miejscu w tej sytuacji.

— Marco Scannadinari
źródło

git ma kolor na wyjściu? Czy po prostu jeszcze nie natrafiłem na poszczególne polecenia, które to robią?

— Izkata,

Świetne odpowiedzi poniżej. Ale zawsze pamiętaj o kolorowaniu, że niebanalna część twoich użytkowników nie będzie w stanie odróżnić różnicy między kolorem czerwonym a zielonym.

— Ross Patterson

Izkata: git diff, git pull, itd.

— Marco Scannadinari

@Izkata Tak, git można skonfigurować tak, aby używał kolorów w danych wyjściowych .

— Andres F.,

@marcoms Te nie mają dla mnie kolorów. Nie wykonałem jednak żadnych specjalnych konfiguracji, aby to umożliwić.

— Izkata

Odpowiedzi:

Właściwe jest, aby kolorowanie było opcjonalne, domyślnie „wyłączone” i sterować nim za pomocą flagi wiersza polecenia. W ten sposób nie ma to wpływu na ludzi, którzy go nie lubią lub których terminal go nie obsługuje, którzy lubią to, a także osoby, które naprawdę lubią to, mogą zdefiniować alias lub skrót, aby wstępnie zdefiniować opcję. Wszyscy są szczęśliwi.

— Kilian Foth
źródło

Jest to funkcja ls( ls --colorwymagana jest opcja, aby ją włączyć).

@MichaelT: Naprawdę? Myślę, że to zależy od używanej dystrybucji. Wyjście (prawie) zawsze ma kolor i nigdy nie określam --color.

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner BSD smak. /bin/lsjest gładki, /bin/ls -Gjest kolorowy (chociaż jeśli w środowisku zdefiniowano CLICOLOR, ta opcja działa domyślnie). W dystrybucjach wpływających na GNU widać --colori powiązane z nim zmienne środowiskowe.

Świetna odpowiedź na „Czy kolor powinien być obowiązkowy, czy nie”, tym bardziej dla „kiedy jest to właściwe” :)

— Michael Durrant,

@FrustratedWithFormsDesigner na Ubuntu, na przykład, alias ls='ls --color=auto'jest w domyślnym .bashrc(lub jeśli nie już, to jednak gdzieś około 8,04 lub dać rocznie, a ja właśnie przeprowadza moje .bashrc całej instalacji)

— Izkata

Uznałbym za stosowne użycie koloru, gdy:

Istnieją „grupy” przedmiotów, a grupy kolorów pomogą wizualnie pogrupować przedmioty.
Istnieją pola pól „etykieta: wartość” i chcesz, aby etykiety (lub wartości) wyróżniały się.
Są przedmioty, które powinny być wyświetlane w kolorze czerwonym / zielonym, np. Stop / go, good / bad itp.
Większość informacji stanowi tło, ale jeden kluczowy element powinien się wyróżniać.

— Michael Durrant
źródło

Innym ważnym czynnikiem, który należy wziąć pod uwagę, jest to, że kolorowanie, w zależności od platformy, może dodawać sekwencje specjalne znaków. W przypadku kompilacji na tych platformach Jeśli bieżącym / domyślnym trybem jest kolor wyjściowy, zwyczajowo wykrywane jest, czy wyjściem programu jest PIPE, a jeśli tak, to kolor usuwania.

Jest tak, aby sekwencje specjalne koloru nie wyrzucały dalszych programów, które czytają jego dane wyjściowe.

— Preet Kukreti
źródło

dobra uwaga, przypuszczam, że wdrożenie --colour(lub --no-colour) opcji będzie bardziej przyjazne dla takich programów

— Marco Scannadinari,