Повторяюсь, я говорил лишь о том, что там где shell может решать задачу нужно использовать его, а не python. Я не говорю о том, чтобы писать биллинг на sh.
И если Вас не затруднит, расскажите пожалуйста, с какими система в 5000-10000 серверов Вы работаете.
Примеры моих неверных утверждений в студию. За исключением не верного варианта первого скрипта(о котором Вы не смогли устоять и сообщила аж целых два раза) и моего утверждения про пробел, не имеющего фактической смысловой нагрузки.
Хотя бы потому, shell скрипты быстрее python аналогов. Примеры сможете привести, для чего использовался python на этих серверах?
Примеры production систем, где нет awk привести можете?
Про java — говорим о python, так говорим о python.
production системы(nix) — freebsd, и несколько дистрибутивов linux. Которые суммарно покрывают 98% серверных установок nix систем. Принятно ставить системными администраторами, которые имееют порядочный опыт работы.
Bash был всегда sh compatible. Во всяком случае bash скрипты спокойно читались. О полном различии не может быть и речи.
Использование развивающихся, сырых, не достаточно проверенных систем обычно не принятно на production системах. Вы можете использовать их у себя на тестовых машинах, но не в продакшн. За примерами далеко ходить не стоит. Гонка за всем новым и современным зачастую ничего не приносит кроме энергии, потраченной на установку этого нового и решения проблем, принесеннымм этим новым. Повторяюсь, речь идет о production системах. У себя дома — можете городить что хотите.
Вы книгу читали? Можете привести пункты, с которыми не согласны? И желательно аргументировать.
Нет. На сервера принято ставитьтолько production системы, и всякие экзотические дистрибутивы к ним не относятся. А во всех боевых дистрибутивах awk есть.
Сырость заключается хотя бы в полной несовеместимости 2 и 3 ветки. Это достаточное условие.
С того, что Вы не понимаете или не хотите призновать того, что в ней говориться.
Мне кажется Вы просто не имеете опыта работа с большим количеством серверов и не знаете реалий. Вашу точку зрения я понял, и пытаться Вас переубедить — бесполезно, тем более что позиция Ваша достаточно откровенно выглядит глупой. Спасибо за Ваши ответы.
Принято писать на sh, а не каких-то других скриптах, потому что sh предоставляет необходимый минимальный функционал. И то что будет нормально работать на sh, с очень большой вероятностью будет работать и на других интерпретаторах.
>зарегистрированных через /etc/passwd (а это, понятно, не все пользователи)
приведите пример
Стандартный пул пользовательских uid'ов начинается с 1000.
Это не грязный хак, это реальное использование unix систем, и если Вы не умеете использовать базовые утилиты и каждый раз городите свой велосипед на языка программирования — Вы не понимаете UNIX.
Во всех production системах awk входит в base-system.
Python — слишком сырой и использовать его для простых серверных скриптов может только фанатик.
Если Вы не знаете базовых утилит unix — Вам лучше с ним распрощаться навсегда. Вам было бы полезно ознакмоиться с идеологией UNIX. Могу посоветовать книгу Эрика Рэймонда — «Искусство программирования в UNIX».
В моем выражении черт ногу не сломит, а в Вашем — да. Полагаю Вы согласитесь с тем, что «черт ногу сломит» зависит только от того, кто пишет. И не более.
Потому что sh без сторонних программ — не дает толком ничего. shell является прослойкой между терминалом пользователя и сторонними програмами, которые являются частью base-системы и которые представляют всю мощь программирования на shell. И их функционал достаточен практически для любого ряда задач. Повторяю еще раз, читаемость кода ни столько заслуга самого языка, а сколько того, кто на нем пишет. На любом языке(кроме гик-язкыков) можно писать как понятно, так и нет. Надеюсь примеров приводить Вам не нужно.
Про синтаксис и квадратные скобочки — не смешите, если Вы настолько приверженец c-based синтаксиса, то от python Вас просто должно воротить.
(for (xxx in yyy) {}) — пишется два цикла и все.
Повторяюсь, тот круг задач, который обычно решают shell сценарии решается ими хорошо и прикручивание сбоку избыточного функционала, что порождает за собой существование лишних сущностей — в корне не правильно.
Вот так и знал, что Вы стороник python. Вы предлагаете ставить на каждый сервер python?
Синтаксис наооборот — наиболее простой, конечно если не стараться все запутать, впрочем это можно сделать на любом языке. Любые Вещи делаются приятнее? А сделайте мне, вот такой простой аналог на python `cat /etc/passwd | awk -F ':' '$1>1000{$print $3}' | sort -r`. Говорите приятнее? Про использование повторно — вообще не понял. Что Вы shell скрипты повторно использовать не можете? А короткие команды можно и в alias загнать. Если Вы имели ввиду использование библиотек, то кто Вам мешает подключать другие shell сценарии в свой? Только что не знание того, что это можно делать.
Shell — стандарт серверных скриптов и слава богу, python'y до этого еще далеко. Единственное причина, из-за которой можно уходить от shell — необходимость реализации более сложной логики в скриптах. Но никто не говорит, писать различные engine или биллинг на sh.
И если Вас не затруднит, расскажите пожалуйста, с какими система в 5000-10000 серверов Вы работаете.
Примеры моих неверных утверждений в студию. За исключением не верного варианта первого скрипта(о котором Вы не смогли устоять и сообщила аж целых два раза) и моего утверждения про пробел, не имеющего фактической смысловой нагрузки.
Хотя бы потому, shell скрипты быстрее python аналогов. Примеры сможете привести, для чего использовался python на этих серверах?
Примеры production систем, где нет awk привести можете?
Про java — говорим о python, так говорим о python.
Bash был всегда sh compatible. Во всяком случае bash скрипты спокойно читались. О полном различии не может быть и речи.
Использование развивающихся, сырых, не достаточно проверенных систем обычно не принятно на production системах. Вы можете использовать их у себя на тестовых машинах, но не в продакшн. За примерами далеко ходить не стоит. Гонка за всем новым и современным зачастую ничего не приносит кроме энергии, потраченной на установку этого нового и решения проблем, принесеннымм этим новым. Повторяюсь, речь идет о production системах. У себя дома — можете городить что хотите.
Вы книгу читали? Можете привести пункты, с которыми не согласны? И желательно аргументировать.
Сырость заключается хотя бы в полной несовеместимости 2 и 3 ветки. Это достаточное условие.
С того, что Вы не понимаете или не хотите призновать того, что в ней говориться.
приведите пример
Стандартный пул пользовательских uid'ов начинается с 1000.
Это не грязный хак, это реальное использование unix систем, и если Вы не умеете использовать базовые утилиты и каждый раз городите свой велосипед на языка программирования — Вы не понимаете UNIX.
Python — слишком сырой и использовать его для простых серверных скриптов может только фанатик.
Если Вы не знаете базовых утилит unix — Вам лучше с ним распрощаться навсегда. Вам было бы полезно ознакмоиться с идеологией UNIX. Могу посоветовать книгу Эрика Рэймонда — «Искусство программирования в UNIX».
Вот что я имел ввиду, просто было поздно.
В моем выражении черт ногу не сломит, а в Вашем — да. Полагаю Вы согласитесь с тем, что «черт ногу сломит» зависит только от того, кто пишет. И не более.
-rwxr-xr-x 1 root 38K Jun 17 2008 /usr/bin/[
ubique@ubique ~ $ ls -ahlo /usr/bin/test
-rwxr-xr-x 1 root 26K Jun 17 2008 /usr/bin/test
ubique@ubique ~ $ uname -o
GNU/Linux
Про синтаксис и квадратные скобочки — не смешите, если Вы настолько приверженец c-based синтаксиса, то от python Вас просто должно воротить.
(for (xxx in yyy) {}) — пишется два цикла и все.
Повторяюсь, тот круг задач, который обычно решают shell сценарии решается ими хорошо и прикручивание сбоку избыточного функционала, что порождает за собой существование лишних сущностей — в корне не правильно.
Синтаксис наооборот — наиболее простой, конечно если не стараться все запутать, впрочем это можно сделать на любом языке. Любые Вещи делаются приятнее? А сделайте мне, вот такой простой аналог на python `cat /etc/passwd | awk -F ':' '$1>1000{$print $3}' | sort -r`. Говорите приятнее? Про использование повторно — вообще не понял. Что Вы shell скрипты повторно использовать не можете? А короткие команды можно и в alias загнать. Если Вы имели ввиду использование библиотек, то кто Вам мешает подключать другие shell сценарии в свой? Только что не знание того, что это можно делать.
Shell — стандарт серверных скриптов и слава богу, python'y до этого еще далеко. Единственное причина, из-за которой можно уходить от shell — необходимость реализации более сложной логики в скриптах. Но никто не говорит, писать различные engine или биллинг на sh.