AVKor, ничего я не разбил. Вопрошающий не понимал, как вывод "цепочки" комманд передать в цикл. Как в "цепочке", так и в самом цикле могли быть более сложные действия.
Это, к слову, не единственный вариант, можно было сделать и так:
while read line
do
...
done < <(cat sorted | cut -f 1 -d ' ' | uniq)
Более того, в некоторых задачах так даже лучше, потому что в первом варианте цикл запускается в subshell, а во втором в subshell запускается "цепочка" (хотя это можно переопределить опцией lastpipe).
Omolix, чтобы пользователем root присоединиться к базе testbase, надо сделать mysql -uroot testbase. Или выполнить в клиенте mysql команду use testbase;
Соответственно, что удаётся присоединиться к базе root пользователем root не имеет никакого отношения к невозможности присоединиться к базе testbase.
WiNNeR_tig, например, в telebot это message_handler, плюс регулярно делать запрос к базе и делать send_message.
upd: хотя в вопросе тэг php, в библиотеках Телеграма для php я не разбираюсь. Если использовать API напрямую без библиотек, то это getUpdates для забора новых сообщений с сервера и sendMessage для посылки их в Телеграм. Или вместо getUpdates настраивать webhook.
WiNNeR_tig, можно. Заводишь бота, добавляешь его в чат, в коде бота пишешь, чтобы новые сообщения пользователей вставлялись в общую с сайтовым чатом базу. Также можно из этой базы извлекать новые сообщения с сайта и постить их в чат в Телеграме. Одно из самых простых решений этой задачи.
Roman Kitaev, спасибо за такую показательную successfully fail story. Всегда пользовался pip (для моего уровня несложности его более чем хватает), но, не единожды видя похвалы pipenv, уже подумывал, что, быть может, пора вляпаться во что-то новое?
На exit-ноде можно прочитать и модифицировать только нешифрованный трафик. Почему https не спасёт? Конечно, на exit-ноде можно определить по SNI куда идёт трафик (доменное имя), но откуда он пришёл уже будет непонятно, он же прилетает от неких промежуточных посредников.
При обычном способе работы если нам нужно выполнить сто запросов, то мы по очереди делаем запросы. При этом сами запросы и обработка ответов занимает допустим 10 мс, а ещё 90 мс занимает отправка по сети, ожидание ответа и всё такое. В итоге один запрос - 100 мс, всего 10 запросов в секунду.
При асинхронном способе работы мы можем отправить сразу 10 запросов, далее ожидать по каждому 90 мс ответа одновременно, в итоге мы потратим 100 мс на нашу работу (генерация запросов плюс обработка ответов) и 90 мс на ожидание, 10 запросов за 190 мс.
Конечно, не всё так просто и вовсе необязательно эффективность будет настолько высокой, но в целом принцип такой. Правда, попытки написания асинхронного кода с непривычки могут прилично взорвать мозг. И если там не будет реальной параллельной работы, все эти ухищрения могут оказаться бессмысленны и даже вредны.
