shurshur

Телеграм кэширует preview ссылок. Поэтому бесполезно менять что-то на сайте, когда он уже запомнил не то, что нужно.

Решение: находим бота WebpageBot, вводим ему ссылку - и он обновляет preview на серверах Телеграма. Только что проделал это с указанной ссылкой - и всё заработало.

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

Например, мне известен совсем недавний случай, когда одна крупная международная компания (представленная и в России), производящая продукты питания и использующая некоторый зарегистрированный бренд из двух слов, потеряла домен первое_слово.company из-за того, что оно само по себе было чьим-то товарным знаком. При этом указанная компания могла бы зарегистрировать в _некоторых_ странах этот товарный знак и всё равно потерять домен по причине невладения таким товарным знаком в США.

Аналогично может пострадать и Сбер, если домен с его названием будет зарегистрирован в юрисдикции, где у него нет товарного знака. В каком-нибудь Вьетнаме, например. Кстати, вьетнамские домены sber.vn и sberbank.vn свободны (наверняка в домене vn есть ограничения на регистрацию нерезидентами), а индонезийские sber.id и sberbank.id захвачены известным российским киберсквоттером.

Также можно вспомнить, что в нулевые годы гугл долго не мог заполучить gmail.ru и google.ru, поэтому был вынужден ютиться в домене google.com.ru.

Так что нет универсального ответа на этот вопрос. Если найдётся свободный домен, похожий на чей-то, то иногда может и прокатить. Но если домен будет не просто простаивать, а использоваться по отношению к тому же самому Сберу и хоть сколько-нибудь заметен, то ему это вряд ли понравится, а уж в США у Сбера вполне может найтись давно зарегистрированный товарный знак в качестве инструмента давления.

Смотрим в сторону модуля json

import json

data = json.loads(dirtyJson)
print (data["foo"]["bar"][666])

Можно вот так сделать:

math.floor(balance*100)/100

viber://chat?number=%2B79123456789

К сожалению, у Viber всё плохо с нормальным документально обоснованным форматом ссылок, и раньше уже переставали работать некоторые из них, например, viber://contacts больше не работает.

Есть документация по deep link для ссылок на Public Accounts. Есть также такие официальные:

viber://keypad?number=%2Bxxxxxx - открывает номеронабиратель Viber с этим номером
viber://chat?service=xxxxxx - ссылка на Viber Service
viber://more/qr - открывает QR-сканер

Владелец файла неважен, важно наличие доступа. Если доступа на чтение нет, то это всё, приехали.

Так-то кратчайший вариант тут указали:

echo `<-text.txt-`

Но я думаю пользователя волновал именно минус в имени, а не наличие cat, и вот с этим побороться легко:

cat -- -text.txt-
cat ./-text.txt-

Вопрос в такой форме в принципе не очень корректен. Понятно, что vim может намного больше и намного круче, чем nano, но в конкретной ситуации важно не то, насколько крут используемый инструмент, а твоё личное умение решать задачи.

Кто-то может быть и хорошо шпарит всякие клёвые штуки на vim, но элементарные задачи будет решать бездумными копипастами со Stackoverflow, чреватыми получением какого угодно (вплоть до деструктивного) результата. А в это же самое время опытный админ типа одного моего хорошего знакомого быстро и эффективно решит все проблемы в малоизвестном нынче, но весьма популярном лет 20 назад среди пересевших с DOS на UNIX редакторе joe. Ничего предосудительного в этом нет.

Это точно один и тот же файл? Можно сделать stat на файл в системе и отдельно в контейнере, зайдя в него по docker exec. Если inode у файла разный - это разные файлы. Возможно, с пробросом в докер что-то напутано.

Как называется пользователь зависит от содержимого файла /etc/passwd, который в контейнере и на хосте разные. Пользователь в Linux идентифицируется по uid - это просто числовой идентификатор. Соответственно, uid=0 это root, теоретически его можно переименовать, но так никто не делает.

Всё нормально, на /dev/md# и не должно быть таблицы разделов. Почему возникла мысль, что что-то не так?

Если речь идёт о сервисах, продающих за 200 рублей в месяц и подключающих за один день - это всё имитации WhatsApp Web. Легальный WhatsApp Business API стоит дороже и подключают его порой по 2-3 недели (из-за модерации на стороне Facebook).

Указанные два относятся к категории имитаторов Web и это вовсе не скрывают. Но второй более известный и хотя бы предоставляется в России от имени ИП, первый же имеет явно кликбейтовое название, никаких реквизитов владельцев нет, плюс из контактов на сайте только телеграм-бот, короче, я бы поостерёгся. В любом случае, Важный и Ценный Аккаунт, Который Нельзя Поменять я бы не стал отдавать в подобные сервисы, поскольку в случае бана он будет потерян.

Поставщиков имеет смысл выбирать в первую очередь по признаку наличия интеграции под нужную CRM.

В Windows используется COMPOSE_PATH_SEPARATOR=';', но это можно переопределить через env.

Кроме того, в Windows компоненты пути разделяются обратным слешом, поэтому в данном случае docker-compose решил, что в COMPOSE_FILE одно имя файла, лежащего в текущем каталоге.

Википедия, в отличие от большинства сайтов, не ставит задачу сокрытия данных от использования. Кроме её парсинга полезно рассмотреть альтернативные способы:

1. Парсинг дампов SAX-парсером: https://dumps.wikimedia.org/ruwiki/latest/

Главное в тексте находить нужные категории.

2. Использование SPARQL к Wikidata: https://query.wikidata.org/

Например, я наскоро набросал такой запрос, находящий все элементы субклассов "животное":

select ?animal ?animalLabel where {
# субкласс (wdt:P729) животного (wd:Q729)
  ?animal wdt:P279 ?animalSubClass.
  ?animalSubClass wdt:P279* wd:Q729.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "ru,en". }
}

К сожалению, не всегда данные в Википедии хорошо размечены семантически, поэтому в подобную выборку может попасть не всё. Ну и полно будет извлечено из enwiki.

Можно порыться в исходниках клиентов, например:
https://github.com/telegramdesktop/tdesktop/tree/d...
https://github.com/DrKLO/Telegram/tree/master/TMes...

Нет, SDL - это кроссплатформенная библиотека для работы приложений с мультимедиа (аудио-видео). Никакие "API разных ОС" (что это, системные вызовы что ли?) она не объединяет.

Потому что иметь одну переменную (или один набор) для описания состояния пользователя - это несовместимо с одновременной работой с множеством пользователей. Нужно заводить словарь состояний пользователей, используя их id как ключи.