LINUX.ORG.RU
ФорумTalks

Чего только не напишешь на bash...


0

0

Вот, к примеру, сейчас, подумав пару минут, сделал минимальный аналог netcat из одной строчки (нужно было с одного хоста подсоединиться к другому по smtp для проверки, ни telnet-а, ни nc там не было):

(cat <&2 & cat >&2) <>/dev/tcp/hostname/port 1>&0

Это я к чему: unix-принцип построения системы ОЧЕНЬ гибок и позволяет довольно эффективно решать большинство задач (даже не совстем стандартных) с минимальными усилиями. Веднузятникам такое и не снилось :)

★★

В огороде бузина, а в Киеве дядька.

Teak ★★★★★
()

А им это и не нужно:

Весь мир разделился: думающие пользуют линукс, глупцы виндовс. И не надо их ПЕРЕМЕШИВАТЬ, запутаемся.

soomrack ★★★★★
()

Надо было на лиспе, скобок бы больше было. А так - как-то несолидно.

bugmaker ★★★★☆
()
Ответ на: комментарий от soomrack

Пока ещё не разделился. Вот когда будут зверинцы для вендузятнегоф делать...

bugmaker ★★★★☆
()

Кто-то писал на bash виртуальную машину.

Lockywolf ★★★
()

> (cat <&2 & cat >&2) <>/dev/tcp/hostname/port 1>&0

me ~$ ls -l /dev/tcp
ls: /dev/tcp: No such file or directory

К чему бы это? Где копать?

pv4 ★★
()

>Это я к чему: unix-принцип построения системы ОЧЕНЬ гибок и позволяет довольно эффективно решать большинство задач (даже не совстем стандартных) с минимальными усилиями. Веднузятникам такое и не снилось :)

[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]

С подогревом. Автоматический. С проигрыванием огг-файлов :))

Кури "Just For Fun"

Doom3r
()

Аха, я тоже в одну строчку bash уложил целый редактор, не хуже kwrite, делюсь с вами:

>kwrite

applesin
()

У меня тоже /dev/tcp нету.

Linux 2.6.17, /dev делается udev'ом. Slav, не поделишься, откуда /dev/tcp брать?

anonymous
()
Ответ на: комментарий от pv4

> К чему бы это? Где копать?

Копать в man bash. Перенаправления в файлы /dev/tcp/, /dev/udp/, /dev/fd/ bash обрабатывает сам, открывая соответствующий сокет или копируя соответствующий дескриптор.

slav ★★
() автор топика
Ответ на: комментарий от slav

В смысле реально в ФС /dev/tcp быть и не должно. Баш это интерпретирует как "открыть сокет с таким-то хостом на такой-то порт и подсунуть дескриптор процессу".

slav ★★
() автор топика

Ну не понимаю я людей, которые пишут на шелле... Да, для вещей типа того, что из первого сообщения он подходит, но имхо если размер проги превышает 20 строк то следует всё же выбрать нормальный язык из (Python/Perl/Lisp/Haskell/Ruby/PHP/erlang/по вкусу, извините если что забыл, что-то туплю).

Удобность POSIX - регэкспов впечатляет - я обожаю писать [:digit:] вместо \d

Постоянные проблемы с переменными содержащими пробел при передачи их дочерним скриптам в качестве параметров (тут возможно у меня кривые руки)

Очень компактный синтаксис:

if [ "$z" = "$s" ];then echo equ;fi

все пробелы обязательны

*-expansion, который по дефолту пропускает скрытые файлы в лучших традициях explorer.exe

О производительности shell скритов вообще говорить не хочется - это ж fork + exec на каждый чих + постоянная пересылка по пайпам всех данных; правда производительность обычно и не требуется.

И наконец, то, что меня бесит больше всего - шелл представляет из себя типичное all-in-one приложение, что абсолютно противоречит Unix-way:
ну зачем пихать в одну программу такие ничем не связанные вещи как редактирование командой строки и её исполнение? Что мне делать если мне нравится автодополнение в zsh, но нет желания использовать его синтаксис, а пользоваться башевским... Почему до сих пор редактор не вынесен в отдельную пограмму?

И наконец, когда же в хоть в каком-нибудь интерактивном шелле сделают подсветку синтаксиса... 21 век на дворе...

GPFault ★★
()
Ответ на: комментарий от GPFault

Напиши свой/переделай под себя существующий, делов-то. Исходники все есть.

anonymous
()
Ответ на: комментарий от slav

Из man bash:

NOTE: Bash, as packaged for Debian, does not support using the /dev/tcp and /dev/udp files.

Секьюрити ризэнс? Netcat'a нормального нет, bash /dev/tcp не поддерживает... кошмар ;)

PashaKustov ★★
()
Ответ на: комментарий от GPFault

> *-expansion, который по дефолту пропускает скрытые файлы в лучших традициях explorer.exe

А скрытые файлы на то и скрытые, чтоб перед глазами не маячили. Их не садомазохисты придумали. shell изначально был инструментом пользователя, а он 90% времени работает НЕ с конфигами.

> шелл представляет из себя типичное all-in-one приложение, что абсолютно противоречит Unix-way:

Если шелл противоречит Unix-way, то я тогда даже не знаю... Пойду напьюсь с утра :)

> зачем пихать в одну программу такие ничем не связанные вещи как редактирование командой строки и её исполнение?

Потому что редактирование строки это задача, которая совершенно не тянет на отдельное приложение.

> когда же в хоть в каком-нибудь интерактивном шелле сделают подсветку синтаксиса...

Могу ошибаться, давно смотрел, но у fish, вроде была: http://roo.no-ip.org/fish/

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от GPFault

> Да, для вещей типа того, что из первого сообщения он подходит, но имхо если размер проги превышает 20 строк то следует всё же выбрать нормальный язык

Не всегда. Если в требуется многократно вызывать внешние программы (с перенаправлением ввода/вывода, подстановкой аргументов и т. д.), то делать это на shell на порядки проще чем на языках общего назначения. Собственно, он для этого и делался, и "форк на каждый чих" (там, где это нужно) в нём делается значительно проще чем в прочих языках. Шелл и писался, вообще говоря, как средство для обеспечения взаимодействия между внешними программами.

> Удобность POSIX - регэкспов впечатляет - я обожаю писать [:digit:] вместо \d

Флаг -P у grep-а ниасилили?

> И наконец, то, что меня бесит больше всего - шелл представляет из себя типичное all-in-one приложение, что абсолютно противоречит Unix-way:

В таком случае, 'perl/python/(другой язык по вкусу) представляет из себя типичное all-in-one приложение, что абсолютно противоречит Unix-way' - там же то, для чего в bash используются внешние программы (регулярные выражения к примеру) засунуто в сам язык (ну или стандартную библиотеку). Всё-таки при разделении системы на части надо остановиться в разумном месте, а не доводить всё до предельного случая.

slav ★★
() автор топика
Ответ на: комментарий от soomrack

Это кого ты думающими людьми назвал? Тех, кто, согласно опроса, сидит за компом по 10+ часов в сутки? Спасибо, посмешил.

Energizer
()
Ответ на: комментарий от Energizer

Не понял, что ты имеешь против тех, кто сидит >10 часов в сутки за компом? Что за странные выпады?

Teak ★★★★★
()
Ответ на: комментарий от Teak

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

Energizer
()
Ответ на: комментарий от Energizer

И все твои возражения будут его только подтверждать

bugmaker ★★★★☆
()

slav а если бы там и bash не было ??? LOL вот в plan9 этот принцип ВЕЗДЕ . Советую :) ознакомится.

robot12 ★★★★★
()
Ответ на: комментарий от Energizer

>шаблон "линуксоиды - умные, виндузятники - ламеры" так и хочется возразить.

Увы но в 80% случаев именно так и есть.

robot12 ★★★★★
()
Ответ на: комментарий от Energizer

> согласно опроса

"Согласно опросу", вообще-то. Велики и могуче русской языка.

Sikon ★★★
()
Ответ на: комментарий от watashiwa_daredeska

>Потому что редактирование строки это задача, которая совершенно не тянет на отдельное приложение.

Насколько я знаю очень значительная часть zsh это именно реализация интерактивного редактирования - хитрое автодополнение, работа с историей и т.д.

>Могу ошибаться, давно смотрел, но у fish, вроде была: http://roo.no-ip.org/fish/

Спасибо

GPFault ★★
()
Ответ на: комментарий от Energizer

>Никого не хотел задевать
>Это кого ты думающими людьми назвал?
У тебя зашибись как получилось :-)

anonymous
()
Ответ на: комментарий от slav

>В таком случае, 'perl/python/(другой язык по вкусу) представляет из себя типичное all-in-one приложение, что абсолютно противоречит Unix-way' - там же то, для чего в bash используются внешние программы (регулярные выражения к примеру) засунуто в сам язык (ну или стандартную библиотеку).

Разумеется perl/python/(другой язык по вкусу) ещё менее unix-way, но они и не позиционируются так.

>Всё-таки при разделении системы на части надо остановиться в разумном месте, а не доводить всё до предельного случая.

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

GPFault ★★
()
Ответ на: комментарий от robot12

>шаблон "линуксоиды - умные, виндузятники - ламеры" так и хочется возразить.

Действительно, среди линуксоидов аж треть - ламеры. Но под виндами-то их 100%

anonymous
()
Ответ на: комментарий от PashaKustov

Ну... Не знаю... Может конечно и правда что-то не так, а может руки. За проксёй не сидел, мне это без надобности.

Если знаешь в чём баг - пошли им багфикс, если нет - то и говорить не о чём.

Teak ★★★★★
()
Ответ на: комментарий от PashaKustov

Можно поподробнее? Посмотрел, в Дебиане и FreeBSD неткат собирается из одного и того же дистфайла, хотя конечно и там и там свои патчи есть. Ты хочешь сказать, что в Дебиане специально прокси поломали патчами?

Сорри, у меня прокси правда нет, а поднимать ради этого лень, а то бы проверил.

Teak ★★★★★
()
Ответ на: комментарий от Teak

В общем-то у меня тоже его давно нет ;) Надо было в прошлом году, чтобы лазить из колледжа через проксяк на домашний комп через SSH который висел на порту 443 :P

Во FreeBSD это достигалось путём добавления в ssh_config строчек типа /usr/bin/nc -X connect -x 192.168.38.28:3128....

В Дебиане ключика -Х нет вообще, а -х означает совсем другое.

Вот nc -h из Debian:
[v1.10]
connect to somewhere: nc [-options] hostname port[s] [ports] ...
listen for inbound: nc -l -p port [-options] [hostname] [port]
options:
-c shell commands as `-e'; use /bin/sh to exec [dangerous!!]
-e filename program to exec after connect [dangerous!!]
-b allow broadcasts
-g gateway source-routing hop point[s], up to 8
-G num source-routing pointer: 4, 8, 12, ...
-h this cruft
-i secs delay interval for lines sent, ports scanned
-k set keepalive option on socket
-l listen mode, for inbound connects
-n numeric-only IP addresses, no DNS
-o file hex dump of traffic
-p port local port number
-r randomize local and remote ports
-q secs quit after EOF on stdin and delay of secs
-s addr local source address
-t answer TELNET negotiation
-u UDP mode
-v verbose [use twice to be more verbose]
-w secs timeout for connects and final net reads
-x tos set Type Of Service
-z zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi [inclusive];
hyphens in port names must be backslash escaped (e.g. 'ftp\-data').


А вот из FreeBSD:

usage: nc [-46DEdhklnrStUuvz] [-e policy] [-i interval] [-p source_port]
[-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_version]
[-x proxy_address[:port]] [hostname] [port[s]]
Command Summary:
-4 Use IPv4
-6 Use IPv6
-e policy Use specified IPsec policy
-E Use IPsec ESP
-D Enable the debug socket option
-d Detach from stdin
-h This help text
-i secs Delay interval for lines sent, ports scanned
-k Keep inbound sockets open for multiple connects
-l Listen mode, for inbound connects
-n Suppress name/port resolutions
-P proxyuser Username for proxy authentication
-p port Specify local port for remote connects
-r Randomize remote ports
-S Enable the TCP MD5 signature option
-s addr Local source address
-T ToS Set IP Type of Service
-t Answer TELNET negotiation
-U Use UNIX domain socket
-u UDP mode
-v Verbose
-w secs Timeout for connects and final net reads
-X proto Proxy protocol: "4", "5" (SOCKS) or "connect"
-x addr[:port] Specify proxy address and port
-z Zero-I/O mode [used for scanning]
Port numbers can be individual or ranges: lo-hi [inclusive]
See ipsec_set_policy(3) for -e argument format

PashaKustov ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.