Как стать автором
Обновить

Комментарии 47

Они еще и копипасту в cmd сделали нормальную, и ресайз, и цвета и воообще удивляют.

Вы имеете в виду Ctrl+Insert / Shift+Insert? Несколько месяцев когда попробовал, вставка только ПКМ работала, что крайне неудобно было.

Ctrl-C/Ctrl-V или right click — все работает. Ctrl+Insert / Shift+Insert никогда до этого не пробовал, но тоже работает.
Странно, но у меня Shift+Insert никак не работает. А без этого шорт-ката совсем неудобно мышкой работать. Только из-за этого по прежнему остаюсь на Cygwin.
Я на ПК обновился, а на ноуте поставил систему с нуля. Так вот, на ПК Ctrl+Insert/Shift+Insert не работает, а на ноутбуке без проблем. Возможно где-то в настройках необходимо включить или переустановка системы.
Копирование по Ctrl-C точно было и в Anniversary, ну и собственно статья, на которую я сослался выше написана в августе 15, когда первая версия 10ки вышла.
За счет изрядкой переработки консоли и доработки WSL в целом, работает такое.
image

Доктор Франкенштейн просто в восторге! Кстати, а сам гуй эмулятора терминала улучшили или он все так-же безнадежно отстал от terminal.app или же gnome-terminal.

Относительно названных не скажу, давно не пользоваляс ими, но субъективно стало комфортней работать. И цвета и отрисовки изменились в лучшую сторону. Выделение, вставка, изменения размеров уже и ранее были. Так что движутся в верном направлении и достаточно плотно работают с пользователями, быстро отвечают на issue в github, на форуме своем.
Вопрос по использованию tmux в windows: Как заставить работать горячие клавиши для создание окон?
У меня работает такой вариант
ctrl-b + c

ну и так далее
Спасибо. Проблема заключалась в отсутствии tmux.conf
Заработало после
cp /usr/share/doc/tmux/examples/screen-keys.conf /etc/tmux.conf

Может кому пригодится.

Bash в Windows 10 добавили еще год назад в
Anniversary Update(Ubuntu 14.04) в Creators Update его доработали и улучшили(Ubuntu 16.04)

И добавили то, о чём тут речь — запуск виндовых программ и скриптов
Вопрос от ламера: а почему первый вариант нельзя было сделать на PS, а не ждать баша?
вот, к примеру, выгружают метаданные всех фоточек в папке в CSV https://blogs.technet.microsoft.com/heyscriptingguy/2014/02/06/use-powershell-to-find-metadata-from-photograph-files/
Забыл поблагодарить за ссылку.

Посмотрю не является ли это вариантом одного из моих двух методов и, если нет, задействую и его.
Потребность в массовой проверке версий программ появилась этой зимой, а тогда уже было известно что в весеннем обновлении будет возможность запуска exe-файлов из баша.

Поэтому я сперва сделал решение из двух файлов запускаемых по очереди и стал ждать нужного мне обновления обновления.
Эм вы как-то странно ответили на мой вопрос.
В чем пеимущество запуска на винде из баша пхпскрипта, который запускает cmd, который запускает виндовую тулзу перед скриптом в PS?
Я ответил на вопрос про ту часть где «не ждать», сорри.

В чем пеимущество запуска на винде из баша пхпскрипта, который запускает cmd, который запускает виндовую тулзу перед скриптом в PS?

В моём случае — в унифицированности.

Я для своих нужд делаю всякие разные скриптики для мелких задач.

Они все используют одни и теже общие папки, одни и теже общие базы, одни и те же общие функции.
Часть из них лезет на сервер, берёт исходные данные, что-то делает и возвращает на сервер результат.

И если они все «sh + php», то пусть и этот будет «sh + php». Чисто для простоты использования и обслуживания.

А иначе, если девять будут а BASH, а десятый в PowerShell, то есть вероятность что я на этого «десятого» забью и не буду использовать.

ну, т.е, вы могли бы из баша PS скрипт запускать, а не городить цепочки?
Если цель состоит в ручной проверке единственного файла — да

Но задача, как и написано выше, состоит в проверке множества файлов расположенных на разных сайтах.

В итоге:
— список проверяемых ссылок составляется php и хранится в mysql
— выкачивает файлы — wget
— результат обрабатывается php (нужно сравнить) и хранится в mysql + формируется отчёт

То есть, цепочка уже есть, просто часть её работы выполнял bat файл с wmic внутри. И он запускался отдельно.

Теперь этот функционал встроен прямо в php скрипт.

Ок, так это приобретает смысл.
Вобщем, если совсем коротко, то преимущество организационное, а не техническое

А вот это уже типичный EEE, сейчас вырастет куча скриптов, которые закладываются на особенности WSL и в особенности на виндовые бинарники, а потом вылезут сложности с их портированием на Linux.
То есть чисто практически фича конечно полезная, но если все начнут ей злоупотреблять, то получится франкенштейн, которого потом даже при помощи wine'а не запустишь нигде.
Впрочем, с другой стороны, теперь можно чисто видновые проблемы решать при помощи WSL.


Думаю, что открытие кода некоторых подсистем Windows сняло бы все такие сомнения и вопросы.

В большей степени интересно как этими возможностями воспользуются IDE строители, в принципе ничего не мешает организовать бесшовную интеграцию лишь поправив код запуска консольных команд.

Зачем использовать абсолютные пути? Переменные окружения спасут вас от потенциальных проблем.

Зачем использовать абсолютные пути?

Для подстраховки.
Когда вручную запускаю, то знаю из какогой папки, а когда из скрипта, то я лучше ВСЁ напишу в абсолютных путях, чем он сам хватанёт не оттуда

А так bash подцепляет переменные из Windows и при набранном trace по табу выводит варианты из обоих миров

~$ trace
tracepath            tracepath6           traceroute6          traceroute6.iputils  tracerpt.exe
насколько там честный линукс и можно ли на него взгромоздить Докера

Docker, установленный на винду «нативно», из баша не запустился. Хотя, возможно я не учел тот факт, что под виндой бинарник докера может называться docker.exe. Если так, то создание соответствующего alias в баше может помочь.
Тем, кто всё же считает эмулятор терминала в винде убогим, рекомендую попробовать ConEmu — хотя бы есть вкладки, профили, quake-режим с выдвигающейся по хоткею консоли, цвета получше настраиваются, да и вообще.

Лично я поставил себе дефолтной оболочкой в нём как раз bash — тогда под рукой всегда есть ssh, cURL, vim и всё остальное.
Спаситель!
После guake дико корёжило переключение на теминал под винде кликом/альт-табом.
А теперь — каеф :)

В чем смысл запуска wmic.exe через cmd.exe? Почему нельзя запустить его напрямую?

в этом смысла нет, это косяк :(

Увлёкся механическим переносом строчек из батника и забыл сделать вызов напрямую.

Увидел уже перед публикацией, но решил не исправлять. Типа если кто спросит, то отбрехаюсь мол «это специально иллюстрация того что cmd.exe нужно запускать с ключём /C

Но нет, просто пробакланил. Сорри.

P.S. Если что, то он не wmic.exe, а WMIC.exe.
Для описываемых применений можно использовать Cygwin — POSIX user-space в Windows с набором софта практически как в обычном Linux-дистрибутиве. Проекту уже «как сто лет в обед» и всякие заморочки со взаимодействием с Windows-миром пройдены и переварены, достаточно большое коммюнити пользователей, ведется при поддержке Redhat.

И да, там можно запустить X-сервер для GUI-программ или c целым десктопом как XFce/LXDE, или даже, например, из bash с помощью имеющегося в пакетах mingw-w64 скомпилировать нативную Windows-программу (не связанную с библиотекой Cygwin-POSIX), и, разумеется, запустить её, и например распарсить её консольный вывод с помощью unix-утилит или любого другого инструментария (типа PHP) в bash. :)



Я думаю, что мои задачи мог бы решить и windows-версия php, но… ощущения не те

И цигвин как то пробовал — не встаёт.
То есть цигвин то у меня встаёт, а вот у меня на цигвин — нет.
Не получается повторить второй пример, с печатью

$ 2Printer.exe -s "c:\2Printer\_input\*.*"


В wsl выполнилось, в cygwin висит и ничего не происходит.

Если без параметров, то работает

$ 2Printer.exe
 2Printer, Version 5.3, ▒ fCoder SIA 2017


-?, -help       - display usage information
-s              - set source path for printing
                  for example -s "c:\my folder\*.doc"


Там есть какие-нибудь особенности синтаксиса или ввода путей?
$ 2Printer.exe -s "c:\2Printer\_input\*.*"


Там есть какие-нибудь особенности синтаксиса или ввода путей?

Ну да.
Кстати в bash-шелле строка в двойных кавычках считается экранированной. И "*.*" не расширяется в список файлов. См. man bash раздел QUOTING. Не понятно вообще почему в WSL-bash это сработало.
Так что в Cygwin скорей всего надо так:

$ 2Printer.exe -s /cygdrive/c/2Printer/_input/*


Вот кстати пример того что майкрософт что-то намудрило с попыткой скрестить ужа и ежа.
У Вас на скриншоте тоже виндовые пути указаны.

Перебирал и юникосвые пути и двойные слэши. Не помогает.
Печалька

Есть идея — версия триальная и не срабатывает в месте запроса «выберите вариант»

Завтра попрошу у коллег серийник и попробую на лицензионной копии.

Спасибо за наводку
Не, для 2Printer.exe я просто на автомате пути перебил не зная ничего об этой проге.

Сейчас скачал установил — это же виндовая прога и все что ей нужно просто дать строку во входном параметре не затронутую bash-шеллом, дальше она её сама разбирает.

Причина зависания что она хочет именно виндовую консоль и не работает в эмуляторе терминала mintty.exe. В директории установки Cygwin должен быть Cygwin.bat — он запустит bash в виндовой консоли. Из под неё все работает.


А в терминале mintty.exe только через запуск нового окна консоли cmd.exe удалось:
$ cmd /c start 2Printer.exe -verbose -pres 'c:\tmp$\pres.txt' -s 'c:\tmp$\tmp.txt'

В отличии от никсов, где звездочки раскрывает шелл, виндовым программам шаблоны имен файлов приходится раскрывать самим. Потому и работает.


Кстати, "намудрили" как раз создатели cygwin. У них программы по-разному получают свои аргументы себя ведут в зависимости от родительского процесса.

Микс из Windows-мира и POSIX-окружения приводит к путаницам — кому где какие пути можно задавать в качестве аргументов или по каким путям будут искаться указанные в командной строке программы.

Пример:
— which (в Cygwin) находит fc как досовскую команду
 $ which fc
/cygdrive/c/Windows/system32/fc

— если в командной строке указать просто fc, то будет вызвана builtin команда bash, которая делает совсем другие вещи, а не досовсая fc.exe
— нужно вызывать указывая точно, что это именно fc.exe
$ fc.exe
FC: Insufficient number of file specifications

— bash-шелл раскрывает шаблон и полученные имена передаются как аргументы досовской программы (т.е. здесь юниксовые пути для файлов из локальной директории прекрасно подходят досовской программе)
$ fc.exe *.log
Comparing files make-1.log and MAKE-2.LOG
FC: no differences encountered

— сама же Windows-программа звездочки в своих параметрах не раскрывает
$ fc.exe "*.log"
FC: Insufficient number of file specifications

— и не понимает пути записанные через прямой слэш (не смотря на то, что в Windows как бы декларируется что для файловых путей прямые слэши допускаются вместо обратных)
$ fc.exe ./make-*.log
FC: cannot open ./MAKE-1.LOG - No such file or folder

$ fc.exe ./make-1.log ./make-2.log
FC: cannot open ./MAKE-1.LOG - No such file or folder

— задаём полный прямой досовский путь к файлам экранируя строки параметров чтобы bash их никак не пытался затрагивать со своими фичами расширения параметров
$ fc.exe 'c:\cygwin.home\Mike\tmp\make-1.log' 'c:\cygwin.home\Mike\tmp\make-2.log'
Comparing files C:\CYGWIN.HOME\MIKE\TMP\make-1.log and C:\CYGWIN.HOME\MIKE\TMP\MAKE-2.LOG
FC: no differences encountered

— вот артефакт — программа не воспринимала ./make-1.log ./make-2.log, а микс параметров с разными способами задания путей проходит (и это не глюк Cygwin, точно так же она ведёт себя при запуске в родном cmd.exe
$ fc.exe 'c:\cygwin.home\Mike\tmp\make-1.log' ./make-2.log
Comparing files C:\CYGWIN.HOME\MIKE\TMP\make-1.log and ./MAKE-2.LOG
FC: no differences encountered


Я никогда не сталкивался в Cygwin с проблемами, связанными с тем, что какие-либо программы запущенные из bash по-разному получают свои аргументы в зависимости от того, из какого родительского процесса они были запущены (термнал mintty, досовская коносль cmd.exe, или в bash запущенном напрямую из проводника Windows).

Разница понятна, но я никогда не ленился писать полные имена файлов и абсолютные пути (где-то тут в комментариях даже вопрос был об этом) и проблему неоднозначности "fc" не чувствуют. Просто потому что неоднозначности для меня нет — одна программа называется fc, а другая fc.exe.


И с параметрами тоже самое. Для меня факт "запускаем любую программу с родными параметрами" является плюсом.


Да, невозможность скормить юниксовые пути виндовой программе иногда затрудняет выстраивание цепочек через пайп, но я могу запустить ЛЮБУЮ[1] консольную программу и она сработает.


То есть, у cygwin очень красиво с путями и параметрами, но на ограниченном количестве программ, а у wsl нужно ежам и ужам прописывать свои параметры, но зато набор инструментов не ограничен специальным репозиторием и специально скомпилированными экзешниками.


Мне нравится иметь именно все доступные программы и за эту возможность я готов платить необходимостью писать одним виндовые пути, а другим юниксовые.


Не спрашивайте зачем оно мне нужно. Пока ещё не знаю. Нужно свыкнуться с наличием таких возможностей. Нужно что бы в голове уложилось "ой, да запусти виндовую консольную утилиту и не парься". И тогда, в нужный момент, это будет использовано.


И в этом ключе, спасибо за идею о возможных проблемах связанных с разницей путей. Рано или поздно я с этим столкнусь и буду к этому готов. Если не технически, то, хотя бы, морально. :)




1 — совершенно некорректное обобщение малого количества экспериментов, но, как прогноз, прокатит.

Cygwin был и остается прекрасной альтернативой почившему в бозе встроенному в Windows SFU/SUA с непонятными версиями программ, и которое в общем нацеливалось на непонятные задачи связанные со взаимодействием Windows-серверов с Unix-серверами, а не на предоставление привычного POSIX-окружения для пользователей Windows.

А теперь, когда макрософт полюбила линукс, WSL не то что бы конкурент Cygwin, а наверное его будущий убийца, если майкрософт захочет.
То что печаталка не сработала, это цигвин не может или у меня руки кривые?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.