Насколько вы хорошо умеете пользоваться командной строкой?

О, хорошо что этот вариант на два разбили, «Умею писать сложные скрипты» и «Знаю малейшие нюансы работы shell» это всё таки разное. Ну а я умею писать сложные скрипты. Правда делаю это довольно редко, чаще пишу простые, а для более сложного использую питон, но уметь умею.

читал ABSS guide и даже смотрел оба LinuxCBT bash, но после имплементации нескольких сложных рекурсивных алгоритмов на bash купил книгу по пайтону, и теперь живу в нем. Это как классифицировать?

На работе живу в шелле, пишу большие скрипты. Дома почти не вижу его.

Нюансы не знаю и не хочу - там какая-то наркомания. Хотел свой шелл написать для понимания, но заглянул в posix... и забил.

Tmux очень часто запущен... Подскажите знатоки, в чём разница между

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

«малейшие нюансы» это те о которых в мане не написано?

Запускаю иногда приложения, чаще копируя откуда-то

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

У меня mac. Что такое командная строка? Зачем она, если есть автоматор? :)

Умею писать сложные скрипты

Первый вариант короче, а второй надёжнее. В zsh ещё можно смотреть опцию interactive.

Не пользуюсь, потому что нет надобности.

Часто работаю с командной строкой

и

Умею писать простые скрипты

потому что

Знаю базовые команды

Ответил «Умею писать простые скрипты», хотя где грань между простыми и сложными?

У меня mac. Что такое командная строка?

У Вас какой-то неправильный mac, на нем наверное наклейка windows, срочно верните продавцу, а лучше сразу обращайтесь в защиту прав потребителей.

но после имплементации нескольких сложных рекурсивных алгоритмов на bash купил книгу по пайтону, и теперь живу в нем

Мне кажется, сложные алгоритмы в BASH реализуются совсем обычным для большинства языков программирования образом, хотя, безусловно, нужно следить за областью видимости переменных, что в BASH не очень удобно. Проблема скорее в том, что при глубокой рекурсии BASH любит отжирать немеряно памяти, а при сверх-глубокой - попросту падать (наверное, OOM killer его тяпает).
С точки зрения алгоритмизации в BASH два существенных недостатка и один не очень существенный, хотя и досадный:
1) BASH работает безумно медленно в сравнении с, казалось бы, более сложными интерпретируемыми языками (я, например, программирую на Perl и вижу разницу)
2) Отсутствие механизма ссылок за исключением очень куце и убого реализованного механизма символических ссылок просто не позволяет строить сколько-нибудь сложные структуры данных
Ну и малосущественный (в связи с пунктом 1) недостаток:
3) Полное(!!) отсутствие поддержки чисел с плавающей запятой

Насчёт Python'а - его тотальное навязывание богомерзкого ООП и «код шашечками» меня не устраивают, так что нет альтернатив Perl'у кроме R для сложной математики :)

он пять минут пилит питонячий скрипт.

Мда. А вообще для этого есть dsh (distributed shell). Ну и хотелось бы невзначай упомянуть MPI. Знаете, оно умеет много чего, не имеющего отношения к математике ;)
Ну и, повторюсь, Питон - это зло, что прекрасно видно по тому как большинство программистов на Питоне реализуют логирование (чаще всего никак).

Не, ну там единичный таск, подобное нужно крайне редко, поэтому в mpi смысла нет совсем (у нас и так головы пухнут). А так можно и pssh заюзать было, или просто зайти на ноду и в цикле запустить vzctl exec с переводом в бэкграунд.

в принципе да, рекурсия делается так же как и везде - функция которая вызывает сама себя, плюс правило остановки, как в старом добром прологе. Только когда рекурсия уходит слоев на 15 вглубь, и в каждом гоняет тяжелые операции которые сами по себе могут провалиться (в моем случае qemu-img convert времен rhel 5.1), то можно слегка офонареть пока все не отладишь. с пайтоном все таки попроще и поудобнее.

Что же касается самого пайтона, то мне он кажется намного более протым чем перл в освоении, и ООП далеко не обязателен, хотя и удобно, когда код начинает расти до настоящих программ. Плюс развитие у языка настолько динамочное, что можно при желании переписывать основные модули и получать свои наработки в мейнстриме, как наш betterThreading например