AndreyHenneberg

Клиенты всего Интернета, хотите сказать? Потому что, чтобы «отбрасывать пакеты», надо знать по каким адресам. А эти адреса меняются постоянно. Кроме того, Вы забыли одну важную вещь: блокирует не Роскомпозор, а операторы. Роскомпозор только списки адресов отдаёт. То, что Вы описали — отличное решение для админа небольшой сети, а когда у Вас сеть на сотни тысяч клиентов, это становится проблематично: одно дело — просто не пускать пакеты по определённым маскам, другое — производить с ними какие-то интеллектуальные действия, храня счётчики для каждого из 20 миллионов (столько было на вчерашний вечер) адресов. Да тут никакое оборудование не выдюжит. Причём, списки блокируемых адресов общедоступны — их РКН раздаёт провайдерам он ОБЯЗАН делать это открыто, потому что это открытая информация. А если я знаю, что какой-то диапазон начинают блокировать, я, во-первых, уберу оттуда свои сервисы и перенесу в «чистое» адресное пространство, а во-вторых, не буду переносить эти сервисы назначенные к блокировке диапазоны, даже если они ещё доступны.

На мобильных версиях, как я понял, идёт постоянная доставка новых активных адресов взамен заблокированных. Доставка идёт через push, поэтому заблокировать её можно только всю сразу, для всех приложений. На дэсктопных версиях с этим сложнее. Например, текст грузится нормально, а вот картинки — уже с тормозами. Но как только включаю проксирование через TOR, всё становится нормально.

Томск, Ростелеком. Можно проверить ещё через Билайн и МТС, но мне, честно говоря, уже лень этим заниматься в такое время.

Мне — удобно. Я постоянно использую git. Но мне и ставить его под винду не надо — у меня линукс. А заказчику… Вы думаете, человек, который заказал парсер, а я именно на них специализируюсь, будет заинтересован в установке очередной неведомой херни? Зачем ему такое? Ему, зачастую, сложно объяснить, что такое интерпретатор и зачем его надо ставить. Нет уж, лучше я допишу ещё один скрипт на Python, интерпретатор которого я уже уговорил поставить и который, интерпретатор, ставится сам, без участия пользователя.

Параметры к синтаксису языка отношения не имеют, потому что это синтаксис параметров внешних, по отношению к оболочке, программ. Позже посмотрел синтаксис PowerShell — классический язык программирования с возможностью интерактивного использования. У питона такой есть, если просто запустить интерпретатор. В целом, где-то тут уже был комментарий с хорошим подведением итогов всего этого спора: Bash — интерфейс ОС, управляющий файлами и потоками, поэтому сравнивать его надо с cmd.exe, а PowerShell — интерфейс платформы .NET, поэтому сравнивать его надо с соответствующими утилитами.

Ну вот не нужны мне объекты, мне нужны имена файлов и их содержимое в виде текста. Потому что, если нужно что-то более сложное, я использую Python или другой язык программирования. PS — удобное средство для администрирования именно Windows. Оболочка для работы с объектами, интерфейс для платформы .NET, а не для ОС. Вчера кто-то разницу очень чётко расписал: Bash — интерфейс для ОС, для управления файлами и потоками, а PowerShell — интерфейс для платформы .NET и сравнивать его надо с другой утилитой.

Надо же! Я с утилитой ip не работал — надобности не было. Но тут стоит помнить, что PowerShell и его обвязку писала одна команда, а в *nix у каждой утилиты свои авторы и у многих синтаксис ключей тянется из древних времён, когда getopt ещё не приняли в качестве стандарта. Поверхностный поиск даёт дату принятия в районе 1985, а многие утилиты гораздо старше.

Та история, с которой начался спор, происходила тогда, когда даже Win8 ещё даже в проекте не была, а что касается установки Bash, то тут три причины и я их описывал:
1. Эта программа требует файлов конфигурации и, если не делать специальную сборку, придётся создавать песочницу, которая сильно всё попортит. Ну и не забываем, что сам по себе Bash — это просто «клей» или менеджер потоков, то есть понадобится установить ещё кучу всего.
2. Установка ЕЩЁ одной программы, а по факту — нескольких. И имена некоторых из них конфликтуют с уже имеющимися в системе. Например, юниксовый find внезапно называется так же, как убогий досовый, который доступен по умолчанию. Поскольку даже это убожество кем-то используется в пакетных файлах (потому что нормального по умолчанию нет), я не могу просто взять и переписать его. Собственно, отсюда и причина для морока с песочницей.
3. Пользователю часто и так тяжко поставить одну программу, которая ставится, по сути, сама. Я имею в виду интерпретатор Python. А Вы предлагаете ставить целый ворох непонятно чего, которое потом ещё и настраивать надо. Не, я лучше ещё один скрипт на питоне напишу: это будет быстрее, чем возиться с установкой Bash и компании ради перебора файлов. Если бы то же самое можно было бы делать на cmd, было бы вообще замечательно, но там синтаксис вообще какой-то кошмарный и циклы с ветвлениями — просто ад.

Про скрипты под виндой. 15 лет назад я пришёл в одну контору. Писали могучую систему для технических писателей. Писали на Java, но, по факту, всё было заточено под винду. Так вот, сборочные скрипты были написаны — тадам! — на Bash и Perl. Под виндой. 15 лет назад. С обязательными танцами с бубном вокруг Cygwin. Перетаскивание под *nix началось только через три года, когда пришёл запрос от Sun Microsystems.

Я вот только что смотрел синтаксис PS. Сложность написания соответствующего кода примерно на уровне такового на Java. А в Bash всё делается в 3-4 сроки, потому что там язык заточен именно под оперирование файлами и строками.

Это не демагогия, это факт. Но в Вашем варианте речь идёт об оперировании книгой как физическим объектом как набором объектов, его составляющих, а в моём — об оперировании текстовой информацией, составляющей содержания книги. Просто Ваш пример не имеет отношения к обсуждаемой теме.

Надо же! Всегда вызывал это меню просто кнопкой Win. А командная строка пользователям нужна, если в ней есть нормальная оболочка. Потому что удобно. Понятно, что о чём не знаешь, в том не нуждаешься. Но вот стоит такому «просто пользователю» показать удобства командной строки, как он начинает ею пользоваться. Может, не так активно, как я, но всё-таки.

Да вот как-то постоянно пишу. Для живых пользователей. А те, кто хочет просто кнопку «Сделать зашибись», получают такую кнопку. Только всё, что она делает, сообщает, что «Теперь всё зашибись». А кто хочет выполнения некоторой реальной работы, формулируют задание и обучаются использованию полученным инструментом. Подавляющее большинство клиентом очень довольно.

И вот так, не показывая пользователю, что есть какой-то инструмент (оболочка), мы потом жалуемся, что пользователь тупой и не знает, как работать с компьютером, которым он пользуется каждый день.

Чем что? Чем язык cmd.exe? Ну… есть немного, если не требуется работать с файлами в режиме оболочки. Синтаксис такой, что проще написать дополнительную программу на основном языке проекта. Если не требуется управлять ОС Windows. А мне надо было всего лишь сделать перебор файлов определённым способом.

Учитывая, что сейчас у меня в руках том формата А4 на 550 с хвостиком страниц со списками и таблицами, описывающими историю моих предков за больше чем 400 по материнской линии, видимо, всё-таки строками. Текстовый документ состоит из строк, если что. Обозвав директорию папкой, ни Вы, ни сочинители из Apple ничего не изменили. А вот путаницы двойная иерархия устроила много, потому что, как только возникает техническая задача, пользователь внезапно осознаёт, что всё строено иначе, чем показывает ему поделие MS. Потому что в реальном мире папка находится на столе, который стоит в кабинете и так далее, а стол является основой мироздания и вход в туалет, душ и архив, внезапно, находятся не на нём, а за дверью кабинета.

Ну… Я видел инженеров, настраивающих связь у абонентов, которые консолью пользоваться не умели. То есть виндовой консолью ещё как-то пользовались, а вот с Bash управиться не могли и моя жена им на пальцах объяснял. Замечу, это профессионал, то есть человек, которому за такую работу деньги платят, и домохозяйка, которая в Linux только кино смотрела, документы в OpenOffice правила и по интернету лазила.

Это к тому, что у нас выборки разные и слишком маленькие, чтобы быть репрезентативными. Я писал про своих клиентов, которых не особо затруднял запуск скрипта из командной строки в MacOS X. Был только один случай, когда заказчик с этим не справился. А вот те, кто пользуется Windows не справляются регулярно. Вплоть до того, что они не знают, что такое файл и что такое директория, что обнаруживается уже на этапе приёмки работы. Вплоть до того, что один явно изъявил согласие на интерфейс командной строки, не зная, что это такое.

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

Интересно. Надо будет как-нибудь повнимательнее разобраться с этой частью истории железа.

В обоих случаях это внешняя утилита и тут уже вопрос в том, как принято в конкретной ОС обозначать ключи. В DOS и Windows ключи идут после "/", а в *nix — после "-" (короткие) и после "--" (полная форма).

А аргумент про новый язык я не понял — баш же вы учили? Или он и является основным языком проекта?

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

Я понимаю, что можно сделать всё то же, что и на Bash, вопрос в синтаксисе. Мне он показался ничуть не более понятным, чем у cmd.exe, с которым я работал довольно много.

То есть, по сути, консоли у него нет. Потому что открыть КС для текущей директории можно и в Проводнике, чем я иногда пользуюсь. Просто TC — чисто GUI-шная программа, тогда как FAR работает в текстовом режиме, в том же самом эмуляторе терминала, который использует КС, поэтому он просто передаёт уже запущенной оболочке ввод и отображает её вывод. Ну или как-то так: я не знаю, как именно это реализовано, потому что в исходниках не копался, хотя они и доступны.

Я не про это. В MC всё точно так же, за исключением того, что не Ctrl-Enter, а Alt-Enter и имена с пробелами не заключаются в кавычки, а эти пробелы экранируются. Я имел в виду возможность вытряхнуть выделенные имена в командную строку стразу пачкой. И да, я знаю, что именно в FAR это есть, разве что не помню, как именно это делается, и сам им с удовольствием пользуюсь, когда надо разгребать горы файлов под виндой: на мой взгляд, ничего лучше под винду ещё не написали. А вот сборки MC под винду настолько убоги, что вызывают желание плакать и биться головой о клавиатуру, при том, что в родной среде он FAR-у не уступает, разве что нельзя туда прикрутить почтовый агент, но это уже извращение для любителей тонких изврашений.

Я через него могу общаться с ОС «человеческим» языком, используя как просто оболочку для повседневной работы? Вряд ли. Как мне только что сообщили, для вызова консоли с этим инструментом, надо нажать хитрую комбинацию клавиш, о которой я не знал, хотя регулярно вынужден кому-то что-то настраивать в винде, получить какую-то менюшку и в ней выбрать нужный пункт.

Второй момент — синтаксис. Не как отдельного языка программирования, а как оболочки, чей язык может быть прозрачно использован в качестве языка программирования. Если я правильно помню, синтаксис команд ветвления и циклов там такой же, как в cmd.exe, то есть довольно страшненький.

Вот это и называется тайненьким знаньицем: вместо того, чтобы вывесить программу в основное меню, её закопали в какое-то отдельное меню, запускаемое отдельной комбинацией клавиш. Как бы крут ни был этот инструмент, пока пользователи его не видят, он бесполезен. Даже я, вынужденный периодически заниматься настройкой компьютеров с виндой, не знал этого. Что уж говорить об обычных пользователя?

Он не хуже, потому что он для другого. Ещё раз, Bash — пользовательский интерфейс командной строки, PowerShell — инструмент для админа. На момент моего с ним знакомства, они был совершенно непригоден в качестве пользовательского интерфейса. А изучать ещё один язык для написания того, что я могу написать на основном языке проекта, было как-то не очень интересно. Если бы его синтаксис позволял проделать то, что легко делается в Bash, я бы написал скрипт и успокоился, но на тот момент это было невозможно.

Это всё аналоги программ, запускаемых из Bash. А вот синтаксис самого языка оказался настолько же невразумительным, как и у cmd.exe. И когда мне понадобился маленький довесок к уже сделанной работе, чтобы уже окончательно передать её заказчику, пришлось потратить дополнительное время и написать всё руками в Python. Хотя у меня такой довесок в Bash написался без проблем и был совершенно человекочитаемым.

Вы, вероятно, удивитесь, но ничего не разваливается. Можно использовать кавычки, можно выставить набор разделителей. Я постоянно работаю с кучей разных файлов. Недавно закончил проект, в котором приходилось работать с массивом файлов и там в именах директорий были пробелы. Почему-то ничего не развалилось. Что я делал не так? У меня всё собралось и залилось в базу под MariDB.

Особенности есть у всего. Не нравится Bash? Используйте csh, tcsh или любую другую оболочку из кучи имеющихся в репозиториях разных ОС и дистрибутивов.

Так смысл Bash не в том, чтобы уметь всё внутри себя, а в том, чтобы оперировать файлами, строками и внешними утилитами, которые уже сами что-то там делают. Инкапсуляция, однако.

Строки — это универсальный человекочитаемый формат. Содержимое строки можно проконтролировать глазами. Функция Bash — не администрирование отдельно взятого семейства ОС, а «клей» для организации взаимодействия между специализированными инструментами и общения пользователя с этими инструментами.

Как ни странно, многие. Вот я ни разу не админ, а пользуюсь. Потому что удобно. И, Вы не поверите, но в MacOS X рядовые пользователи тоже используют консоль, в которой — вот неожиданность! — запускается всё тот же Bash. А всё потому, что удобно. Потому что Bash, как я уже написал, оперирует теми же типами объектов, что и пользователь. Потому что он изначально — именно пользовательская оболочка.

Магнитные сердечники в 70-х? Вы не ошиблись? В 1966-1969 годах было принято решение о копировании IBM s/360, уже морально устаревавшей к тому моменту. Именно она стала основой ЕС ЭВМ, которая по-настоящему пошла в серию где-то в 1974 году. Магнитные сердечники — это несколько более ранняя технология. Первый вариант UNIX писался под DEC PDP-7, а стандартный Shell попал в состав UNIX только в 1977.

На Python можно, например, написать программу, не задумываясь о структуре конкретной ОС. Даже той, на которой пишешь эту программу. И она будет работать без явного привлечения системных библиотек. И даже будет работать на другой ОС. В частности, у меня таких случаев в практике, наверное, половина: пишу под Linux, потом всё работает под MacOS X или Windows. Но! Для того, чтобы что-то писать на Python или Bash, мне не нужно знать подноготную ОС, я просто запускаю внешние утилиты и передаю результат работы дальше по конвейеру. Ну и кое-какие инструменты по работе со строками доступны. А в PS надо прямо в недра системы лезть. Для чего он, собственно, и делался.

«Ужас» в том, что синтаксис PowerShell не особо предназначен для работы с ним человека без специальной подготовки, а потому он никогда не был оболочкой. И не будет. Это специальный язык программирования для администрирования системы.

Как раз наоборот: Bash оперирует теми же типом объектов, что и пользователь, то есть человек. Поэтому Bash — оболочка, а PowerShell — инструмент для администрирования, с которым обычный пользователь и не должен сталкиваться. Потому PowerShell не обязан быть удобным для ежедневного использования для чего-то отличного от управления объектами .NET, как написали выше.

Понял. Значит, сравнивать его с Bash и прочими «нормальными» оболочками некорректно, потому что это узкоспециализированный инструмент администратора, тогда как Bash — именно что пользовательская оболочка. Иначе бы он уже запускался именно в качестве общей оболочки, но даже в десятке этого нет — там по-прежнему в качестве оболочки командной строки используется cmd.exe.

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

Если же говорить о просто команде ls, то можно задать формат вывод и отработать его с помощью grep, egrep или sed — это уже по ситуации. А ещё можно скормить тоже команде ls выхлоп утилиты find, которой задать поиск файлов с ограничениями по времени.

Увы, не припомню такой. Разве что запуск, по сути, отдельного приложения «Командная строка», но это не то. Консоль там открывается одной комбинацией в директории текущей панели, работает с файлами из этой панели (например, передаются выделенные в панели файлы)? Подробности, как это делается в FAR, я сейчас не вспомню, помню только, что как-то делается, а вот в Midnight Commander достаточно использовать placeholder %s и выделенные файлы будут вставлены в командную строку.

Главное преимущество Bash (shl, csh, tcsh, ksh etc) в том, что это именно оболочка, команды которой можно «сложить» в файл и получится новая команда. Причём, сами команды легко читаются и понимаются «без перевода». Проблема command.com и его наследника cmd.exe в том, что вторая часть там реализована плохо: код, написанный на их программном языке читается с трудом, у них куча невразумительных конструкций, которые простым прочтением мануала не проясняются — надо ещё долго укладывать в голове какие-то странные многожтажные условные обозначения. Я понимаю, зачем это было в DOS: ресурсов было мало и надо было упихать в короткую строку как можно больше. Но этот синтаксис остаётся и сейчас. А PowerShell во многом его унаследовал, так что стройного языка не получилось.Какой этот синтаксис сейчас, я не знаю, но тогда, когда я пытался писать скрипты заказчикам, это был тихий ужас.

Если сейчас синтаксис PowerShell причесали — отлично, но пока он не станет «общим местом», пока именно он не начнёт запускаться при запуске «Командной строки», он будет такой же экзотикой, как Tcl, который безумно удобен для построения сложных комбинаций из самостоятельных программ, но, не являясь оболочкой, пользователям на глаза не попадается. И даже так: я тот же Tcl знаю, но, поскольку работаю в Bash, Bash мне на глаза первым и попадается/ F написать на нём короткий однострочник, для которого даже редактор запускать не надо, куда проще и быстрее, чем на Python или том же Tcl.

В WinXP его надо было ставить руками, насколько я помню. Если всё равно что-то ставить, то я предпочитаю интерпретатор нормального языка программирования. Опять же, как Вы сами указали, удобоваримым он стал с третьей версии, а я успел от него отказаться, ещё когда он, видимо, ещё из первой не вырос.

А про WinAPI я писал применительно к JScript и VB, которые могли бы претендовать на роль главного скриптового языка, но, поскольку средствами языка почти ничего не могли делать, пользы от них оказалось ноль: если я пишу что-то на Python, мне, в общем-то безразлично, в какой ОС я работаю, пока не натыкаюсь на специфику, которая разруливается через какие-то вызовы или переменные стандартных библиотек. То есть работа с сетью, включая самые распространённые транспортные протоколы, работа с диском и прочими «общими» функциями реализованы через стандартные библиотеки языка, а в том же JScript, насколько я помню, чтобы всё это делать, надо изучать ровно то же, что и при программировании на Си. И подключать все те же DLL поимённо. И зачем мне тогда скриптовый язык? Поэтому JScript, насколько я знаю, практически нигде не используется, а ниши VB — компилируемые программы и VBA, где он выполняется в контексте приложения, через реализованные в приложении интерфейсы, имеет доступ к его внутренним струкрурам.

А, Вы про этот набор. Ну так этого маловато: мне нужен был более широкий набор, а там уже без песочницы, видимо, не получается.

Пробовал работать с Cygwin и MSys2. В обоих случаях создаётся песочница, корневая директория, в которой всё и работает. Выход за её пределы возможен и сделать это не особо сложно, но всё равно это именно песочница. И все прелести такой организации прилагаются: дополнительные действия по перемещению корня куда-то, выход на корневые директории дисков Windows через какие-то странные структуры и так далее. Примерно такой же геморрой, как и при работе с WINE под Linux. Если мне нужны какие-то программы, у которых есть нормальные сборки под Windows, я не могу их использовать — система пытается установить то, что есть у неё в репозиториях, а это, зачастую, устаревшие на несколько лет версии. При этом, тянется, к примеру, собственная версия GTK, даже если у меня в системе уже есть программы, для которых установлена эта библиотека. То есть такая вот изолированная область с софтом в стиле *nix.

С GnuWin не сталкивался: полтора года назад этот продукт в поиске не попался. Но, думаю, там так же создаётся структура директорий, оформляющая файловую систему *nix, потому что программы ищут свои настроечные файлы в определённых местах.

Я тоже так делаю, когда приходится иметь дело с этой ОС на хоть сколько-то постоянной основе. Но эти утилиты работаю… не очень хорошо, потому что установка по умолчанию настраивает пути так, что они рассчитаны на работу в своей песочнице и вывести их на «просторы» основной файловой системы очень сложно. К тому же, у Windows отстойно реализованы конвейеры. Я полтора года назад работал в одной странной конторе, где на все машины была установлена винда и работать приходилось в ней, хотя всё, что я писал, должно было работать в Linux. В итоге, у меня была возможность сравнить работу этих утилит одновременно и в винде, и в Linux. Увы, даже на куда более мощной машине с Windows они работали гораздо медленнее, чем на слабенькой виртуалке и древнем нетбуке (моём личном).

Понятно, что на безрыбье и рак — рыба, но отсутствие вызова fork и нормальных конвейеров превращают сильно ломают работу таких привычных инструментов. Так изрядно портит впечатление то, что многие вещи устаревают на несколько лет, прежде чем попадают в этот комплект, а сборка из исходников чаще всего оказывается тем бегом по граблям. Не в последнюю очередь — по причине сильно устаревших утилит и библиотек.