Linux scripting in windows

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

В прилетевшем обновлении Windows 10 Creators Update появилась интереснейшая возможность — запускать виндовые программы в этом их линуксе. Официальные примеры меня категорически не устроили — евангелисты Microsoft предложили мне рисовать корову в PowerShell и запускать Notepad из bash. Чё, правда? Это всё до чего вы додумались?

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

Bash on Windows я использую для всякой мелкой механизации — выкачать, распарсить, проанализировать. Взять 10-20 гигов логов и поколдовать над ними в поисках чего нибудь этакого. Взять 200 гигов исходных данных, сделать ВЖУХ и пульнуть пару мегов результатов в базу сайта. Вобщем, обычная бытовуха, как у всех. Разве нет?

Кейс номер один

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

Имеется некоторое количество веб-сайтов для разных программ, требуется проверить что все ссылки «download» ведут на актуальные версии.

Пропустив этап поиска ссылок и скачивания файлов перейдём к извлечению нужной информации.
Делаем это двумя путями.

Путь первый — обращение к WMIC

В CMD вызов данной информации выглядит вот так:

/VALUE — что бы получить всю возможную информацию

В bash это выглядит вот так

слэшей много и все нужные

Но мне то нужно не просто на экран вывести, а получить и обработать.

Поэтому, в PHP это выглядит вот так:

/mnt/c/Windows/System32/cmd.exe — полный путь, что бы наверняка
$b — результат многострочный, поэтому получаем его в виде массива (в $a попадает лишь последняя строчка)
$ini — формат результата совместим с ini-файлом, грех этим не воспользоваться — превращаем полученный массив $b в текст для последующего преобразования с помощью parse_ini_string().

Путь второй — использование Scripting.FileSystemObject

Данной решение я нашёл здесь и немножко допилил.

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

Я заменил эту строчку на цикл извлекающий ВСЕ возможные свойства файла

формат вывода сделан совместимым с ini-файлом.

PHP код, вызывающий bat-файл, получился вот такой

Почти так же как как в случае с WMI, только приходится перекодировать результат в юникод. ( CP866 — всплакнул )

Склеиваем полученные результаты в единый текст и парсим

Делаем разбиение на секции (второй параметр — true) и во избежании проблем включаем — INI_SCANNER_RAW

ВЖУХ и получаем массив всех возможных свойств файла с которым удобно работать.

Array
(
[WMIC] => Array
(
[AccessMask] => 1179817
[Archive] => TRUE
[Caption] => c:\windows\system32\cmd.exe
[Compressed] => FALSE
[CompressionMethod] =>
[CreationClassName] => CIM_LogicalFile
[CreationDate] => 20170318235750.921718+180
[CSCreationClassName] => Win32_ComputerSystem
[CSName] =>
[Description] => c:\windows\system32\cmd.exe
[Drive] => c:
[EightDotThreeFileName] => c:\windows\system32\cmd.exe
[Encrypted] => FALSE
[EncryptionMethod] =>
[Extension] => exe
[FileName] => cmd
[FileSize] => 271872
[FileType] => Application
[FSCreationClassName] => Win32_FileSystem
[FSName] => NTFS
[Hidden] => FALSE
[InstallDate] => 20170318235750.921718+180
[InUseCount] =>
[LastAccessed] => 20170318235750.921718+180
[LastModified] => 20170318235750.921718+180
[Manufacturer] => Microsoft Corporation
[Name] => c:\windows\system32\cmd.exe
[Path] => \windows\system32\
[Readable] => TRUE
[Status] => OK
[System] => FALSE
[Version] => 10.0.15063.0
[Writeable] => TRUE
)

[FileSystemObject] => Array
(
[Имя] => cmd.exe
[Размер] => 265 КБ
[Тип элемента] => Приложение
[Дата изменения] => 18.03.2017 23:57
[Дата создания] => 18.03.2017 23:57
[Дата доступа] => 18.03.2017 23:57
[Атрибуты] => A
[Автономность] =>
[Доступность] => Доступен автономно
[Распознанный тип] => Приложение
[Владелец] => TrustedInstaller
[Вид] => Программа
[Дата съемки] =>
[Исполнители] =>
[Альбом] =>
[Год] =>
[Жанр] =>
[Дирижер] =>
[Теги] =>
[Оценка] => Без оценки
[Авторы] =>
[Название] =>
[Тема] =>
[Категории] =>
[Комментарии] =>
[Авторские права] => c Microsoft Corporation. All rights reserved.
[№] =>
[Продолжительность] =>
[Скорость потока] =>
[С защитой] =>
[Камера, модель] =>
[Размеры] =>
[Камера, изготовитель] =>
[Организация] => Microsoft Corporation
[Описание файла] => Windows Command Processor
[Ключевые слова образцов] =>
[Имя программы] =>
[Длительность] =>
[В сети] =>
[Повторяется] =>
[Место] =>
[Адреса необязательных участников] =>
[Необязательные участники] =>
[Адрес организатора] =>
[Имя организатора] =>
[Время оповещения] =>
[Адреса обязательных участников] =>
[Обязательные участники] =>
[Ресурсы] =>
[Состояние собрания] =>
[Свободно/Занято] =>
[Общий размер] => 227 ГБ
[Учетная запись] =>
)

)

К чему был весь этот стрёмнокод? А вот к чему.

Как я уже упомянул ранее, на сайте майкрософта поведали, что теперь мы можем рисовать коров в PowerShell и запускать notepad.exe из баша.

А в обсуждении перевода этого майкрософтовского текста люди выясняют насколько там честный линукс и можно ли на него взгромоздить Докера.

Люди, вы не туда смотрите! Я в bash выполнил PHP-скрипт который через exec() запустил bat-файл в котором JScript создал ActiveXObject.

It’s Kind Of Magic!

А ещё я могу из CMD сделать вот так:

Кейс номер два

Обновление Windows 10 Creators Update я накатил 6 числа, а на прошлой недели был отвлечён от новой игрушки бухгалтерией. Бухгалтерия запросила оригиналы первички.

Эврика, подумал я и поставил консольную печаталку

Лезем в bash и просто запускаем программу

Результат — из принтера ползут листочки:

(данный скриншот — последующая имитация на виртуальном принтере, но на реальном HP тоже сработало)

В результате имеем:

• программа проявила интерактивность (триалка запросила нажать кнопочку)
• из башевского окошка полезла по своим виндовым путям
• взяла оттуда файлы с русскими названиями
• вызвала офисный редактор через COM-объекты
• отправила результат на принтер

То есть можно не только писать простейшие скриптики, но и использовать сложные программы.

Резюме

Я ещё не до конца осознал что ещё с этим можно делать, но эта штука может гораздо больше чем просто беседа с коровами и запуск LAMP.

Надо просто самому себе разрешить вырваться из дихотомиии «либо Linux, либо Windows» и начать скрещивать ежей и ужей в самых невероятных пропорциях и последовательностях.

Источник

‼️ 4 способа запустить команды Linux в Windows

Краткое описание: Хотите использовать команды Linux, но не хотите выходить из Windows? Вот несколько способов запуска команд Linux bash в Windows.

Если вы изучаете скрипты оболочки, вероятно, как часть вашей учебной программы, вам нужно использовать команды Linux для практики команд и скриптов.

В вашей школьной лаборатории может быть установлен Linux, но лично у вас нет ноутбука с Linux, а обычный компьютер с Windows, как и у всех.

Ваша домашняя работа должна выполняться с командами Linux, и вы задаетесь вопросом, как запускать команды и скрипты Bash в Windows.

Вы можете установить Linux вместе с Windows в режиме двойной загрузки.

Этот метод позволяет вам выбрать Linux или Windows при запуске компьютера.

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

Вы также можете использовать терминалы Linux онлайн, но ваша работа не будет сохранена.

Хорошая новость заключается в том, что есть несколько способов запуска команд Linux внутри Windows, как и в любом обычном приложении. Разве это не круто?

Использование команд Linux внутри Windows

Как “промоутер” Linux, я бы хотел, чтобы все больше и больше людей использовали «настоящий» Linux, но я понимаю, что иногда это не является приоритетом.

Если вы просто хотите попрактиковаться в Linux, вы можете использовать один из этих методов для запуска команд Bash в Windows.

1. Используйте оболочку Linux Bash в Windows 10

Знаете ли вы, что вы можете запустить дистрибутив Linux внутри Windows 10?

Подсистема Windows для Linux (WSL) позволяет запускать Linux внутри Windows.

В следующей версии WSL будет использоваться настоящее ядро Linux внутри Windows.

Этот WSL, также называемый Bash для Windows, дает вам дистрибутив Linux в режиме командной строки, работающий как обычное приложение Windows.

Не пугайтесь режима командной строки, потому что ваша цель – запускать команды Linux. Это все, что вам нужно.

Вы можете найти некоторые популярные дистрибутивы Linux, такие как Ubuntu, Kali Linux, openSUSE и т. д. В Магазине Windows.

Вам просто нужно скачать и установить его, как любое другое приложение Windows.

После установки вы можете запускать все необходимые вам команды Linux.

2. Используйте Git Bash для запуска команд Bash в Windows

Вы, наверное, знаете, что такое Git.

Это система контроля версий, разработанная создателем Linux Линусом Торвальдсом

Git для Windows – это набор инструментов, который позволяет использовать Git как в командной строке, так и в графических интерфейсах.

Одним из инструментов, включенных в Git для Windows, является Git Bash.

Приложение Git Bash предоставляет и слой эмуляции для командной строки Git.

Помимо команд Git, Git Bash также поддерживает множество утилит Bash, таких как ssh, scp, cat, find и т. д.

Другими словами, вы можете запускать множество общих команд Linux / Bash, используя приложение Git Bash.

Вы можете установить Git Bash в Windows, скачав и бесплатно установив инструмент Git для Windows с веб-сайта:

3. Использование команд Linux в Windows с Cygwin

Если вы хотите запускать команды Linux в Windows, рекомендуется Cygwin.

Cygwin был создан в 1995 году для обеспечения POSIX-совместимой среды, которая изначально работает в Windows.

Cygwin – это бесплатное программное обеспечение с открытым исходным кодом, поддерживаемое сотрудниками Red Hat и многими другими добровольцами.

В течение двух десятилетий пользователи Windows используют Cygwin для запуска и выполнения команд Linux / Bash.

Вы можете скачать Cygwin с официального сайта, который будет показан ниже.

4. Используйте Linux на виртуальной машине

Другой способ – использовать программное обеспечение для виртуализации и установить в него Linux.

Таким образом, вы устанавливаете дистрибутив Linux (с графическим интерфейсом) внутри Windows и запускаете его как обычное приложение Windows.

Этот метод требует, чтобы в вашей системе было достаточно оперативной памяти, по крайней мере, 4 ГБ, но лучше, если у вас более 8 ГБ.

Здесь хорошо то, что вы по-настоящему почувствуете использование настольного Linux. Если вам нравится интерфейс, вы можете позже полностью перейти на Linux.

Существует два популярных инструмента для создания виртуальных машин в Windows: Oracle VirtualBox и VMware Workstation Player.

Вы можете использовать любой из двух. Лично я предпочитаю VMware.

Источник

Опыт настройки и использования WSL (подсистемы Linux в Windows 10)

К написанию данной статьи меня побудил вопрос на Тостере, связанный с WSL. Я, после нескольких лет использования систем на ядре Linux, около полугода назад перешел к использованию Windows 10 на домашнем ПК. Зависимость от терминала и Linux окружения в моей работе практически сразу привели меня к вопросу: или ставить виртуалку или попробовать WSL. Я выбрал второе, и остался вполне доволен.

Под катом я расскажу как установить и настроить WSL, на какие я наткнулся проблемы и ограничения, как запускать Linux приложения из Windows и наоборот, а так же как интегрировать элементы окружения Xfce в окружение рабочего стола Windows.

Никогда не думал, что однажды вернусь на Windows, но повод попробовать мне дали стечения обстоятельств: жена, далекая от IT, дергала почти каждый раз, когда у нее возникала необходимость воспользоваться компом; проснулась ностальгия по одной игре, но она никак не хотела адекватно работать под wine; а тут еще мне подарили коробочную Windows 10 Pro. WSL я поставил чуть ли не сразу после установки системы, поигрался несколько вечеров, понял, что продукт для моих задач годный, но хочется более привычный терминал и вообще некоторых удобств.

Установка WSL и дистрибутива

Сразу оговорюсь, в интернете можно найти описание установки с помощью выполнения команды lxrun /install в командной строке или консоли PowerShell. Данный способ больше не работает (после выхода WSL в стабильный релиз). Насколько мне известно, сейчас WSL можно установить только из Microsoft Store вместе с предпочитаемым дистрибутивом.

Так же отмечу, что когда установку производил я, на выбор были доступны дистрибутивы OpenSUSE, SUSE Linux Enterprise и Ubuntu 16.04 — последний я и установил. Сейчас также доступны Ubuntu 18.04, Debian 9 и Kali Linux, возможно появятся и другие дистрибутивы. Действия по установке могут отличаться. Так же, часть проблем описанных в статье может быть уже исправлена.

Находим в магазине желаемый дистрибутив и устанавливаем. Установка пройдет быстро, так как скачает только эмулятор ядра Linux и утилиту для запуска подсистемы, которая окажется в системной папке в трех экземплярах: wsl.exe, bash.exe и ubuntu.exe (вместо ubuntu будет имя Вашего дистрибутива). Все они равнозначны и делают одно и то же — запускают собственный эмулятор терминала, в нем linux’овый bash работающий под эмулятором ядра. При первом же запуске нас попросят придумать логин и пароль для пользователя по умолчанию, а после произойдет непосредственно установка дистрибутива. В качестве пользователя по умолчанию указываем root без пароля — это потребуется для дальнейших шагов. Безопасность не пострадает, кроме того при подготовке материалов к статье, в англоязычном туториале, я наткнулся на информацию, что новые версии WSL теперь делают пользователем по умолчанию root без пароля без лишних вопросов.

Дожидаемся установки. Далее первым делом стоит обновить зеркала apt на ближайшие. Для этого понадобится CLI текстовый редактор. В комплекте только vi, я же больше предпочитаю nano, поэтому ставлю его:

sudo вводить не требуется, так как мы уже под root’ом. Отредактируем файл /etc/apt/sources.list:

У меня лучше всего работают зеркала Яндекса, поэтому мой файл выглядит так:

Нажимаем Ctrl+O для сохранения и Ctrl+X для выхода. Теперь можно обновить систему до актуального состояния:

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

Далее переходим в папку юзера, зайдем под ним, установим пароль и отредактируем файл

Все, подсистема готова к использованию… почти.

Установка X-сервера, Xfce и прочих GUI’шных приложений

Первая же проблема, на которую я натолкнулся — bash-completion в предлагаемом эмуляторе терминала работал, мягко говоря, некорректно. Кроме того, данный эмулятор не умеет вкладки, а каждый его экземпляр запускает все в новом пространстве процессов, с отдельным init’ом (который кстати не заменить). Мне захотелось нормальный эмулятор терминала, некоторых других GUI приложений, а так же панельку, чтоб это все быстро запускать.

Когда я гуглил этот вопрос, я наткнулся на множество проблем, вроде необходимости перевода dbus на tcp протокол. На данный момент всех этих проблем нет. В подсистеме нормально работают unix-domain-socket’ы и все спокойно общается через них.

Первым делом нам понадобится X-сервер, притом установленный в основную систему (в Windows). Лично я использую для этих целей VcXsrv — порт X11 на Windows. Официальный сайт указанный в about самой утилиты его сейчас не предоставляет, поэтому гуглим установщик и устанавливаем все по умолчанию.

Пока идет установка возвращаемся в терминал WSL, командой exit выходим обратно в root’а. Первым делом настроим русские локали:

Далее установим некоторые компоненты Xfce. Можно конечно установить его целиком из мета-пакета, но большинство компонентов нам не понадобится, а модульная архитектура Xfce позволяет нам поставить только необходимое:

Запускать каждый раз окружение руками не очень удобно, поэтому я автоматизировал данный процесс. Для этого в основной системе создадим в удобном для нас месте папку, а в ней 3 файла для запуска:

config.xlaunch — файл настроек для VcXsrv

x-run.vbs — WSL всегда запускается со своим эмулятором терминала, если его закрыть — завершатся все его дочерние процессы. Чтоб данное окно не мозолило глаза, неплохо его запускать скрытым. К счастью в Windows встроен интерпретатор VBScript, который позволяет это сделать в одну строчку:

Поясню, что здесь происходит. Мы говорим VBscript выполнить приложение wsl с параметром cd /home/user1; DISPLAY=:0 LANG=ru_RU.UTF-8 su user1 -c xfce4-session , папка запуска нам не важна, поэтому пустая строка, действие open — запуск, 0 — скрытый режим. Самому wsl мы отдаем команду на выполнение: переход в папку пользователя, затем с установкой переменных окружения DISPLAY (дисплей X-сервера) и LANG (используемая локаль) мы запускаем xfce4-session от имени нашего пользователя user1 (благодаря команде su)

start.bat — batch файл для запуска, по желанию его можно засунуть в автозагрузку

Далее можем запустить наш start.bat и настроить панель Xfce под себя. Замечу, что здесь я наткнулся на еще одну проблему — панель прекрасно отображается поверх всех окон, но вот выделить себе место, как панель на рабочем столе Windows она не может. Если кто знает решение данной проблемы, поделитесь в комментариях.

Ну и под конец данной части, скриншот моего рабочего стола:

Взаимодействие окружения Windows и окружения подсистемы Linux

Запускать Linux приложения напрямую из Windows можно через те же 3 команды — bash, wsl или ubuntu. Не забываем, что по умолчанию запуск идет от root, поэтому стоит понижать привилегии через su , так же нужно не забывать передавать переменную окружения DISPLAY=:0 если приложению требуется X-сервер. Так же нужно менять папку, из которой должно работать приложение, через cd внутри WSL. Пример, посчитаем md5 для file.txt на диске D средствами Linux’овой md5sum:

Доступ к файловой системе Linux так же имеется, лежит она в %localappdata%\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs . Читать таким образом файлы можно, а вот писать — не желательно, можно поломать файловую систему. Думаю проблема в том, что Windows не умеет работать с правами и владельцами файловой системы Linux.

Из Linux так же можно запускать Windows приложения. Просто запускаем exe-шник и он выполнится в основной системе.

Диски Windows монтируются в /mnt в соответствии со своими буквами в нижнем регистре. Например диск D будет смонтирован в /mnt/d . Из Linux можно свободно читать и писать файлы Windows. Можно делать на них симлинки. Права у таких файлов всегда будут 0777, а владельцем будет root.

Сетевой стек у подсистемы общий с Windows. Сервер поднятый в Linux будет доступен на localhost в Windows и наоборот. Однако unix-domain-socket для Windows будет просто пустым файлом, работать с этим можно только внутри Linux. Выход во внешнюю сеть у Linux так же есть, в том числе можно слушать порты, если этого не запрещает фаервол.
ifconfig в Linux и ipconfig в Windows выдают одинаковую информацию о сетевых интерфейсах.

Из диспетчера задач Windows можно спокойно прибить процесс внутри подсистемы Linux. Однако Linux увидит только свои процессы.

Особенности, ограничения и подводные камни

Ядро Linux в WSL не настоящее. Это всего лишь прослойка-эмулятор, которая часть Linux-специфичных задач выполняет сама, а часть проксирует напрямую в ядро winNT. Большая часть api в нем реализована, но не все. Свое ядро собрать не получится, как и не получится подключить модули ядра (.ko, Kernel Object).

Init процесс у WSL тоже свой и заменить его, например, на system.d не выйдет. У меня давно есть желание написать менеджер демонов на go, который бы работал с файлами юнитов system.d и предоставлял бы схожий интерфейс, да все руки не доходят.

Нет поддержки openFUSE, соответственно примонтировать виртуальную или удаленную файловую систему не получится. Так же нельзя сделать mount из файла, mount вообще ничего кроме bind здесь, похоже, не умеет.

Так же нет никакой возможности разбить файловую систему Linux на несколько разделов/дисков.

Прямой доступ к железу практически отсутствует. Все таки мы находимся в песочнице Windows, а не в полноценном Linux. /dev и /sys заметно пустуют, в них лишь проц да виртуальные устройства. Доступ к GPU — только через X-сервер, напрямую — никак, так что нейросети обучать придется в Windows.

В JS разработке столкнулся с тем, что electron.js отказался запускаться в WSL, пришлось дублировать окружение node.js в Windows.

Итоги

Статья получилась довольно длинной, надеюсь, что она окажется еще и полезной.
WSL для меня лично оказался инструментом вполне юзабельным, решающим мои задачи fullstack backend разработчика. Виртуалка с Linux за полгода так и не понадобилась. По общим ощущениям Windows+WSL намного функциональнее, чем Linux+Wine.

Пока писал статью, обнаружил, что в Microsoft Store появилась сборка WSL с Debian 9.3, данный дистрибутив мне более симпатичен, чем Ubuntu, поэтому буду пробовать ставить.

Источник