LINUX.ORG.RU
ФорумAdmin

Atuin - не работает синхронизация истории

 , ,


1

1

Установил на своём сервере Atuin для синхронизации истории fish между тремя своими устройствами (десктоп, личный ноут, и рабочий ноут).

Залогинился на десктопе и личном ноуте. На десктопе импортировал всю историю fish за несколько лет.

Однако, на ноуте история десктопа не ищется, хотя синхронизация прошла успешно, судя по статусу. Аналогично, на десктопе не появляется история ноута. Специально и там, и там добавлял уникальные сочетания в историю, чтобы гарантированно проверить синхронизацию.

Key file на обоих устройствах одинаковый. atuin status выводит, что синхронизация с сервером прошла успешно.

Кроме того, fish начала выдавать предупреждения вида: error: ignoring corrupted history entry around offset 5636186

Кто-нибудь пользовался atuin - оно вообще работает? Или я не понимаю, как оно должно работать, и у каждого устройства будет своя история, т.е. история устройств не объединяется?

Перемещено hobbit из general

Оно отлично работает. Нет, если залогинен под одним аккаунтом, то история будет одна и та же на всех девайсах.

Честно говоря, один раз поставил и оно работает с тех пор. Но я припоминаю, что в первый запуск я тоже немного помучался с тем, что история не прогружалась. Конкретного рецепта не скажу, но, судя по истории команд, я с одного девайса делал atuin sync, логинился с другого и делал atuin store push --force, затем с обоих девайсов по очереди atuin store pull --force, затем с обоих девайсов atuin store rebuild history, и после этого начало работать нормально. Но это неточно :)

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

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

Но не помогло.

Такое ощущение, что у каждого устройства всё равно своя история.

И вообще, есть ощущение, что у них self-hosted история как-то сбоку реализована, ибо в доке информации минимум, что-то пришлось додумывать самому.

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

Или они не тестировали с fish.

Chiffchaff
() автор топика

error: ignoring corrupted history entry around offset 5636186

Поищи в файле NUL-байты. В fish куча багов с историей, которые заботливо портировали из старой кодовой базы. Недавно какой-то герой без плаща привёл это всё в порядок, но оно пока не в релизе.

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

Поищи в файле NUL-байты. В fish куча багов с историей, которые заботливо портировали из старой кодовой базы. Недавно какой-то герой без плаща привёл это всё в порядок, но оно пока не в релизе.

Да, уже нашёл и поправил. Не знаю, связано это с atuin, или нет, пока что произошло лишь однажды.

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

У меня три устройства: десктоп, личный ноут, рабочий ноут. Все команды, связанные с работой, выполняю на всех устройствах.

И довольно часто тестирую какую-то часть кода, используя зубодробительные curl команды с кучей данных, генерирую токены jwt через jwt-cli. Всё это заново вспоминать долго и утомительно, когда из дома на дачу приезжаешь, например. А синхронизировать вручную через копирование истории или части истории - часто забываю.

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

А ну понятно, я это всё на откуп swagger/postman отдаю. В терминале только команды для администрирования локалхостов и там они отличаются.

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

И довольно часто тестирую какую-то часть кода, используя зубодробительные curl команды с кучей данных, генерирую токены jwt через jwt-cli. Всё это заново вспоминать долго и утомительно...

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

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

Ты каждую команду, которую вводишь, сначала сохраняешь в виде скрипта?

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

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

Ты каждую команду, которую вводишь, сначала сохраняешь в виде скрипта?

Нет. Но вот на подобное:

И довольно часто тестирую какую-то часть кода, используя зубодробительные curl команды с кучей данных, генерирую токены jwt через jwt-cli. Всё это заново вспоминать долго и утомительно...

У меня «тренировать память» как-то мозга не хватает, поэтому начинаю агрится на этапе «очень долго кнопочки влево-вправо держать для исправления ошибки/внесения-изменений».

У меня в истории тысячи однострочников из нескольких команд

Т.е. это больше 2к, если не секрет, вы по какому признаку их распознаете?
Это не стеб если чё, мне реально сложно представить, как можно в линейном списке из 2к записей найти именно нужный однострочник. А с учетом того, что к гадалке не ходи, что там будут и варианты с ошибками, то выбрать правильный вариант становится ещё сложнее.

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

Это не стеб если чё, мне реально сложно представить, как можно в линейном списке из 2к записей найти именно нужный однострочник.

  • Fuzzy-поиск
  • Ограничить поиск директорией, в которой была выполнена команда
  • Отсортировать поиск по наиболее частым командам (склеивать лексически похожие команды или нет — вопрос открытый)
  • Возможно, убрать в конец команды, которые завершились неуспешно (должно сократить предложение вариантов с ошибками, но будут ложноположительные срабатывания)

Но тот факт, что автор не использует скрипты, указывает на плохой UI. Файлы — основная абстракция юникса и она должна быть настолько дешёвой в использовании, чтобы разница между скриптом и командой не чувствовалась.

Почему можно чаще увидеть коллекцию в Postman, а не коллекцию скриптов в директории? Казалось бы, ведь это одно и то же. Потому что UI подталкивает на новые способы решения задачи.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 3)
Ответ на: комментарий от kaldeon

Fuzzy-поиск

Это что?

Ограничить поиск директорией, в которой была выполнена команда

Зачем?

Отсортировать поиск по наиболее частым командам (склеивать лексически похожие команды или нет — вопрос открытый)

Зачем?

Возможно, убрать в конец команды, которые завершились неуспешно (должно сократить предложение вариантов с ошибками, но будут ложноположительные срабатывания)

Это ваше «Возможно»?

Но тот факт, что автор не использует скрипты, указывает на плохой UI. Файлы — основная абстракция юникса и она должна быть настолько дешёвой в использовании, чтобы разница между скриптом и командой не чувствовалась.

Ну наконец-то, я уж грешным делом подумал, что вы топите. :( Разумные слова!

Потому что UI подталкивает на новые способы решения задачи изобретение велосипеда с треугольными колесами.

Поправил.

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

Да ну, где еще кроме как истории команд хранить историю команд? У меня тоже история с доисторических времен хранится, бекапится и переносится с машины на машину. И поиск там не линейный, а как написали, контекстный и гибкий

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

Да ну, где еще кроме как истории команд хранить историю команд? У меня тоже история с доисторических времен хранится, бекапится и переносится с машины на машину. И поиск там не линейный, а как написали, контекстный и гибкий

Оказывается это заразно. Ну и вангану, что ваши «доисторические» измеряются пятком, максимум десятком лет.

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

Но тот факт, что автор не использует скрипты, указывает на плохой UI.

Это с чего это я не использую скрипты? Кто это вообще сказал?

Точно не я, потому что я скрипты использую.

Chiffchaff
() автор топика