Comments 47
Вы имеете в виду Ctrl+Insert / Shift+Insert? Несколько месяцев когда попробовал, вставка только ПКМ работала, что крайне неудобно было.
Доктор Франкенштейн просто в восторге! Кстати, а сам гуй эмулятора терминала улучшили или он все так-же безнадежно отстал от terminal.app или же gnome-terminal.
Bash в Windows 10 добавили еще год назад в
Anniversary Update(Ubuntu 14.04) в Creators Update его доработали и улучшили(Ubuntu 16.04)
Поэтому я сперва сделал решение из двух файлов запускаемых по очереди и стал ждать нужного мне обновления обновления.
В чем пеимущество запуска на винде из баша пхпскрипта, который запускает cmd, который запускает виндовую тулзу перед скриптом в PS?
В чем пеимущество запуска на винде из баша пхпскрипта, который запускает cmd, который запускает виндовую тулзу перед скриптом в PS?
В моём случае — в унифицированности.
Я для своих нужд делаю всякие разные скриптики для мелких задач.
Они все используют одни и теже общие папки, одни и теже общие базы, одни и те же общие функции.
Часть из них лезет на сервер, берёт исходные данные, что-то делает и возвращает на сервер результат.
И если они все «sh + php», то пусть и этот будет «sh + php». Чисто для простоты использования и обслуживания.
А иначе, если девять будут а BASH, а десятый в PowerShell, то есть вероятность что я на этого «десятого» забью и не буду использовать.
Но задача, как и написано выше, состоит в проверке множества файлов расположенных на разных сайтах.
В итоге:
— список проверяемых ссылок составляется php и хранится в mysql
— выкачивает файлы — wget
— результат обрабатывается php (нужно сравнить) и хранится в mysql + формируется отчёт
То есть, цепочка уже есть, просто часть её работы выполнял bat файл с wmic внутри. И он запускался отдельно.
Теперь этот функционал встроен прямо в php скрипт.
А вот это уже типичный EEE, сейчас вырастет куча скриптов, которые закладываются на особенности WSL и в особенности на виндовые бинарники, а потом вылезут сложности с их портированием на Linux.
То есть чисто практически фича конечно полезная, но если все начнут ей злоупотреблять, то получится франкенштейн, которого потом даже при помощи wine'а не запустишь нигде.
Впрочем, с другой стороны, теперь можно чисто видновые проблемы решать при помощи WSL.
Думаю, что открытие кода некоторых подсистем Windows сняло бы все такие сомнения и вопросы.
Зачем использовать абсолютные пути? Переменные окружения спасут вас от потенциальных проблем.
Для подстраховки.
Когда вручную запускаю, то знаю из какогой папки, а когда из скрипта, то я лучше ВСЁ напишу в абсолютных путях, чем он сам хватанёт не оттуда
А так bash подцепляет переменные из Windows и при набранном trace по табу выводит варианты из обоих миров
~$ trace
tracepath tracepath6 traceroute6 traceroute6.iputils tracerpt.exe
насколько там честный линукс и можно ли на него взгромоздить Докера
Docker, установленный на винду «нативно», из баша не запустился. Хотя, возможно я не учел тот факт, что под виндой бинарник докера может называться docker.exe. Если так, то создание соответствующего alias в баше может помочь.
Лично я поставил себе дефолтной оболочкой в нём как раз bash — тогда под рукой всегда есть ssh, cURL, vim и всё остальное.
В чем смысл запуска wmic.exe
через cmd.exe
? Почему нельзя запустить его напрямую?
Увлёкся механическим переносом строчек из батника и забыл сделать вызов напрямую.
Увидел уже перед публикацией, но решил не исправлять. Типа если кто спросит, то отбрехаюсь мол «это специально иллюстрация того что cmd.exe нужно запускать с ключём /C „
Но нет, просто пробакланил. Сорри.
P.S. Если что, то он не wmic.exe, а WMIC.exe.
И да, там можно запустить X-сервер для GUI-программ или c целым десктопом как XFce/LXDE, или даже, например, из bash с помощью имеющегося в пакетах mingw-w64 скомпилировать нативную Windows-программу (не связанную с библиотекой Cygwin-POSIX), и, разумеется, запустить её, и например распарсить её консольный вывод с помощью unix-утилит или любого другого инструментария (типа PHP) в bash. :)
И цигвин как то пробовал — не встаёт.
То есть цигвин то у меня встаёт, а вот у меня на цигвин — нет.
$ 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/*
Вот кстати пример того что майкрософт что-то намудрило с попыткой скрестить ужа и ежа.
Перебирал и юникосвые пути и двойные слэши. Не помогает.
Печалька
Есть идея — версия триальная и не срабатывает в месте запроса «выберите вариант»
Завтра попрошу у коллег серийник и попробую на лицензионной копии.
Спасибо за наводку
Сейчас скачал установил — это же виндовая прога и все что ей нужно просто дать строку во входном параметре не затронутую 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. У них программы по-разному получают свои аргументы себя ведут в зависимости от родительского процесса.
Пример:
— 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 — совершенно некорректное обобщение малого количества экспериментов, но, как прогноз, прокатит.
А теперь, когда макрософт полюбила линукс, WSL не то что бы конкурент Cygwin, а наверное его будущий убийца, если майкрософт захочет.
Bash on Windows: практические опыты по скрещиванию ежей и ужей