Buku: менеджер закладок командной строки для Linux
В эту эпоху Интернета управление закладками является одной из задач, которая нам всем нужна. Сегодня мы собираемся представить новую утилиту командной строки для управления закладками — Buku .
Buku — это гибкая утилита управления закладками из командной строки, разработанная Аруном Пракашем Яной. Он тот самый парень, который дал нам Googler: инструмент для использования Google в терминале Linux.
Он разработал его, потому что он не мог найти подходящее решение командной строки для своих нужд управления закладками. И, как оказалось, ему действительно удалось создать хорошего менеджера закладок.
Установка на Ubuntu
Буку нужен Python версии 3.3 или выше для запуска. Команда для проверки версии Python:
Затем мы должны установить пару зависимостей:
Теперь для установки Buku выполните следующие команды:
Особенности и основное использование
Buku поддерживает все основные задачи по закладкам, такие как — добавление, удаление, тегирование, комментарий, поиск, обновление и т. Д., А также добавляет некоторые дополнительные функции. Вы можете проверить страницу руководства Buku для различных примеров:
Вот некоторые из черт Buku:
Выбор заголовка закладки : Buku может автоматически получать заголовок закладки из Интернета. И вы можете обновить все из них с помощью одной команды из терминала:
Шифрование . Одна из интересных особенностей Buku — встроенный механизм шифрования. Вы можете зашифровать свою базу данных закладок с помощью этой команды:
Введите пароль для шифрования базы данных, и она будет зашифрована с использованием алгоритма 256-битного шифрования AES. Если вы не хотите, чтобы кто-нибудь еще просматривал ваши закладки, Buku окажет вам большую помощь. А для расшифровки базы данных просто запустите:
Импорт / экспорт : Buku может импортировать закладки из экспортированного HTML-файла Firefox / Chrome / IE, а также экспортировать закладки в том же формате.
База данных с возможностью слияния : базы данных Buku полностью пригодны для использования и переносимы. Итак, если у вас есть несколько устройств и вы используете Buku на них для управления закладками, вы можете получить файл базы данных с одного устройства, объединить его с базой данных на другом устройстве и передавать его туда и обратно!
Мысли о буку?
Большинство из нас просто используют встроенный менеджер закладок в наших веб-браузерах. Но могут быть некоторые сценарии, когда вместо этого предпочтительнее использовать Buku:
- Если вы заядлый любитель терминалов и хотите делать что-то с терминала как можно больше.
- Если вы серьезно относитесь к безопасности закладок. И хочу управлять ими самостоятельно.
- Если вы используете браузер без возможности синхронизации закладок (например, Vivaldi), но также не хотите использовать сторонние расширения браузера. Комбо Buku-Dropbox будет отлично работать.
Тем не менее, он предлагает нам альтернативу, и мы это ценим. Что вы думаете о Буку? Хотите увидеть какие-либо новые функции, добавленные в Buku?
Источник
Менеджер ссылок (букмарков/закладок) в файловой системе?
Я до сих пор считаю древнее решение IExplorer с хранением закладок в дереве ФС очень удачным. И сильно не хватает подобного для ручной работы со ссылками в других браузерах. Понятно, что не сложно сделать свой аналог, но, прежде чем велосипедить — может, где-то уже есть подобное готовое решение?
Я за велосипединг. Когда пилят софт, чтобы упростить себе жизнь — велики шансы на выходе получить годноту, которая будет полезна не только автору.
Велосипедь.
О результатах велосипединга доложишь к исходу (вписать дату).
Проще запилить самому. Можно на модном Электроне.
//я бы подобное заюзал; сам планирую писать
Да нет, мне по факту только бэкенд нужен. Хранилище для синхронизации 🙂 Морду, возможно, сделаю, но только под Web.
Тогда нужно формат хранения придумать. По факту выбирать нужно будет между *.url в дереве каталогов и *.md 🙂 Вариант от MS интересен тем, что какой-никакой, а стандарт, если какие-то инструменты для работы с таким форматом есть, они и у меня работать будут, вариант с Markdown гибче в плане оформления, разметки и human readable.
А чем звездочка в браузере не устраивает? В firefox например ты можешь всегда экспортировать закладки в html или json.
А если бравзер начнет на заводиться на ровном месте?
А чем звездочка в браузере не устраивает?
Потому что мне нужен стандартный бэкенд 🙂 Мне нужен не конкретный браузер, а абстрактное хранилище. Ну и инструменты для синка букмарков разных браузеров.
Однофайловый вариант а ля Firefox не годится из-за проблем конфликтов при встречных модификациях во время синхронизации.
Вон, чисто для иллюстрации, у scrapbook’а у меня scrapbook.rdf уже в количестве 8 конфликтных копий, которые разрешить у меня руки с 2014 года не доходят 🙂
Для этого же как раз какой-то 3-rd party сервис закладок у Firefox приделывали, чтобы разные устройства, браузеры. Но вообще если под веб не разрабатывать, то разные браузеры не нужны, причем если даже есть разные браузеры, наверняка они используются для разных задач, и не нужно чтобы закладки между ними пересекались.
А если бравзер начнет на заводиться на ровном месте?
Почему? Потом он сам делает бэкапы закладок в json, периодично.
Почему хранить закладки в файловой системе в виде отдельных файлов плохо надеюсь объяснять не надо? Если будешь что-то свое делать, возьми sqlite хотя-бы. Но наверняка какой-нибудь менеджер коллекций, тогда подойдет.
О, тоже хочу такое.
Если будешь что-то свое делать, возьми sqlite хотя-бы
Это тоже сразу смерть синхронизации 🙂
Почему хранить закладки в файловой системе в виде отдельных файлов плохо надеюсь объяснять не надо?
Надо. Больше места на диске — это в 21-м веке несерьёзно.
ЛММ упаси, предпочитаю совместимость с rsync и git.
Вот бы можно было что из e-mail клиента, что из мессенджера, что из фаерфокса или хрома иметь доступ к своим закладкам. И даже удалённо. Ждём.
Тогда нормальную популярную реляционную базу данных и настроить репликацию.
— Это прибивание гвоздями к конкретной платформе
— Это требует доверия между узлами
— Это требует непрерывной синхронизации
— .
Почему хранить закладки в файловой системе в виде отдельных файлов плохо надеюсь объяснять не надо?
И чем же это плохо?
Правда синхронизирует не все букмарки, а только 1 папку.
Если файлов будет очень много, то будет все тормозить, вплоть до вывода ls. и могут закончиться иноды. Нормальный поиск, ты к этому ты же врядли прикрутишь.
Я, конечно, предполагал, что доводы будут сказочными, но не думал, что настолько.
А если тебя подорвут фанатики свободы?
Это только означает, что ты просто не понимаешь в вопросе и никогда с этим не сталкивался.
С такими клоунами я действительно никогда не сталкивался. Давайте, расскажите мне про миллионы закладок в браузере. И про отсутствие поиска по содержимому.
Печаль начнется уже еще на сотнях тысяч файлов, со стороны системы синхронизации, с CPU load. Если только синхронизировать раз в 30 минут и реже, но лесенка в мониторинге все равно, скорей всего появится. Все в зависимости, от твоего калькулятора конечно.
Сотни тысяч закладок? Ну да, типичная картина жи.
Какая система синхронизации в файловой системе?
Как ты будешь синхронизировать файлы с другими машинами? 
KRoN73 Тут если только, если так нужен этот вариант с файлами, то хранить в файлах, разложенных по разным каталогам с категориями, например. Потом сканировать директории локально и делать БД (что-то вроде как было давно в amarok, не знаю как сейчас), а потом уже эту БД экспортировать в один файл сжатый файл например. Это если так сильно не нужна репликация.
Печаль начнется уже еще на сотнях тысяч файлов
Самый мой жирный сервер в плане синхронизации:
— Локальное состояние (всего): 540592 [файлов]
— . 29266 [каталогов]
—
Печали, вроде, не наблюдается 🙂
Это не говоря уже о том, что сотни тысяч закладок — это очень не типичный случай 😀
а потом уже эту БД экспортировать
Если с этими закладками потом потребуется работать высоко нагруженному серверу — то да, так 🙂
В остальных случаях достаточно (и нужно) экспортировать только в формат закладок конкретного браузера.
Как ты будешь синхронизировать файлы с другими машинами?
Я вообще не понимаю, зачем нужен экспорт в браузеры. Открываешь каталог с файлами-закладками, кликаешь по нужной, xdg-open открывает дефолтный браузер.
А через что ты синхронизуешь и как часто?
В остальных случаях достаточно (и нужно) экспортировать только в формат закладок конкретного браузера.
Вот это правильно, особенно если учесть что популярных браузеров всего по сути два.
Я вообще не понимаю, зачем нужен экспорт в браузеры
1. Потому что в браузере часто удобнее работать из его механизма закладок не переключаясь в консоль и обратно.
2. Для синхронизации при работе с закладками из нескольких мест одновременно.
Как будто ты что-то понимаешь, ахинею написал и думает за умного сойдёт.
Ты так и не ответил, зачем на разных браузерах одинаковые закладки? Ты же не вебмакакий вроде.
Сотни тысяч закладок? Ну да, типичная картина жи.
Даже если набрать столько, разложенные по каталогам не будут тормозить.
Ты так и не ответил, зачем на разных браузерах одинаковые закладки?
Например, для работы из дому с десктопа, с ноута, с работы. 🙂
Потому что в браузере часто удобнее работать из его механизма закладок
Сомнительно. Самый удобный механизм работы с закладками — в Опере, и он, между прочим, полностью имитирует файловый менеджер.
не переключаясь в консоль и обратно
Какая консоль, о чём вы?
Для синхронизации при работе с закладками из нескольких мест одновременно
Не понял этот момент. У вас есть каталог с закладками, синхронизируйте его через облако, всё. Какие тут проблемы?
И что, на каждом из них у тебя разный браузер?
Так у меня и нет задачи _чем_ синхронизировать 🙂 Задача стоит _что_ синхронизировать.
И что, на каждом из них у тебя разный браузер?
Не поверишь, но у меня даже на одной машине, бывает, 2-3 браузера активно используются. Времена такие снова настали 😀
— Opera для обычной работы
— Chrome для гуглоприложений
— Firefox для Scrapbook
— .
Так у меня и нет задачи _чем_ синхронизировать
Тогда зачем вы заморачиваетесь средствами синхронизации? Облако это просто пример. Можно хоть простым ручным копированием переносить закладки.
Тогда зачем вы заморачиваетесь средствами синхронизации?
Я и не заморачиваюсь. В топикстарте нет ни слова про синхронизацию 🙂
Тогда нужно формат хранения придумать.
Может быть .desktop?
Тогда тем более не о чем разговаривать, обычные файлы в каталогах.
Был удивлен тем, что с ходу не обнаружилось решение открытия урлов из файлов для лисы и хромиума.
Если детально, то нужно писать дополнение, которое делало бы следующее:
выведение диалога с предложением ввести название закладки, по умолчанию там уже строка с тайтлом страницы
всё это упаковывается в desktop-файл, туда же — description страницы
В результате получаем совершенно прозрачную закладку с превьюхой и возможностью поиска по содержимому.
подписался, тоже хочу. даже, возможно, готов вписаться в разработку
Дык, тогда проблема совсем надумана. Что Chromе, что Firefox умеют импортировать/экспортировать закладки в/c HTML.
Я просто понял, что ты хотел синхронизировать закладки в разных браузерах в разных ОС, на разных устройствах, при это зачем-то хранить каждую в виде отдельного текстового файла.
Тогда, если ты хочешь делать это вручную тебе просто нужна программа, которая сравнит несколько HTML файлов с закладками, выберет уникальное, и на выходе создаст один общий файл.
Потому что мне нужен стандартный бэкенд 🙂 Мне нужен не конкретный браузер, а абстрактное хранилище. Ну и инструменты для синка букмарков разных браузеров.
подписался, тоже хочу. даже, возможно, готов вписаться в разработку
Ну, в виду того, что какого-то универсального бэкенда никто не назвал, я, пожалуй, сделаю хранение в Markdown в формате, принятом под контентные данные в Infonesy. Т.е. дерево/ссылка.md, а внутри:
Что-то в таком духе 🙂 Ну и импорт/экспорт тоже в рамках Infonesy. Т.е. каждый браузер в синке — просто нода сети. Добавил букмарк, обновление летит в сеть, принимается и импортируется другими нодами-браузерами. Одно только, надо проверить, как браузеры с монолитным файлом букмарков (т.к. почти все :D) реагируют на изменение этого файла, когда браузер запущен.
Прямой работы не много, так что займусь этим как потребность возникнет.
Источник
