Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Пока что полет нормальный но что-то niggles at the back of my mind — где-то получу проблемы. Вопрос где и какие?

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

От проясняния этих вопросов зависит дальнейший ход рассуждений.

Здравствуйте, Pzz, Вы писали:

Pzz>Ты написал программу для личного использования и разложил её таким необычным образом?

Разрабатываю я и сейчас подключается один мой друг. Возможно подключится еще один.

Pzz>Ты собираешься распространять эту программу?

Никто распространять не собирается.

Расклад как в Windows позволяет на одном компьютере держать три версии, одну stable — /usr/local/myprog/ для проходимцев из Internet, и две в разработке /home/user1/myprog/ и /home/user2/myprog/. Каждая слушает на своем порту номер которого берется из ./myprog.conf.

-

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Расклад как в Windows позволяет на одном компьютере держать три версии, одну stable — /usr/local/myprog/ для проходимцев из Internet, и две в разработке /home/user1/myprog/ и /home/user2/myprog/. Каждая слушает на своем порту номер которого берется из ./myprog.conf.

Если программой собирается пользоваться ты и твой друг, я вообще не вижу проблем. Делайте, как вам удобно.

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

Проблемы версионирования могут разрешаться, например, так: /usr/local/myprog/1.0, /usr/local/myprog/1.1, /usr/local/myprog/1.0, /usr/local/myprog/1.1 и т.п.

Я обычно ищу конфигурационный файл где-то по-соседству с исполняемым (с его фактическим расположением). Это позволяет запускать программу прямо из сборочной директории, что удобно и полезно в процессе разработки. Но в поинсталлированной версии конфига не будет рядом с исполняемым файлом, поэтому при штатном использовании это никак не помешает.

Здравствуйте, Pzz, Вы писали:

Pzz>Если ты собираешься её распространять,

Это не для распространения.

-

Здравствуйте, Лазар Бешкенадзе, Вы писали:

Pzz>>Если ты собираешься её распространять,

ЛБ>Это не для распространения.

А почему, кстати, ты ссылаешься на мануал FreeBSD? Всё же, FreeBSD — это сейчас для утончённых ценителей, не массовый рынок.

Здравствуйте, Pzz, Вы писали:

Pzz>А почему, кстати, ты ссылаешься на мануал FreeBSD? Всё же, FreeBSD — это сейчас для утончённых ценителей, не массовый рынок.

Это разработка под FreeBSD. Мне помнится в разговоре с тобой я объяснял свой выбор:

https://rsdn.org/forum/life/9020951.1

Я не люблю пингвинов. Да, FreeBSD оказалась с проблемами, но пока все удалось обойти.

-

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Это разработка под FreeBSD. Мне помнится в разговоре с тобой я объяснял свой выбор:

ЛБ>https://rsdn.org/forum/life/9020951.1

Да, объяснял. Тот разговор не продолжился, а потому и не запомнился.

А не продолжился потому, что мне не хочется устраивать холивар на тему Linux vs FreeBSD. Пустое это занятие.

Но в целом, твоё объяснение выгядит так: линух не люблю, почему не скажу. Из оставшегося выбираю FreeBSD, хоть он и с проблемами.

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Пока что полет нормальный но что-то niggles at the back of my mind — где-то получу проблемы. Вопрос где и какие?

на линуксе это мог бы быть источник проблем для selinux, ну или что там во freebsd на этот счёт есть. а так пофиг.

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Мне тут предложили файл конфигурации хранить в /usr/local/etc/, временные файлы в /tmp/myapp/ или /var/tmp/myapp/. Как я понимаю в этом раскладе исполняемый файл должен идти в /usr/local/bin/.
ЛБ>Мне это все очень не нравится и я решил все свои файлы держать, как принято в Windows, в одной директории. Пусть это будет /usr/local/myprog/. Более того, исполняемый файл я назвал myprog.exe.

Если хочешь сделать как в Windows, тогда используй папку /opt. Если кратко, то /usr/local это тот же /usr, только для себя. А вот сторонние инсталляторы не из репозиториев и портативные версии копируют в /opt. В /usr будут устанавливаться версии программ, которые пришли из репозиториев в виде пакетов таких как *.deb, *.rpm или других, в зависимости от операционки.

А вот в /usr/local скачивают исходники программы и там их сами компилируют. Это папка не для разработки в ней, а для скачивания исходников и компиляции в ней. Потому /usr/local повторяет структуру папок /usr. Но если делаешь инсталлятор или портативку как в Windows, когда программа должна оказаться как в папке Program Files, то тогда выбирай /opt.

Ну и бла бла бла. Вот тебе выжимка из гугловского ии.
https://www.google.com/ai

Хотя перед этим ещё напишу как я вижу путь к экспертности.
1. Читай книги (например, Таненбаума).
2. Пользуйся выжимками.
Или и то и другое.

Быстрые советы людей сейчас превратились вот в такой вот поиск, вместо тех же форумов с ответами, откуда ии тоже дерёт данные. А для глубокой экспертности нужно читать книги и думать в процессе.

Я к тому, что спрашивать на форуме это уже практически ушло в прошлое. Это долго и неэффективно. Не зря форумы программистов превратились в балабольство ни о чём. Потому что действительно не нужно и джуны тоже понятно почему резко стали не нужны.

Смысл давать мидлам и синьорам задание джунам, когда джуны тупо набъют его в поиске, когда мидлы и синьоры могут сами набить его в поиске. Что типа, джуны нынче такие продвинутые, а мидлы и синьоры идиоты. Вот туда и движется айтишка, не в ..пу как некоторые думают, а в высокую степень экспертности.

для чего нужна папка /opt в unix

Папка /opt в Unix-подобных операционных системах (включая Linux) предназначена для установки дополнительных (optional) пакетов прикладного программного обеспечения, которые не являются частью базовой операционной системы.

Основные характеристики и назначение /opt:

• "Optional" (дополнительное): Само название папки указывает на ее предназначение для размещения программ, не входящих в стандартную дистрибутивную сборку.
  
• Стороннее ПО: Она используется для установки проприетарного или стороннего программного обеспечения, которое распространяется вне стандартных систем управления пакетами (например, .deb или .rpm), или же приложений, которые разработчики хотят держать отдельно от основных системных файлов.
  
• Самодостаточные пакеты: Приложения, установленные в /opt, как правило, являются самодостаточными и содержат все необходимые статические файлы (бинарные файлы, библиотеки, документацию) в своем собственном подкаталоге (например, /opt/имя_пакета/), что упрощает их управление и удаление.
  
• Отделение от системных файлов: Такое расположение помогает отделить стороннее ПО от основных системных компонентов, находящихся в каталогах /bin, /usr/bin, /lib и т.д. Это повышает целостность и безопасность базовой системы.
  
• Удобство развертывания: Установка в /opt часто сводится к простому копированию или распаковке архива, что удобно для системных администраторов при развертывании приложений, специфичных для конкретной компании или проекта.

Примерами программ, которые могут устанавливаться в /opt, являются Google Chrome, Spotify, или другие крупные проприетарные приложения.

для чего нужна папка /usr/local в unix

Папка /usr/local в Unix-подобных системах имеет схожее назначение с /opt, но служит немного иной цели в рамках иерархии файловой системы (FHS). Она предназначена для размещения локально установленного программного обеспечения, которое собирается и компилируется вручную системным администратором или пользователем.

Основные функции и отличия /usr/local:

Основное назначение

Это место для программ, которые вы устанавливаете "вручную" из исходных кодов (например, с помощью команд ./configure, make, make install), а не через системный менеджер пакетов (вроде apt, yum или dnf).

Ключевые отличия от /opt и других папок

• Локальная компиляция: В отличие от /opt (куда чаще просто копируют готовые, скомпилированные бинарники сторонних вендоров), /usr/local исторически используется как стандартное место установки ПО, собранного локально из исходников.
  
• Резервное копирование: Иерархия FHS (Filesystem Hierarchy Standard) предписывает, что содержимое /usr/local должно быть безопасно для резервного копирования и не должно конфликтовать с файлами, управляемыми дистрибутивом.
  
• Иерархия внутри: Внутри /usr/local поддерживается та же структура, что и в /usr:
  

  /usr/local/bin: исполняемые файлы (бинарники);
  /usr/local/lib: библиотеки;
  /usr/local/share: общие данные, документация;
  /usr/local/etc: файлы конфигурации.

Сравнение с /opt

Характеристика	/usr/local	/opt
Метод установки	Чаще всего ручная компиляция из исходников (make install).	Чаще всего копирование готового пакета от стороннего вендора.
Структура	Соблюдает внутреннюю иерархию (bin, lib, share).	Каждое приложение имеет свой собственный изолированный подкаталог (/opt/appname/).
Назначение	Расширение системных утилит, установленных пользователем.	Установка полностью независимых, сторонних приложений.

Таким образом, /usr/local — это "песочница" для ваших собственных скомпилированных программ, которая позволяет держать их отдельно от основных системных файлов, поддерживаемых операционной системой.

Но это я как бы давно знаю как пользователь. Но предположим я бы не знал, тогда напрашивается запрос.

в какую папку устанавливать программы в unix

Выбор папки для установки программ в Unix или Linux зависит от нескольких факторов:

• Тип программы (системная утилита, стороннее приложение, скомпилированная вручную программа).
  
• Способ установки (через менеджер пакетов дистрибутива или вручную).
  
• Стандарты дистрибутива (FHS — Filesystem Hierarchy Standard).

Вот краткое руководство по основным папкам:

Папка	Назначение	Пример использования
/usr/bin	Системные исполняемые файлы. Сюда устанавливаются программы, которые поставляются с вашей операционной системой (например, ls, grep, python). Вы не должны устанавливать сюда программы вручную.
/usr/local	Локально скомпилированные программы. Используется для программ, которые вы скачали в виде исходного кода и скомпилировали вручную (используя make install). Это стандартное место для локальных расширений системы.	Установка последней версии NodeJS из исходников.
/opt	Сторонние (опциональные) приложения. Используется для полностью самостоятельных программ, которые распространяются сторонними поставщиками в готовом виде (например, Google Chrome, Spotify, Oracle Database).	Установка проприетарного ПО.
~/.local/bin	Программы только для вашего пользователя. Если у вас нет прав администратора (root) или вы хотите установить программу, доступную только вам. (Символ ~ обозначает ваш домашний каталог, например, /home/user/).	Установка персональных скриптов или утилит.

Рекомендации:

• Для большинства пользователей: Используйте стандартный менеджер пакетов вашего дистрибутива (apt в Debian/Ubuntu, yum/dnf в Fedora/CentOS, pacman в Arch). Он автоматически разместит файлы в нужных системных папках (/usr/bin, /etc, /var).
  
• Если вы компилируете программу сами: Используйте /usr/local (убедитесь, что ваш make install по умолчанию устанавливает туда).
  
• Если вы устанавливаете крупное стороннее приложение: Используйте /opt.

Теперь что касается практики. Тот же Qt как раз установит себя в /opt, как и много других программ. Но файлы конфигурации своей программы на Qt не обязательно должны лежать в папке с программой. Я создавал файлы *.ini из своей программы, и выяснил, что их ещё потом надо удалять при деинсталляции.

А между тем QSettings предлагает хранить настройки в Windows, GNU/Linux, MacOS и Android в разных местах. Для Windows это реестр 32 и 64 битной ветки, а для того же GNU/Linux тоже есть папка у пользователя, ну и так далее.

В общем я веду к тому, что саму программу с библиотеками и ресурсами можно запихнуть в /opt, а настройки можно хранить где-то по умолчанию в другом месте, в котором по крайне мере будет разрешение на запись и что не придётся потом чистить деинсталлятором.

Я сейчас не буду смотреть куда та же QSettings дела у меня файлы настройки, когда не записываешь их принудительно в *.ini в папку с программой, но предположим такой запрос.

в какой папке qsetting хранит настройки в linux

В Linux QSettings по умолчанию хранит настройки в файлах формата INI в следующих местах:

• Для пользовательских настроек (локальная область QSettings::LocalScope):
  * $HOME/.config/Название_организации/Название_приложения.conf
  * Также может использоваться $HOME/.config/Название_организации.conf или $HOME/.qt/Название_приложенияrc в старых версиях.
  
• Для системных настроек (глобальная область QSettings::SystemScope):
  * /etc/xdg/Название_организации/Название_приложения.conf
  * Также может использоваться /etc/xdg/Название_организации.conf.

Обратите внимание:

• $HOME — это домашний каталог текущего пользователя (например, /home/user/).
  
• Папка .config является скрытой (начинается с точки), поэтому для ее просмотра в файловом менеджере может потребоваться включить отображение скрытых файлов или использовать команду ls -a в терминале.
  
• Точное имя файла и организации/приложения зависит от того, как они были заданы в коде приложения с помощью QCoreApplication::setOrganizationName() и QCoreApplication::setApplicationName().
  
• Если разработчик явно указал другой формат (например, QSettings::IniFormat с определенным путем к файлу), настройки будут храниться там, где указано в коде, а не в стандартных расположениях. Вы можете использовать функцию QSettings::fileName() в своем приложении, чтобы получить точный путь к используемому файлу настроек.

Скорее всего это был $HOME/.config, проверять не буду. Но вряд ли /etc, хотя можно было бы их записывать куда угодно.

Причём заметь, всё это относилось к развёртыванию программ на компьютерах пользователей. А разрабатывать программу можно где-нибудь в $HOME/work (/home/user/work), или примонтированный диск /mnt/data00 можно виндовый, или ещё где.

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

Здравствуйте, velkin, Вы писали:

V>Если хочешь сделать как в Windows, тогда используй папку /opt.

В своем сообщении я дал ссылку на описание стандартной иерархии в документации — у меня такая. Директории /opt нет и в корне создавать я сам ничего не буду.

-

Здравствуйте, Лазар Бешкенадзе, Вы писали:

V>>Если хочешь сделать как в Windows, тогда используй папку /opt.
ЛБ>В своем сообщении я дал ссылку на описание стандартной иерархии в документации — у меня такая. Директории /opt нет и в корне создавать я сам ничего не буду.

/opt это стандарт для распространения из нестандартных пакетов для операционки.

https://ru.wikipedia.org/wiki/FHS
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

У тебя скорее всего основная операционка для десктопа винда, а юниксы только по работе. Я когда-то годами использовал только основной репозиторий и директория /opt мне была не нужна. Только когда мне стала нужна последняя откомпилированная версия софта, причём с сайта разработчика, а не из репозиториев я и открыл для себя папку /opt, потому что софт ставился туда.

Мораль здесь в том, что /usr/local тоже имеет стандартное предназначение, и /etc тоже имеет стандартное предназначение. Если в /usr/local был make install, то должен быть и make uninstall. Ну и всё в таком роде. Но в целом из исходников установка получается грязной и люди даже в /usr/local рекомендуют сразу компилировать установочные пакеты, которые использует текущая операционка.

В принципе Pzz тебе уже дал ответ делать как удобно, потому что распространять ты не собираешься. Это значит тебе не нужен ни /opt, ни /usr/local. И то что ты намусорил сразу в папке пользователя, а не создал в ней папку /work, /projects или что-то от себя то это тоже твоё дело.

Просто вот такое
ЛБ>Расклад как в Windows позволяет на одном компьютере держать три версии, одну stable — /usr/local/myprog/ для проходимцев из Internet, и две в разработке /home/user1/myprog/ и /home/user2/myprog/. Каждая слушает на своем порту номер которого берется из ./myprog.conf.
не имеет смысла.

Всё это нужно держать в папке с git, или отдельную для проекта, или как у меня общий монорепозиторий для всего. Внутри stable это или тег git, или просто копипаста в какую-нибудь папку версии, или сразу оба. Пример тегов или папок, 0.1, 0.2, 0.3-beta1.

Если другим людям нравится /usr/local, вот пусть и качают твой репозиторий git с твоей программой туда, это их дело. А для тебя важнее должны быть резервные копии в git твоей программы, нежели кто куда это бросает, раз ты всё равно не делаешь пакеты для распространения ни для FreeBSD, ни сторонние.

Но особо не важно, сам потом поймёшь. Я в принципе тоже много лет занимался подобной ерундой, пока не стал более продвинутым пользователем. Прямо как твои советчики, типа давайте кинем исходник в /usr/local. Ого, так ведь в инструкции написано для чего-то там не знаю для чего, но надо.

А сейчас у меня папки больше напоминают то, что видно в проектах на том же sourceforge. Первичен репозиторий git причём где-нибудь на надёжном сервере, потому что операционка на десктопе у тебя без году неделя навернётся и что будешь делать.

Вот ты пишешь, я создам /usr/local/myprog, а не /usr/local/bin, например, в целях тестирования. А вопрос, зачем пользователи сделали папку /usr/local/bin, там же и с названиями программ могут быть пересечения.

А затем, что /usr/bin из коробки внесена в системные пути, то есть программы можно запускать не набирая полный путь. А /usr/local/bin или внесена или может быть внесена вручную. То есть ты не сможешь написать myprog и чтобы у тебя программа запустилась из случайной папки вроде /usr/local/myprog.

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

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

Если хочется понять для чего сделано то или это посмотри команду PATH.

Обычно в переменную $PATH входят каталоги /bin, /usr/bin и /usr/local/bin.

Ну моя практика показывает, что /usr/local/bin может входить, а потом со временем может и не входить. А вот /bin и /usr/bin входят сразу из коробки. Причём всё это можно изменить для текущей консоли когда угодно, да и в целом для операционки.

И раз уж затронута эта тема, то исходник копируется в /usr/local/src, а не в /usr/local. То есть должно быть /usr/local/src/myprog, а после компиляции с помощью make файлы должны распределиться по подпапкам /usr/local, таких как /usr/local/bin и так далее.

А если ты не хочешь соблюдать эту логику, и делаешь /home/user/myprog, тогда озаботься, чтобы был хоть какой-нибудь репозиторий вроде /home/user/myprog/.git и далее можно использовать .gitignore и теневую сборку, то есть непосредственный билд в /home/user/build*-myprog.

Можно, кстати, делать билды и в /usr/local, при том, что она сама может лежать где угодно. В конце концов программа твоя и специально копировать её в /usr/local/src нет смысла. В общем со временем сам поймёшь и документацию будешь читать не формально, а по назначению.

Я вот открыл сейчас твою ссылку.
https://man.freebsd.org/cgi/man.cgi?query=hier&sektion=7&format=html

/usr/ contains the majority of user utilities and applications
-local/ local executables, libraries, etc, installed by pkg(7) or ports(7)
--bin/ local user utilities, see intro(1)
--etc/ local program configurations
--include/ local library headers
--lib/ local libraries
--lib32/ local 32-bit compatability libraries
--libdata/ local utility data files
--libexec/ utilities executed by local utilities
--sbin/ local administration utilities
--share/ local architecture-independent files
--share/doc/ local documentation
--share/doc/freebsd/ articles, books, FAQ, and handbooks available from the FreeBSD project
--share/man/ local manual pages; see man(1)

Где папка /usr/local/src? Теперь я вспоминаю твой комментарий.

ЛБ>В своем сообщении я дал ссылку на описание стандартной иерархии в документации — у меня такая. Директории /opt нет и в корне создавать я сам ничего не буду.

А, ну понятно, значит по твоей логике и /usr/local/src создавать тоже не надо. Я не считаю себя каким-то экспертом, но прочитанные когда-то давно пару статеек на эту тему всё же сделали из меня больше, чем совсем уж новичка. Действуя формально и опираясь на взятый откуда-то ограниченный источник знаний ты придумал /usr/local/myprog.

В чём причина? Ну потому что вот есть документация, о которой неизвестно, что она неполная. И есть желание сделать как в винде. И получатся какая-то ерунда бесполезная как для юниксов, так и для тебя. Потому я и говорю, благодаря поиску с помощью нейронок и книг программисты вступают в эру повышенной экспертности.

Причём экспертность эта самих программистов, а не просто внешних инструментов. Проблема здесь всё та же, Почему программисты прошлого были умнее (26.05.2022). Слишком быстрый перескок на новые технологии в основе которых лежат старые технологии, причём не сложные для понимания, просто их учат не все, или лучше сказать не только лишь все.

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