Comments
66
Лол… DOS это не командная строка, а неюзабельный огрызок.
На сегодняший день можно сказать «изучи PowerShell».
/bin/sh тогда уж. PowerShell больно тормозной
Человек начал с тезиса о том, что он разработчик\тестер под ОС Windows.
Увы… /bin/sh еще больше в винде тормозит, чем powerShell. Так, что видимо шустрой и функциональной консоли ему не видать(((
Не могу сказать ничего хорошего или плохого о /bin/sh в винде — не работал с ним. Я хотел выразить мысль о том, что тестеру или сисадмину под Windows очень полезно знать PowerShell (полезнее, чем комманды DOS).
Скорее всего да, но блин. Лично меня удручает скорость запуска powershell'а и скорость выполнения команд в нем.
Да ладно Вам, пару десятков секунд подождать до запуска. Зато если набирать текст пока он запускается, то при полном запуске этот текст появится =)
О каких паре десятках секунд Вы говорите?
На всякий случай:
Полная инициализация вместе с рантаймом и выходом — 700 миллисекунд. Но в случае павершелла не нужно создавать процессы сотнями, если рантайм уже проинициализирован, создание нового павершелла со всеми ранспейсами и пайпами — меньше миллисекунды (вторая команда). Вручную этим заниматься чаще всего не приходится (параметр -AsJob делает это автоматом).
Полная инициализация вместе с рантаймом и выходом — 700 миллисекунд. Но в случае павершелла не нужно создавать процессы сотнями, если рантайм уже проинициализирован, создание нового павершелла со всеми ранспейсами и пайпами — меньше миллисекунды (вторая команда). Вручную этим заниматься чаще всего не приходится (параметр -AsJob делает это автоматом).
Извините, я и забыл что все так сложно </humor>
В WinRM скорость ещё хуже.
PS-Remoting основан на WinRM
Причем здесь действительно удаленная машина: почти все время — latency сети.
Причем здесь действительно удаленная машина: почти все время — latency сети.
А что со скоростью запуска и скоростью выполнения? Слишком быстро для Вас?
Для «скриптабельности» на винде есть расширяемый WSH, c VBScript и JScript из коробки, с возможностью делать вообще всё, даже дергать функции из нативных DLL и т.д. Не говоря о том, что при желании можно в WSH хоть perl подключить.
А чтобы писать «one-liner» в комстрокеFarлюбимого файлового менеджера для 90% задач Вам вполне хватит стандартного виндового cmd и стандартных же findstr и прочих.
Добавим портированные из никсов coreutils — убили еще 9 % задач.
И perl для оставшегося 1 %.
Еще есть 4NT, он же Take Command, по возможностям примерно равный sh с coreutils, но синтаксис не лучше, чем у cmd.
А чтобы писать «one-liner» в комстроке
Добавим портированные из никсов coreutils — убили еще 9 % задач.
И perl для оставшегося 1 %.
Еще есть 4NT, он же Take Command, по возможностям примерно равный sh с coreutils, но синтаксис не лучше, чем у cmd.
>VBScript и JScript из коробки, с возможностью делать вообще всё, даже дергать функции из нативных DLL
К сожалению из коробки этого сделать нельзя.
К сожалению из коробки этого сделать нельзя.
Пардон, про вызов DLL — перепутал с VBA.
Что в PowerShell, что в WSH, чтобы дернуть нативную DLL из VBscript действительно придется использовать свой или чужой костыль (одна радость — при вездесущем дотнете можно сгенерировать его прямо в том же скрипте :) ).
А «всё» — имелись в виду, конечно, доступные из WSH сотни и тысячи COM-интерфейсов.
Что в PowerShell, что в WSH, чтобы дернуть нативную DLL из VBscript действительно придется использовать свой или чужой костыль (одна радость — при вездесущем дотнете можно сгенерировать его прямо в том же скрипте :) ).
А «всё» — имелись в виду, конечно, доступные из WSH сотни и тысячи COM-интерфейсов.
Нет, из PowerShell можно свободно дергать любые dll-ки за P/Invoke
Вот пример вызова EmptyWorkingSet
На WSH — да, нужны сторонние COM-ы
Вот пример вызова EmptyWorkingSet
На WSH — да, нужны сторонние COM-ы
Огрызок не огрызок, а мне порой жалко юзеров, которые лихорадочно вспоминают куда они сохранили файл, в котором записаны параметры подключения ко второй/третей сети, затем также лихорадочно вбивают эти параметры в диалоговый окошки настройки сети.
Они не знают и не хотят знать о netsh
Они не знают и не хотят знать о netsh
Огрызок — это безусловно, по сравнению даже c голым POSIX-совместимым sh.
А вот неюзабельный? Я бы не был так категоричен. Синтаксис страшноват, но это ж не брейнфак, верно?
А вот неюзабельный? Я бы не был так категоричен. Синтаксис страшноват, но это ж не брейнфак, верно?
Да не такой уж огрызок. А синтаксис страшен у обоих. Именно поэтому их категорически нельзя использоваться для скриптинга.
Никто и не сомневался, что сюда наведается линукс-илита. А давайте ка Вы расскажете, чего в cmd нельзя сделать такого, что можно сделать в (ba)sh?
Да, на всякий случай, и cmd и sh — говно, непригодное для скриптинга.
Да, на всякий случай, и cmd и sh — говно, непригодное для скриптинга.
Я думаю, что отрицательное отношение общественности к NT batch обусловлено:
Итого — пытается некто нечто автоматизировать — не получается, лезет за примерами — видит хрень ===> НЕНАВИСТЬ!!!
Насчет непригодного для скриптинга sh — заглянем в боевой юникс, к примеру, HP-UX — масса скриптов именно на sh. Страшно, но жить можно.
Потом, если не ошибаюсь, писать init-скрипты на sh — это вроде как хороший тон, ибо переносимо и совместимо по самые помидоры до десятого колена.
- Малая известность фич NT batch. В пустой системе батников — раз, два — и обчелся, да и те с базовым синтаксисом. А в никсах — скрипты везде, и даже неопытному пользователю приходится в них заглядывать. И one-liner'ы в никсах популярны.
- Чтобы сделать многострочный блок внутри ветвления, надо или круглые скобки городить(а круглые скобки широким массам слабо известны), или goto'ми давиться (цикл с постусловием организовать — тем более).
- Громоздкая конструкция %ERRORLEVEL%. Ну кто, кто мешал назвать ее %E% или даже %?
- Обработка ввода пользователя — мало, да и то ужс. До семерки носил за собой choice.exe
- В batch не любят ставить отступы, хотя можно ведь.
Итого — пытается некто нечто автоматизировать — не получается, лезет за примерами — видит хрень ===> НЕНАВИСТЬ!!!
Насчет непригодного для скриптинга sh — заглянем в боевой юникс, к примеру, HP-UX — масса скриптов именно на sh. Страшно, но жить можно.
Потом, если не ошибаюсь, писать init-скрипты на sh — это вроде как хороший тон, ибо переносимо и совместимо по самые помидоры до десятого колена.
Малая распространенность cmd — это благо. Для скриптинга испокон веков был WSH и люди пользовались тем, что было создано для скриптинга. Собственно, одна из причин, по которой мне не нравится (ba)sh — это его повсеместное использование. Ну уродливы на нем скрипты. Уродливы и ограничены. Был же перл, сейчас есть питон тот же — не так изящно, как WSH, но это изящество не всегда и нужно, если надо просто набросать скриптик — нет же все равно тянутся к sh
Кстати, по поводу 4: есть такая малоизвестная штука как «set /p»
Что же до боевых юниксов — я и не говорил, что sh не используется для скриптинга, я говорил, что он непригоден для скриптинга. Автоконф вон тоже sh-скрипты генерирует, это не значит, что это стоит делать. Да и в init лучше б питон какой — переносимость и совместимость не страдает (даже выигрывает через сменные реализации всяких платформнозависимых модулей с одинаковым интерфейсом), но при этом хотя бы не выглядит как говно (а также не плодит тысячи процессов, не эмулирует печатную машинку для связи между модулями и пр)
Кстати, по поводу 4: есть такая малоизвестная штука как «set /p»
Что же до боевых юниксов — я и не говорил, что sh не используется для скриптинга, я говорил, что он непригоден для скриптинга. Автоконф вон тоже sh-скрипты генерирует, это не значит, что это стоит делать. Да и в init лучше б питон какой — переносимость и совместимость не страдает (даже выигрывает через сменные реализации всяких платформнозависимых модулей с одинаковым интерфейсом), но при этом хотя бы не выглядит как говно (а также не плодит тысячи процессов, не эмулирует печатную машинку для связи между модулями и пр)
Подскажите, есть ли смысл сразу использовать .NET для написания простенькой программы, которая будет управлять несколькими устройствами по COM-портам и собирать с них данные. По сути, проще ли будет сделать простенькую морду для такого обмена в .NET, чем в стандартном Win32 API?
Есть факторы, влияющие на решение:
Если количество устройств в будущем может достигать десятков (сотен), если есть четкие требования по быстродействию, потреблению CPU и RAM — пишите на C++ и Win32 API.
Если надо написать быстро, устройств не будет больше пары штук, ресурсы не жмут и нужен запас по возможности «наворачивания интерфейса» — пишите на .NET.
Если количество устройств в будущем может достигать десятков (сотен), если есть четкие требования по быстродействию, потреблению CPU и RAM — пишите на C++ и Win32 API.
Если надо написать быстро, устройств не будет больше пары штук, ресурсы не жмут и нужен запас по возможности «наворачивания интерфейса» — пишите на .NET.
Ага, спасибо за разъяснение. Мне подойдет второе.
p.s. не понял за что комментарий заминусовали, вроде касается 2-го пункта топика как раз, ну да ладно
p.s. не понял за что комментарий заминусовали, вроде касается 2-го пункта топика как раз, ну да ладно
>p.s. не понял за что комментарий заминусовали…
Это Хабр — тут комментарии до конца не читают, а у Вас упоминание о Win32 API — последним словом написано.
Это Хабр — тут комментарии до конца не читают, а у Вас упоминание о Win32 API — последним словом написано.
в рамках
посоветую perl модуль Win32::SerialPort
благополучно справляется с отправкой и приемом данных по COM портам
а уж простенькую морду наваять там и вовсе запросто можно
Изучи Perl!
посоветую perl модуль Win32::SerialPort
благополучно справляется с отправкой и приемом данных по COM портам
а уж простенькую морду наваять там и вовсе запросто можно
Спасибо за подсказку, учту, в случае чего. :)
Недавно писал такую морду на .NET/WPF.
Вышло неплохо. Но учтите, что обертки для Serial Port кривоваты и без P/Invoke скорее всего обойтись не удастся.
Вышло неплохо. Но учтите, что обертки для Serial Port кривоваты и без P/Invoke скорее всего обойтись не удастся.
Хм, интересно. А может тогда получится сразу на Silverlight? Просто мне больше всего лень руками писать морду приложения, вместо того, чтобы сделать это в каком-нибудь редакторе интерфейса на подобии того, что есть в Visual Basic. Плюс наличие доступа к COM-портам нужно.
Ну, в .net такой доступ есть, но как я уже писал, кривоват и если вам нужно многое, то без P/Invoke никак.
Я не понимаю, зачем вам Silverlight. Это в веб будет работать?
Я не понимаю, зачем вам Silverlight. Это в веб будет работать?
Нет, просто програмка, для автоматизация эксперимента. Управляет по COM-портам приборами для эксперимента и снимает данные. Вот думал, что наверняка в Silverlight есть средства для более простого рисования интерфейса, чтобы не прописывать параметры каждого окна и элемента вручную. А так мне все равно на чем остальное делать, хоть .NET, хоть Win32 API.
есть средства для более простого рисования интерфейса, чтобы не прописывать параметры каждого окна и элемента вручную
Это есть в WinForms, WPF и тысяче фреймворков.
Это есть в WinForms, WPF и тысяче фреймворков.
Ооо, понятно, спасибо. А что бы Вы посоветовали? WinForms или WPF?
Я бы — WPF.
Спасибо. Ну, значит решено. =)
Спасибо за ссылки. Уже начал немного эксперементировать с портами и, вроде, все работает. =)
Если скриптовая функция работала в 25 раз медленнее, чем «команда DOS», которая запускает внешний процесс выполняющей те же API, что должен использовать скрипт, подключает процесс консоли к пайпам созданного процесса и, дампит текстовый вывод в файл, то это говорит о том, что радиус кривизны рук или автора топика, и/или, что скорее всего, некоторых разработчиков SilkTest стремится к 0.
Дык автор же про это и говорит. Он не супер-пупер программист, но свои задачи решает максимально эффективно используя _правильные_ инструменты. Например комманд лайн вместо самописных функций.
А еще оказалось, что команда xcopy работает стабильней, чем стандартная функция SilkTest SYS_CopyFile
Borland такой Borland.
Borland такой Borland.
Когда же он наконец сдохнет…
А автору статьи я бы посоветовал почитать умные книжки, а не ходить впотьмах на борландовских костылях.
WinAPI кстати являет собой хрестоматийный пример неудачного, стихийного проектирования. Как впрочем и многие бородатые вещи
А автору статьи я бы посоветовал почитать умные книжки, а не ходить впотьмах на борландовских костылях.
WinAPI кстати являет собой хрестоматийный пример неудачного, стихийного проектирования. Как впрочем и многие бородатые вещи
бородатые? емнип у UNIX/POSIX борода подлиннее будет, а вы тут на /bin/sh слюной брызжете
Я про все что-ли говорил? Почему народ так любит читать совсем не то, что написано!
Из бородатых, но кривых штук могу вспомнить X11 — то ещё зрелище!
И на sh я слюной тащемта не брызгал.
Из бородатых, но кривых штук могу вспомнить X11 — то ещё зрелище!
И на sh я слюной тащемта не брызгал.
Статья очень понравилась стремлением автора к саморазвитию.
Мои рекомендации:
1. Посмотрите в сторону VBScript — хорошая альтернатива консольным пакетным программам (.bat) для винды.
2. (опционально) Посмотрите как устроена консоль в Unix-подобных системах, поймете недостатки виндовой консоли.
Мои рекомендации:
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 слабоват :)
command line (и уменее работать с ним) жутко помогает в реальной жизни, и не только тестировщикам
Правда, не холивара ради, а по наблюдениям, те кто использует Win/TotalComander реже использует command line
FAR — чаще, и имхо это объяснимо — FAR сам в консоле живет, а для Тотала — она чужда по идеологии.
И путь C->Perl->Ruby — тоже мой реальный путь (при том что вся контора пишет на .net)
А винапи похоже таки надо учить, особенно в контексте того что из руби его дергать — элементарно, его часто не хватает.
Еще из полезного в жизни тестировщика (и не только)
AutoIT — как автономная штука, для автоматизации GUI, именно не тестирования, а автоматизации операций, кнопочки там понажимать, etc.
AutoitX — COM версия ее же, дергаю из руби, т.к. язык в AutoIT слабоват :)
я не тестировщик, а разработчик
но со всеми советами согласен,
очень часто приходится решать разного рода системные задачи.
Знание комендной строки порой бывает просто необходимо, потихоньку внедряю в практику sed & awk
Что касается знание любого «динамического» языка, то администратору он бывает просто необходим. Иногда 10 строк кода заменят два часа рутиннго набора команд. Сейчас популярен питон. Хотя, каждый язык, прекрасен в своем роде.
но со всеми советами согласен,
очень часто приходится решать разного рода системные задачи.
Знание комендной строки порой бывает просто необходимо, потихоньку внедряю в практику sed & awk
Что касается знание любого «динамического» языка, то администратору он бывает просто необходим. Иногда 10 строк кода заменят два часа рутиннго набора команд. Сейчас популярен питон. Хотя, каждый язык, прекрасен в своем роде.
в венде я только и уважаю командную строку.
статья хорошая, интересная.
p.s. друг рассказывал, у провайдера техподдержка второй линии, которым первым дозваниваются, прознала про комманду netsh winsock reset, и всем кто с проблемами звонил советовали выполнить эту команду, естественно когда траблов не было на стороне прова.
статья хорошая, интересная.
p.s. друг рассказывал, у провайдера техподдержка второй линии, которым первым дозваниваются, прознала про комманду netsh winsock reset, и всем кто с проблемами звонил советовали выполнить эту команду, естественно когда траблов не было на стороне прова.
Неважное замечание
dir C: /B /S > initial_c.txt сработает если запустить команду из корня диска С. Лучше dir C:\ /B /S > initial_c.txt
Я поробовал без слеша на своей машине, и получил список файлов только текущей папки. Странно.
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 и его командам?
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 и все остальные зависимости для него.
О, спасибо за список! Много интересных примеров команд увидел.
«Тут я приклоняю голову перед..»
Правильно будет «преклоняю».
Правильно будет «преклоняю».
На очепятки обычно принято указывать через личку.
Only those users with full accounts are able to leave comments. Log in, please.
Три самых полезных навыка, которые я приобрел 5 лет назад