GNU Stow

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

Лучше придумать что-нибудь более простое и прозрачное.

Например?

например $HOME как git директория

Зависит от задачи, которую ТС хочет решить с помощью симлинков. Если это организация дотфайлов, то можно .git положить куда-нибудь, а при работе с гитом прокинуть переменные окружения (чтобы при обычной работе этот репо случайно не был обнаружен командой git). В общем, решить проблему на имеющимся слое абстракции.

Но если симлинки неизбежны, то они неизбежны и в юниксах нет более адекватных абстракций на замену а-ля Plan 9.

Симлинки — костыль сам по себе

Главное не грабли

Задача - чтобы всякая нужная мне хрень, раскиданная по /usr/local/bin, ~/.config/foo и другим подобным папкам была в одном месте.

Сейчас у меня это сделано через редактируемый вручную HTML-файлик. В нем изображено дерево интересующих меня каталогов и файлов и на каждый каталог и файл вставлена гиперссылка.

HTML-файл, если обслуживание не вызывает неудобств - норм вариант. Современно. Я делаю нечто похожее, позволяя открыть в текстовом редакторе любой путь, указывающий на существующий файл. Это проще обслуживать: не нужен специальный формат, можно положить в любой файл, можно автоматизировать (нажать на результат команды find . |grep ...).

Если нужно обязательно хранить файлы в одной директории, то можно попробовать решить задачу с помощью Makefile, в котором прописывать cp для каждого файла, если их не много и они не часто меняются. Если много, то можно локально повторить иерархию и пройтись циклом.

Я бы отдал предпочтение инструментам общего назначения (Makefile) до момента обнаружения их ограничений в рамках решаемой задачи. Keep it simple.

Было бы ещё неплохо, если владение GNU Stow пригодилось в будущем. Но людям, кажется, скорее неинтересен этот инструмент. Быть крутым ради решения одной проблемы - такое себе достижение.

Если бы пришлось использовать GNU Stow, я бы попробовал копировать файлы, а не симлинкать.

до упоминания 9p, plan9, inferno осталось 6 сообщений

на замену а-ля Plan 9.

а нет, рекорд побит, plan9 был упомянут в четвертом сообщении

GNU Stow (комментарий)

вместе с /etc

Если бы пришлось использовать GNU Stow, я бы попробовал копировать файлы, а не симлинкать.

за годы практик я пришел к такому:

$ mkdir ~/spaces/<context_name>
$ cd ~/spaces/<context_name>
$ ln ~/git/github.com/repo1 ~/git/github.com/repo2 .
$ tmux new -As $(basename $(pwd))
$ nvim repl.sh

выглядит конечный результат примерно так https://asciinema.org/a/706763

HTML-файл, если обслуживание не вызывает неудобств - норм вариант. Современно. Я делаю нечто похожее, позволяя открыть в текстовом редакторе любой путь, указывающий на существующий файл.

Вы кстати ОЧЕНЬ не далеки от правды, HTML задумывался как язык гиперсылок между семантическими понятиями, гуглить symantic web.

https://www.w3.org/2000/Talks/0906-xmlweb-tbl/text.htm

не могу нагуглить, был пример 3D проводника «проводника»

Stow is implemented as a combination of a Perl script providing a CLI interface, and a backend Perl module which does most of the work.

против перла я ничего не имею, но не понимаю зачем его тащить в систему ради GNU Stow

repl.sh - хорошая тема, тоже юзаю, но на свой манер. Чаще всего это git status-add-commit-push, открытие таски в трекере задач, МРа в гитлабе, запуск make sth, SQL-запросы и всякие ad-hoc команды.

gRPC/HTTP проще обслуживать, если кладу в отдельный скрипт: на входе запрос, на выходе ответ. Просто они тогда визуально не занимают пространство. Выглядит это так:

|./ListContracts
(	filter: {
		client_id_in: ['ffff...']
		page: 1
		per_page: 10
	}
)

(скобочки чтобы быстро выделить)

Файл, как правило, один на проект, поэтому команды накапливаются и встаёт вопрос о навигации. Это удобно делать так: команда для перехода к нужному месту должна быть легкодоступна и коротка. Например, :/^review/ в начале файла. Сама секция выглядит примерно так:

review (release/JIRA-123) !69

	<git diff master...HEAD
	<git log --oneline master..HEAD

Отступы помогают визуально воспринимать секцию (а-ля функции в стиле C) и делают навигацию через :/^review/ возможной. Самый полезный текст должен быть самым легкодоступным, а легкодоступно то, что повыше. release/JIRA-123 позволяет одновременно открыть таску и выделить название ветки для передачи в gitcheckout/gitmerge/etc. !69 открывает МР. Можно было и с помощью шелла сделать, но это уже три строки.

чем плохи hardlinks?

Стоит оно того, или одни проблемы решает, а другие создает?

Если у тебя куча кастомных конфигов, ты в них постоянно делаешь изменения и ты на автомате всё отправляешь в гит, то в Stow может быть смысл. Например, ты используешь hyprland, по файлам прыгаешь в lf, у тебя куча плагинов в vim, почту смотришь в neomutt и т.п. Т.е. используешь вещи, которые тяжело в случае чего привести в нужное тебе состояние за пару минут.

Если просто хочешь забэкапить на всякий случай пару файлов, то это пустая трата времени.

Я пользуюсь, когда не лень задавать --prefix у конфига (а как это сделать в новомодных сборочных тулзах, разбираться тем более лень), а checkinstall по какой-то причине косячит. Уж всяко проще, чем городить какие-то HTML, как тут несут.

В вашем случае может ещё mount --bind пригодиться.

➜  a mkdir view                                                                                                                                                             
➜  a mkdir -p a/b/c{1,2,3,4}                                                                                                                                                             
➜  a touch a/b/c3/file                                                                                                                                                               
➜  a tree                                                                                                                                                                            
.
├── a
│   └── b
│       ├── c1
│       ├── c2
│       ├── c3
│       │   └── file
│       └── c4
└── view

7 directories, 1 file
➜  a mkdir d                                                                                                                                                                         
➜  a touch d/another-file                                                                                                                                                            
➜  a sudo mount --bind a/b view                                                                                                                                                      
➜  a sudo mount --bind d view/c4                                                                                                                                                     
➜  a tree view                                                                                                                                                                       
view
├── c1
├── c2
├── c3
│   └── file
└── c4
    └── another-file

4 directories, 2 files

Позволяя открыть в текстовом редакторе любой путь, указывающий на существующий файл.

У меня это тоже настроено.

Я делаю нечто похожее

Просто набор путей, разбитый на группы?

/foo/bar/.xyzrc
/foo/bar/baz/util.sh
/abc/xyz/conf.toml

Да. Можно в одну строку. /foo/bar/.rc, /qux/.rc - будет работать. И относительные пути тоже. Если я смотрю файл /Users/azat/guide и в нём есть строка github.com/9fans/go/guide, которая указывает на реальный файл, то её тоже можно открыть.

https://9fans.topicbox.com/groups/9fans/T14d091abb3883d10-Md306e949b555cb1f3e2d8aaa/9fans-q-moving-directories-hard-links

спс за инфу о недостатках хардлинкс

есть ли «оттуда же» сравнение с симлинками?

зы. ща раскуриваюсь вторым изданием Дейты(1980 на ру)[ ещё более яснее от чего в Лонгхорне(имя выни 2007) хотели «иновационую реляционую файловую систему»] - так вот хардлинки и симлинки это как нормальная форма в реляционке и кто контролирует целостность система или пользователь :) - как и Xanady vs www - у предыдущей рёбра ненаправлены и следовательно граф жёще у БёрнсаЛи указующий не отвечает за существание указываемого

https://9fans.topicbox.com/groups/9fans/Tf3b0de27c45e263a-M1ccfbca5cc3128541562a06c/9fans-mv-vs-cp

у меня в итоге примерно такие конструкции получаются

(это yaml сценария для tmuxinator)

name: host-broker
root: ./

pre_window: |
  export PAGER=cat
  ns=user-bob
  vm_name=ubuntu-dev
  mindwm_host=ubuntu-dev
  nats_port=4222
  nats_url=nats://root:r00tpass@${vm_name}:${nats_port}

  nats_channel() {
      [ ${action} == "delete" ] && {
          kubectl -n ${ns} delete NatsJetStreamChannel ${name} || :
      } ||
      cat<<EOF | tee | kubectl apply -f -
  apiVersion: messaging.knative.dev/v1alpha1
  kind: NatsJetStreamChannel
  metadata:
    name: ${name}
    namespace: ${ns}
  spec:
    stream:
      config:
        retention: Limits
        maxBytes: 1000000000
        replicas: 1
    consumerConfigTemplate:
      deliverPolicy: New
      maxDeliver: 1
  EOF
  } 
  
windows:
  - editor:
      layout: main-vertical
      panes:
        - 
          - export EDITOR=nvim
          - tmuxinator edit $(basename $(pwd))
          - ":REPLStart bash"

  - dashboard:
      layout: main-vertical
      panes:
        -
          - kubectl -n ${ns} get NatsJetStreamChannel
          - kubectl -n ${ns} get subscriptions

  - nats:
      layout: main-horizontal
      panes:
        # from host
        -
          - topic_name=host-${mindwm_host}-from
          - &nats_topic_show |
            while :; do
              nats -s ${nats_url} sub host-${mindwm_host}-from
              sleep 5
            done
        # to host
        -
          - topic_name=host-${mindwm_host}-to
          - *nats_topic_show
  - test:
      layout: main-vertical
      panes:
        -
          - action=create name=test namespace=default nats_channel
 

Сначала хотел спросить почему knative, а не lambda, потом увидел кубер и вопрос отпал.

а не lambda

про какую именно идет речь?

про какую именно идет речь?

Про AWS-ную версию с их serverless фреймворком.

их serverless фреймворком.

я использовал их, но это вендор лок, а cloud-agnostic serverless фреймворка еще тогда не было.

AWS-ную версию

не совсем корректное сравнение, с knative это eventing (роутинг) и serving (lambda функции), где EDA работает на событиях в cloudevent формате.

понял, спасибо за ответ.