РЕДАКТИРОВАТЬ:
Я хотел бы дать рекомендацию, что синтаксический анализ цветов - это вообще непродуманная идея.
Часть того, почему я хотел, было так, чтобы я мог и проанализировать и передать это в своем собственном выводе сценария. Это... хорошо, но, возможно, было бы разумнее использовать фарфор или что-то подобное и самостоятельно восстанавливать цветные детали!
Оригинальный вопрос следует.
Мне нравится видеть цвет, потому что мои сценарии достаточно надежны (пока) для обработки цветовых кодов. Похоже, что я иду против этого, но я, честно говоря, не понимаю, в чём заключается смысл разбора таких вещей, как escape-коды в скриптах. Если цвета помогают для интерактивного использования, почему они не помогают в использовании сценариев, где я могу собирать данные и обрабатывать даже больше данных, чем вручную? Разве цвета не будут еще важнее?
Во всяком случае, у меня есть аккуратный небольшой сценарий оболочки, который я написал, который выводит git status, и я просто хочу, чтобы этот сценарий не изменял цвета. Моя глобальная конфигурация git настроена так, что списки измененных и неотслеживаемых файлов отображаются в цвете состояния git. К сожалению, в отличие от git diff, я не могу найти опцию принудительного выбора цвета для git status.
Чтобы быть совершенно ясно, это проблема:
$ git status
производит идеальный вывод, но (выдержка из моего сценария следует)
git status | sed "s/^#/\x1b[34m#[0m/"
не производит цветной вывод git status, и вы даже можете видеть здесь, что я явно преобразую ведущие хеш-символы в синий, потому что это помогает выделить различные области вывода из моего скрипта.
Кто-нибудь знает, как заставить его потушить цвета? Может ли быть стандартная программа, которую я могу использовать, которая может быть использована в качестве "поддельного терминала" канала STDIN/STDOUT? На самом деле я также работаю над pty-псевдотерминальным инструментом, чтобы я мог использовать его для этой цели, но это довольно сложное решение (и пока не готово к использованию, так как я еще не закончил его сборку).
Чтобы избежать изменения конфигурации git, вы можете сделать это только для текущей команды, передав конфигурационную переменную с -c:
git -c color.status=always status | less -REX
Эта переменная предназначена только для команды status. Для diff, show и log переменная color.ui:
git -c color.ui=always diff | less -REX
Обратите внимание, что -c должен быть до аргументом status или diff, а не после.
РЕДАКТИРОВАТЬ:
Я хотел бы настоятельно рекомендовать, чтобы синтаксический анализ цветов был в целом непродуманной идеей.
Часть того, почему я хотел, было так, чтобы я мог и проанализировать и передать это в своем собственном выводе сценария. Это... хорошо, но, возможно, было бы разумнее использовать фарфор или что-то подобное и самостоятельно восстанавливать цветные детали!
Оригинальный ответ следует.
Я продолжаю находить ответы очень быстро после того, как задаю вопросы. Что-то связанное с размышлением о проблеме достаточно долго, чтобы написать ее, чтобы вы сформулировали лучшие подходы к ее решению. Во всяком случае, решение этого просто
git config color.status always
Я полагаю, что решение общего назначения включает в себя expect, или что - то pty, связанное с силой каких - либо программ, которые требуют его, думая, что они находятся на терминале.
У меня была эта же проблема при использовании псевдонима git, который выполняет команду оболочки. По-видимому, оболочка git не наследуется от текущей среды, поэтому она ничего не знает о моих настройках раскраски.
В дополнение к добавлению глобального значения параметра git color ui, я исправил это, сделав мой псевдоним похожим на ниже, его вторичную команду, которая требует, чтобы ей сказали использовать цвета, поскольку git будет по умолчанию по сравнению с 1,8.x версия люди упомянули.
[alias]
ignored = !git ls-files -v|grep --color '^h'
Теперь он генерирует эквивалентный раскрашенный вывод, когда он выполняется как псевдоним, как если бы я только запускал команду.
Для sed этот другой ответ работает более надежно, используйте tput. https://unix.stackexchange.com/a/45954