Comments 66
Человек начал с тезиса о том, что он разработчик\тестер под ОС Windows.
Увы… /bin/sh еще больше в винде тормозит, чем powerShell. Так, что видимо шустрой и функциональной консоли ему не видать(((
Не могу сказать ничего хорошего или плохого о /bin/sh в винде — не работал с ним. Я хотел выразить мысль о том, что тестеру или сисадмину под Windows очень полезно знать PowerShell (полезнее, чем комманды DOS).
Скорее всего да, но блин. Лично меня удручает скорость запуска powershell'а и скорость выполнения команд в нем.
Да ладно Вам, пару десятков секунд подождать до запуска. Зато если набирать текст пока он запускается, то при полном запуске этот текст появится =)
На всякий случай:


Полная инициализация вместе с рантаймом и выходом — 700 миллисекунд. Но в случае павершелла не нужно создавать процессы сотнями, если рантайм уже проинициализирован, создание нового павершелла со всеми ранспейсами и пайпами — меньше миллисекунды (вторая команда). Вручную этим заниматься чаще всего не приходится (параметр -AsJob делает это автоматом).
PS-Remoting основан на WinRM

Причем здесь действительно удаленная машина: почти все время — latency сети.
А что со скоростью запуска и скоростью выполнения? Слишком быстро для Вас?
Для «скриптабельности» на винде есть расширяемый WSH, c VBScript и JScript из коробки, с возможностью делать вообще всё, даже дергать функции из нативных DLL и т.д. Не говоря о том, что при желании можно в WSH хоть perl подключить.

А чтобы писать «one-liner» в комстроке Farлюбимого файлового менеджера для 90% задач Вам вполне хватит стандартного виндового cmd и стандартных же findstr и прочих.
Добавим портированные из никсов coreutils — убили еще 9 % задач.
И perl для оставшегося 1 %.

Еще есть 4NT, он же Take Command, по возможностям примерно равный sh с coreutils, но синтаксис не лучше, чем у cmd.
>VBScript и JScript из коробки, с возможностью делать вообще всё, даже дергать функции из нативных DLL

К сожалению из коробки этого сделать нельзя.
Пардон, про вызов DLL — перепутал с VBA.

Что в PowerShell, что в WSH, чтобы дернуть нативную DLL из VBscript действительно придется использовать свой или чужой костыль (одна радость — при вездесущем дотнете можно сгенерировать его прямо в том же скрипте :) ).

А «всё» — имелись в виду, конечно, доступные из WSH сотни и тысячи COM-интерфейсов.

Нет, из PowerShell можно свободно дергать любые dll-ки за P/Invoke
Вот пример вызова EmptyWorkingSet

На WSH — да, нужны сторонние COM-ы
Огрызок не огрызок, а мне порой жалко юзеров, которые лихорадочно вспоминают куда они сохранили файл, в котором записаны параметры подключения ко второй/третей сети, затем также лихорадочно вбивают эти параметры в диалоговый окошки настройки сети.
Они не знают и не хотят знать о netsh
Огрызок — это безусловно, по сравнению даже c голым POSIX-совместимым sh.
А вот неюзабельный? Я бы не был так категоричен. Синтаксис страшноват, но это ж не брейнфак, верно?
Да не такой уж огрызок. А синтаксис страшен у обоих. Именно поэтому их категорически нельзя использоваться для скриптинга.
Никто и не сомневался, что сюда наведается линукс-илита. А давайте ка Вы расскажете, чего в cmd нельзя сделать такого, что можно сделать в (ba)sh?

Да, на всякий случай, и cmd и sh — говно, непригодное для скриптинга.
Я думаю, что отрицательное отношение общественности к NT batch обусловлено:
  1. Малая известность фич NT batch. В пустой системе батников — раз, два — и обчелся, да и те с базовым синтаксисом. А в никсах — скрипты везде, и даже неопытному пользователю приходится в них заглядывать. И one-liner'ы в никсах популярны.
  2. Чтобы сделать многострочный блок внутри ветвления, надо или круглые скобки городить(а круглые скобки широким массам слабо известны), или goto'ми давиться (цикл с постусловием организовать — тем более).
  3. Громоздкая конструкция %ERRORLEVEL%. Ну кто, кто мешал назвать ее %E% или даже %?
  4. Обработка ввода пользователя — мало, да и то ужс. До семерки носил за собой choice.exe
  5. В batch не любят ставить отступы, хотя можно ведь.

Итого — пытается некто нечто автоматизировать — не получается, лезет за примерами — видит хрень ===> НЕНАВИСТЬ!!!

Насчет непригодного для скриптинга sh — заглянем в боевой юникс, к примеру, HP-UX — масса скриптов именно на sh. Страшно, но жить можно.
Потом, если не ошибаюсь, писать init-скрипты на sh — это вроде как хороший тон, ибо переносимо и совместимо по самые помидоры до десятого колена.
Малая распространенность cmd — это благо. Для скриптинга испокон веков был WSH и люди пользовались тем, что было создано для скриптинга. Собственно, одна из причин, по которой мне не нравится (ba)sh — это его повсеместное использование. Ну уродливы на нем скрипты. Уродливы и ограничены. Был же перл, сейчас есть питон тот же — не так изящно, как WSH, но это изящество не всегда и нужно, если надо просто набросать скриптик — нет же все равно тянутся к sh

Кстати, по поводу 4: есть такая малоизвестная штука как «set /p»

Что же до боевых юниксов — я и не говорил, что sh не используется для скриптинга, я говорил, что он непригоден для скриптинга. Автоконф вон тоже sh-скрипты генерирует, это не значит, что это стоит делать. Да и в init лучше б питон какой — переносимость и совместимость не страдает (даже выигрывает через сменные реализации всяких платформнозависимых модулей с одинаковым интерфейсом), но при этом хотя бы не выглядит как говно (а также не плодит тысячи процессов, не эмулирует печатную машинку для связи между модулями и пр)
Подскажите, есть ли смысл сразу использовать .NET для написания простенькой программы, которая будет управлять несколькими устройствами по COM-портам и собирать с них данные. По сути, проще ли будет сделать простенькую морду для такого обмена в .NET, чем в стандартном Win32 API?
Есть факторы, влияющие на решение:
Если количество устройств в будущем может достигать десятков (сотен), если есть четкие требования по быстродействию, потреблению CPU и RAM — пишите на C++ и Win32 API.

Если надо написать быстро, устройств не будет больше пары штук, ресурсы не жмут и нужен запас по возможности «наворачивания интерфейса» — пишите на .NET.
Ага, спасибо за разъяснение. Мне подойдет второе.

p.s. не понял за что комментарий заминусовали, вроде касается 2-го пункта топика как раз, ну да ладно
>p.s. не понял за что комментарий заминусовали…
Это Хабр — тут комментарии до конца не читают, а у Вас упоминание о Win32 API — последним словом написано.
в рамках
Изучи Perl!

посоветую perl модуль Win32::SerialPort
благополучно справляется с отправкой и приемом данных по COM портам
а уж простенькую морду наваять там и вовсе запросто можно
Недавно писал такую морду на .NET/WPF.
Вышло неплохо. Но учтите, что обертки для Serial Port кривоваты и без P/Invoke скорее всего обойтись не удастся.
Хм, интересно. А может тогда получится сразу на Silverlight? Просто мне больше всего лень руками писать морду приложения, вместо того, чтобы сделать это в каком-нибудь редакторе интерфейса на подобии того, что есть в Visual Basic. Плюс наличие доступа к COM-портам нужно.
Ну, в .net такой доступ есть, но как я уже писал, кривоват и если вам нужно многое, то без P/Invoke никак.
Я не понимаю, зачем вам Silverlight. Это в веб будет работать?
Нет, просто програмка, для автоматизация эксперимента. Управляет по COM-портам приборами для эксперимента и снимает данные. Вот думал, что наверняка в Silverlight есть средства для более простого рисования интерфейса, чтобы не прописывать параметры каждого окна и элемента вручную. А так мне все равно на чем остальное делать, хоть .NET, хоть Win32 API.
есть средства для более простого рисования интерфейса, чтобы не прописывать параметры каждого окна и элемента вручную
Это есть в WinForms, WPF и тысяче фреймворков.
Ооо, понятно, спасибо. А что бы Вы посоветовали? WinForms или WPF?
Вот короткий пример на PS:
Вот здесь больше информации о том, что можно сделать

Это если скриптовать. Если нужна «морда», то можно и WPF/WinForms
Спасибо за ссылки. Уже начал немного эксперементировать с портами и, вроде, все работает. =)
Если скриптовая функция работала в 25 раз медленнее, чем «команда DOS», которая запускает внешний процесс выполняющей те же API, что должен использовать скрипт, подключает процесс консоли к пайпам созданного процесса и, дампит текстовый вывод в файл, то это говорит о том, что радиус кривизны рук или автора топика, и/или, что скорее всего, некоторых разработчиков SilkTest стремится к 0.
Дык автор же про это и говорит. Он не супер-пупер программист, но свои задачи решает максимально эффективно используя _правильные_ инструменты. Например комманд лайн вместо самописных функций.
А еще оказалось, что команда xcopy работает стабильней, чем стандартная функция SilkTest SYS_CopyFile
Borland такой Borland.
Когда же он наконец сдохнет…
А автору статьи я бы посоветовал почитать умные книжки, а не ходить впотьмах на борландовских костылях.
WinAPI кстати являет собой хрестоматийный пример неудачного, стихийного проектирования. Как впрочем и многие бородатые вещи
бородатые? емнип у UNIX/POSIX борода подлиннее будет, а вы тут на /bin/sh слюной брызжете
Я про все что-ли говорил? Почему народ так любит читать совсем не то, что написано!
Из бородатых, но кривых штук могу вспомнить X11 — то ещё зрелище!
И на sh я слюной тащемта не брызгал.
Статья очень понравилась стремлением автора к саморазвитию.
Мои рекомендации:
1. Посмотрите в сторону VBScript — хорошая альтернатива консольным пакетным программам (.bat) для винды.
2. (опционально) Посмотрите как устроена консоль в Unix-подобных системах, поймете недостатки виндовой консоли.
Может быть WSH && Python лучший выбор. Есть гораздо более мощные системы тестирования
Советы не кросс-платформенны и в общем сводимы к — «Изучите свою OC прежде чем писать под нее» и «Учите разные парадигмы программирования». Под каждым пунктом готов подписаться. Но конкретный путь — на совести автора…
Статья классная, но автор явно мог бы развернуться на полную катушку если бы изначально попал в unix среду, а не в windows.
Вот вот. Да даже простой обзор других осей мог бы вообще в корне всё мировозрение перевернуть.
Согласен с автором на 100%
command line (и уменее работать с ним) жутко помогает в реальной жизни, и не только тестировщикам
Правда, не холивара ради, а по наблюдениям, те кто использует Win/TotalComander реже использует command line
FAR — чаще, и имхо это объяснимо — FAR сам в консоле живет, а для Тотала — она чужда по идеологии.

И путь C->Perl->Ruby — тоже мой реальный путь (при том что вся контора пишет на .net)

А винапи похоже таки надо учить, особенно в контексте того что из руби его дергать — элементарно, его часто не хватает.

Еще из полезного в жизни тестировщика (и не только)
AutoIT — как автономная штука, для автоматизации GUI, именно не тестирования, а автоматизации операций, кнопочки там понажимать, etc.
AutoitX — COM версия ее же, дергаю из руби, т.к. язык в AutoIT слабоват :)
я не тестировщик, а разработчик
но со всеми советами согласен,
очень часто приходится решать разного рода системные задачи.
Знание комендной строки порой бывает просто необходимо, потихоньку внедряю в практику sed & awk
Что касается знание любого «динамического» языка, то администратору он бывает просто необходим. Иногда 10 строк кода заменят два часа рутиннго набора команд. Сейчас популярен питон. Хотя, каждый язык, прекрасен в своем роде.
в венде я только и уважаю командную строку.
статья хорошая, интересная.

p.s. друг рассказывал, у провайдера техподдержка второй линии, которым первым дозваниваются, прознала про комманду netsh winsock reset, и всем кто с проблемами звонил советовали выполнить эту команду, естественно когда траблов не было на стороне прова.
Неважное замечание

dir C: /B /S > initial_c.txt сработает если запустить команду из корня диска С. Лучше dir C:\ /B /S > initial_c.txt

Я поробовал без слеша на своей машине, и получил список файлов только текущей папки. Странно.
все правильно, без слеша — получаем содержимое из текущей папки на указаном диске

Все советы можно свести к одному простому:
«Изучи среду, в которой ты разрабатываешь тесты/приложения и её возможности»
Но всё равно спасибо за статью. Многие пренебрегают возможностями, описанными в ней.
А я все три вещи б свёл к одной. Хороший тестер-автоматор должен ещё быть и хорошим программистом.
Чрезмерно много «Я» в статье.

Автору желаю не останавливаться на достигнутом.
Да, командная строка в Винде и мне частенько помогает. Например:

netsh wlan set hostednetwork mode=allow ssid=«hotspot» key=«password» keyUsage=persistent
netsh wlan start hostednetwork

Эта нехитрая пара команд под Вин7 запускает Wi-Fi на моем ноуте в режиме точки доступа.
Если взять CMD + WSH, то я думаю, что она не уступит bash'y в юниксах по функциональности.
Еще я слышал, что WMIC мощная штука для управления Виндой, но пока я в ней и с ее WQL запросами не разобрался дальше, чем на просмотр информации. Есть ли мануал по WMIC и его командам?
Ну раз уж речь о Win7, то вместо wmic лучше использовать gwmi (Get-WmiObject) — всяко и гибче и удобнее.
Согласен. Только вот gwmi — это командлет PowerShell'a. К нему нет доступа из простой cmd. А Винду можно собрать и без PowerShell'a, и даже без .NET. У меня сейчас вообще на виртуалке в качестве эксперимента крутится чисто виндовое ядро, минимум драйверов и cmd в качестве единственного интерфейса. Вот тут wmic будет очень кстати. Когда размер сборки винды имеет значение, тогда не очень хочется тянуть за PS целый .NET Framework и все остальные зависимости для него.
Ну кроме простейших задач все равно лучше использовать WSH

Что же до wmic — вот здесь есть небольшой список. Вообще в случае wmic стоит сначала понять что такое WMI (здесь очень поможет gwmi даже если не ставить его на сервер) и чего с ним можно делать, а потом пробовать выразить все на wmic.
Only those users with full accounts are able to leave comments. Log in, please.