Comments 66
Лол… DOS это не командная строка, а неюзабельный огрызок.
На сегодняший день можно сказать «изучи PowerShell».
/bin/sh тогда уж. PowerShell больно тормозной
Человек начал с тезиса о том, что он разработчик\тестер под ОС Windows.
Увы… /bin/sh еще больше в винде тормозит, чем powerShell. Так, что видимо шустрой и функциональной консоли ему не видать(((
Не могу сказать ничего хорошего или плохого о /bin/sh в винде — не работал с ним. Я хотел выразить мысль о том, что тестеру или сисадмину под Windows очень полезно знать PowerShell (полезнее, чем комманды DOS).
Скорее всего да, но блин. Лично меня удручает скорость запуска powershell'а и скорость выполнения команд в нем.
Да ладно Вам, пару десятков секунд подождать до запуска. Зато если набирать текст пока он запускается, то при полном запуске этот текст появится =)
О каких паре десятках секунд Вы говорите?
На всякий случай:
Полная инициализация вместе с рантаймом и выходом — 700 миллисекунд. Но в случае павершелла не нужно создавать процессы сотнями, если рантайм уже проинициализирован, создание нового павершелла со всеми ранспейсами и пайпами — меньше миллисекунды (вторая команда). Вручную этим заниматься чаще всего не приходится (параметр -AsJob делает это автоматом).
Полная инициализация вместе с рантаймом и выходом — 700 миллисекунд. Но в случае павершелла не нужно создавать процессы сотнями, если рантайм уже проинициализирован, создание нового павершелла со всеми ранспейсами и пайпами — меньше миллисекунды (вторая команда). Вручную этим заниматься чаще всего не приходится (параметр -AsJob делает это автоматом).
Извините, я и забыл что все так сложно </humor>
В WinRM скорость ещё хуже.
А что со скоростью запуска и скоростью выполнения? Слишком быстро для Вас?
Для «скриптабельности» на винде есть расширяемый 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.
в рамках
посоветую 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.
Если скриптовая функция работала в 25 раз медленнее, чем «команда DOS», которая запускает внешний процесс выполняющей те же API, что должен использовать скрипт, подключает процесс консоли к пайпам созданного процесса и, дампит текстовый вывод в файл, то это говорит о том, что радиус кривизны рук или автора топика, и/или, что скорее всего, некоторых разработчиков SilkTest стремится к 0.
Дык автор же про это и говорит. Он не супер-пупер программист, но свои задачи решает максимально эффективно используя _правильные_ инструменты. Например комманд лайн вместо самописных функций.
А еще оказалось, что команда xcopy работает стабильней, чем стандартная функция SilkTest SYS_CopyFile
Borland такой Borland.
Borland такой Borland.
Статья очень понравилась стремлением автора к саморазвитию.
Мои рекомендации:
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 и все остальные зависимости для него.
«Тут я приклоняю голову перед..»
Правильно будет «преклоняю».
Правильно будет «преклоняю».
Sign up to leave a comment.
Три самых полезных навыка, которые я приобрел 5 лет назад