Невозможно войти в систему или ssh пользователю Cygwin, не являющемуся администратором, в этом месяце, но может в прошлом месяце и все еще может для другого пользователя, не являющегося администратором.
Первое - неуклюжий взлом, второе - распространенная ошибка.
Эти два теста делают что-то совершенно разное, что дает одинаковый результат.
если тест! $ (которые заваривают); then
Это проверяет, является ли вывод из , который пивоваренный пуст.
- Если
brewнаходится на пути поиска, тоwhich brewпроизводит слово вывода, поэтому командаtestполучает два аргумента:!и путь кbrew. Когдатестимеет два аргумента, первый из которых -!, он возвращает истину, если второй аргумент пуст (что здесь не так), и ложь в противном случае. - Если
brewне находится на пути поиска, то выводwhich brewпуст, поэтому командаtestполучает единственный аргумент, который!, поэтомуtestвозвращает true.
Обратите внимание, что эта команда выдаст сообщение об ошибке и статус сбоя, если путь к brew содержит пробелы, потому что это то, что означает подстановка команды без кавычек . Так получилось, что здесь желаемым результатом был статус отказа, так что это работает окольным путем.
Эта команда не проверяет код выхода , который заваривает . Код выхода игнорируется.
если! который варят> / dev / null; then
Это простой способ проверить, успешно ли which brew . Он не зависит ни от чего хрупкого, кроме , который сам .
который brew всегда вызывается в обоих случаях. Какое значение имеет перенаправление вывода на / dev / null ? «Скрыть вывод этой команды» не означает «не запускать эту команду».
Правильный способ проверить, недоступен ли brew в пути поиска команд, - это
if ! type brew >/dev/null 2>/dev/null; then
См. Почему бы не использовать "which"? Что тогда использовать?
После дальнейшего исследования ( здесь и здесь ) я склонен думать, что проблема НЕ в Cygwin а с Windows 10. В моей голове загорелась лампочка, когда я вчера был в учетной записи Windows User2 и заметил, что могу запускать диспетчер задач без запроса UAC - то, что, как я знал, User1 всегда предлагал после обновления Windows 10 из Windows 8 (несмотря на то, что это обновление произошло почти год назад во время акции бесплатного обновления до Win 10). Я подумал, что это Windows 10, и никогда не думал дважды. Когда я понял, что это происходит без подсказок для User2, и поискал обходные пути в Google, чтобы исправить это для User1, я обнаружил, что могу использовать тот же обходной путь для проблемы User1 Cygwin. Он по-прежнему не отвечает, как учетная запись User1 была испорчена в первую очередь, и как на самом деле исправить это правильным способом, но я доволен этим решением, поскольку теперь я могу внести свои изменения git для User1.
TL; DR
ДОПОЛНИТЕЛЬНАЯ РАБОТА:
- Откройте командную строку (CMD.EXE) и установите эту переменную, чтобы прекратить получение всплывающего приглашения UAC:
set __compat_layer=runasinvoker
- С того же терминала переменная среды была установите, запустите Cygwin:
c:\cygwin64\bin\mintty.exe
- Чтобы сделать это постоянным для этого пользователя (и снова заставить значок на рабочем столе работать)
setx __compat_layer "runasinvoker"
- Чтобы сделать это постоянным для всех пользователей на всей машине, откройте командную строку администратора, затем:
setx /m __compat_layer "runasinvoker"
- И наконец, чтобы получить доступ к git без исправления Cygwin, установите «Git Bash».
Предостережение: Поскольку учетная запись User1 все еще технически сломана, я все еще не могу использовать ssh для входа в систему, но я могу хотя бы добраться до локального терминала Cygwin как User1.Кроме того, этот обходной путь не исправляет возможность изменять переменные пользовательской среды Windows User1 через графический интерфейс sysdm.cpl (по-прежнему получать приглашение UAC, а затем показывать только переменные ENV администратора вместо User1), но это что-то для связанного с Windows форума Stack Exchange. что я знаю, что это проблема с учетной записью Windows, а не с Cygwin. А SETX позволяет изменять пользовательские и машинные переменные ENV из командной строки.