Comments 33
python и bash — повседневное использование, вместо IPython использую стандарный пакет
Что-то так и не понял назначение Sleep Dummy Shell
Указанный запрет доступа к командной строке достигается ключом -N самого ssh, либо /bin/false или /bin/nologin в качестве шелла
Указанный запрет доступа к командной строке достигается ключом -N самого ssh, либо /bin/false или /bin/nologin в качестве шелла
сам не пробовал, но на сайте sleepshell пишут:
Setting the account shell to something like /bin/false (or any other simple programs) usually won't work because the tunnel is closed as soon as the program finish its execution. Sleep Dummy Shell just sleeps until its execution is terminated by the user or the tunnel is closed.
Setting the account shell to something like /bin/false (or any other simple programs) usually won't work because the tunnel is closed as soon as the program finish its execution. Sleep Dummy Shell just sleeps until its execution is terminated by the user or the tunnel is closed.
Так а в чем приемущество «спящего» шела, если ничего кроме как проброса порта не доступно в обоих вариантах?
sleepshell приглашение печатает c адресами, портами и именем терминала
и звездочки еще, красиво и keep alive своего рода
прошу прощения, если мой вопрос глуп, но /bin/false должен же завершиться сразу после запуска и ssh сессия развалится?
и звездочки еще, красиво и keep alive своего рода
прошу прощения, если мой вопрос глуп, но /bin/false должен же завершиться сразу после запуска и ssh сессия развалится?
Вариант с ssh -N не подходит, т.к. сторонний пользователь может использовать этот ключ, а может и не использовать — и тогда получит командную строку. Если указать в профиле пользователя что-то нечленораздельное вроде /bin/nothing, то не получится сделать вообще ничего, т.к. сессия будет мгновенно закрываться.
Кто-нибудь пользуется rush (ruby shell)?
а почему не остановились на zsh? Хотя бы ссылку на конфиги GRML приожили бы, ведь одна из мощных оболочек для режима интерпретатора
Groovy Shell for the win (-:
Примеры для IPython слабоваты: не показывают преимуществ пред bash. Вот пример последовательного пинга 10 хостов на bash:
~$ for i in `seq 100 110`; do ping -c 1 192.168.0.$i; done
Rush или просто irb (Interactive Ruby):
(100..110).each { |n| `ping -c 1 192.168.0.#{n}` }
Пример (и у вас и у ниже отписавшегося akzhan) не эквивалентен тому, что наверху: в Python
Ipython — просто штука, в которой иногда удобно по‐быстрому проверить работоспособность кода на Python. Ещё хорошо использовать как калькулятор. Возможность вызывать оболочку — просто приятное дополнение.
Соответственно преимущества перед bash — те же, что и у самого Python. Преимущества именно как замены /bin/bash в /etc/passwd — отсутствуют, он даже не дополняет команды из $PATH, только имена файлов.
range(n, n+k) возвращает [n, n+1, …, n+k-1]. Не […, n+k].Ipython — просто штука, в которой иногда удобно по‐быстрому проверить работоспособность кода на Python. Ещё хорошо использовать как калькулятор. Возможность вызывать оболочку — просто приятное дополнение.
Соответственно преимущества перед bash — те же, что и у самого Python. Преимущества именно как замены /bin/bash в /etc/passwd — отсутствуют, он даже не дополняет команды из $PATH, только имена файлов.
Не устаю пропагандировать xargs:
которая лёгким движением руки становится многопоточной:
seq 100 110|xargs -n 1 -I ADDR ping -c 192.168.0.ADDR
которая лёгким движением руки становится многопоточной:
seq 100 110|xargs -P 10 -n 1 -I ADDR ping -c 192.168.0.ADDR
Изящно. Про параллельны вариант не знал…
Но xargs — это механизм скриптинга под sh-совместимые оболочки, а я пытался показать как нам сделать все кроме ping на питоне. Если выбирать любой инструмент, то лучшим выбором имхо был бы «nmap -sP 192.168.0.100-110», и параллельно и вывод симпатичнее
Но xargs — это механизм скриптинга под sh-совместимые оболочки, а я пытался показать как нам сделать все кроме ping на питоне. Если выбирать любой инструмент, то лучшим выбором имхо был бы «nmap -sP 192.168.0.100-110», и параллельно и вывод симпатичнее
Не работает:
~$ seq 100 110|xargs -n 1 -I ADDR ping -c 192.168.0.ADDR
Usage: ping [-LRUbdfnqrvVaAD] [-c count] [-i interval] [-w deadline]
[-p pattern] [-s packetsize] [-t ttl] [-I interface]
...
Согласен, примеры похоже не самые удачные. Придумывал такие, чтоб покороче, попроще…
Но, субъективное преимущество перед bash: есть много людей, которые знают Python, и им будет проще на нем и писать, чем запоминать, как правило не очевидные, конструкции bash.
И, субъективное преимущество перед Python: лаконичность выполнения системных команд. Сравните
Но, субъективное преимущество перед bash: есть много людей, которые знают Python, и им будет проще на нем и писать, чем запоминать, как правило не очевидные, конструкции bash.
И, субъективное преимущество перед Python: лаконичность выполнения системных команд. Сравните
>>> import os
>>> l = os.popen("ls -l").read()
l = !ls -l
Ну раз уж про bash, то и пользоваться башевым генератором последовательностей:
for i in {100..110}; do ping -c 1 192.168.0.$i; done
Наброшу немного про why not csh: www.faqs.org/faqs/unix-faq/shell/csh-whynot/
А нет ли шела, с так скажем cisco like дополнением? Т.е. когда вместо «show ip route» пишется «sh ip ro», и нет необходимости нажимать Tab для дополнения каждого слова, система автоматически находит если сокращение однозначно.
В zsh для директорий такое есть.
Не думаю, что это вообще возможно.
В CLI cisco мы вводим именно команды и единый интерпретатор отвечает за их разбор, а в linux первое слово — это, как правило, название программы, а остальные — ее параметры и как с ними работать программа решает сама.
К слову, iproute2 поддерживает нечто подобное.
Вместо
В CLI cisco мы вводим именно команды и единый интерпретатор отвечает за их разбор, а в linux первое слово — это, как правило, название программы, а остальные — ее параметры и как с ними работать программа решает сама.
К слову, iproute2 поддерживает нечто подобное.
Вместо
~$ ip address add
~$ ip a a
Интересно, консоль в стиле Quake — чисто гуевая или что-то консольное с прикрученным плюшками?
И странно, почему забыли консольки типа ios cli (cisco) — помнится, что ios у нас на линуксе, а junos на BSD — несколько лет назад умельцы в Украине чисто ради веселья воткнули на juniper какой-то из графических толи WM, толи DE, врать не буду, но верю, что это в принципе возможно — тот же cico ACS или vmware venter — linux based, о чем честно пишется при запуске машин. При соответствующем вмешательстве в скрипты запуска и там и там можно получить не относящиеся к основному функционалу плюшки.
И странно, почему забыли консольки типа ios cli (cisco) — помнится, что ios у нас на линуксе, а junos на BSD — несколько лет назад умельцы в Украине чисто ради веселья воткнули на juniper какой-то из графических толи WM, толи DE, врать не буду, но верю, что это в принципе возможно — тот же cico ACS или vmware venter — linux based, о чем честно пишется при запуске машин. При соответствующем вмешательстве в скрипты запуска и там и там можно получить не относящиеся к основному функционалу плюшки.
iOS уже тоже на BSD, т.к. сейчас так называется уже ОС установленная на iPhon/iPad/iTouch
А Cisco IOS на сколько я помню не имеет к Unix\Linux отношения. Во всяком случае что в Cisco IOS что в Junos CLI нельзя назвать системной командной оболочкой. Это принципиально другое. Помню, на каких-то сетевых устройствах (не Cisco и не Juniper), была даже команда, чтоб из собственного CLI вывалится в системный shell.
А Cisco IOS на сколько я помню не имеет к Unix\Linux отношения. Во всяком случае что в Cisco IOS что в Junos CLI нельзя назвать системной командной оболочкой. Это принципиально другое. Помню, на каких-то сетевых устройствах (не Cisco и не Juniper), была даже команда, чтоб из собственного CLI вывалится в системный shell.
Под OS X есть терминал в стиле квейковой консоли. Верней плагин к стандартному терминалу.
На С# в Linux можно тоже скрипты писать:
gluttton@lx:~> cat > script.sh << EOF
> #!/usr/bin/csharp
>
> System.Console.WriteLine ("Bingo!");
> EOF
gluttton@lx:~> chmod +x script.sh
gluttton@lx:~> ./script.sh
Bingo!
gluttton@lx:~>
Sign up to leave a comment.
О разных командных оболочках Linux и Unix