Bash on Windows: практические опыты по скрещиванию ежей и ужей

Может они выключены по какой-то причине? https://www.cnet.com/how-to/new-windows-10-keyboard-shortcuts-for-the-command-prompt/

Я на ПК обновился, а на ноуте поставил систему с нуля. Так вот, на ПК Ctrl+Insert/Shift+Insert не работает, а на ноутбуке без проблем. Возможно где-то в настройках необходимо включить или переустановка системы.

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

Не, для 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'

Микс из 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).