Суть программы

Сть программы предельна проста. Я замучался при перестановке системы ставить снова весь софт, и вспоминать что мне нужно, а потом выясняется, что что-то я забыл и приходится доставлять. Поэтому я написал програмульку rempac, которая будет вызыватся вместо стандартной(pacman, yaoutr,yum, apt-get) Принимать анологичные параметры,что и в этих программах(смотря какую использует) и сохранять в фаил названия программы которые устанавляиваются. Так при следующей установке\переустановке, мне не нужно будет нервничать, что я зыбыл что-то поствить.

https://wiki.archlinux.org/index.php/Pacman_Tips#Backing_up_and_retrieving_a_...

полуёбок

Разделите программу на фронтенд и бекенд. Фронтенд пусть хранит конфиги/логи в ~/.config/имя_программы и запускает с правами root'а бекенд, который делает, что ему нужно.

И для этого вам понадобился свой велосипед? Мда.

90 % линукса недостроенные велосипеды

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

Возможно вы правы. Идея работоспособна. Но, неужели все программы, которые требуют права root, и хотят хнаить конфигурацию в homedir пользователя делают такой костыль?

Был комментарий в котором соведомалось использовать suid. Я его сейчас не вижу... Вот не много почитал, и написал тестовый пример. Не работает.

[alex@dhcppc0 test]$ cat testsuid.cpp 
#include <iostream>
#include <sys/types.h>
#include <unistd.h>
#include <pwd.h>

using namespace std;

int main(){
	struct passwd *pw = getpwuid(geteuid());
	const char *homedir = pw->pw_dir;
	cout<< homedir<<endl;
}
[alex@dhcppc0 test]$ g++ testsuid.cpp -o testsuid
[alex@dhcppc0 test]$ chmod ug+s testsuid
[alex@dhcppc0 test]$ ls -l |grep testsuid
-rwsr-sr-x 1 alex users 8647 Июл  7 22:58 testsuid
-rw-r--r-- 1 alex users  216 Июл  7 22:57 testsuid.cpp
[alex@dhcppc0 test]$ ./testsuid
/home/alex
[alex@dhcppc0 test]$ sudo ./testsuid
/root

Так как функции makedir() fopen, и прочие не воспринимают символ «~» в пути к файлу, я получаю домашнюю директорию способом, описаным выше.

Но, неужели все программы, которые требуют права root, и хотят хнаить конфигурацию в homedir пользователя делают такой костыль?

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

А каталоги, в которых должны лежать конфиги, описаны спецификацией: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html. Вкратце: конфиги лежат в подкаталогах каталога $XDG_CONFIG_HOME, т.е. нужно читать переменную окружения. Если она не установлена, для неё предназначены дефолтные значения типа $HOME/.config.

Заставьте бекэнд читать конфиг и передавать настройки фронтэнду другим способом - через параметры командной строки, например.

Я замучался при перестановке системы ставить снова весь софт

перестань пользоваться виндой

Слава богу уже не пользуюсь виндоу уже который год. Идея про бекэнд и фронтэнд мне понравилась. Спасибо.

90 % линукса недостроенные велосипеды

И по этой причине нужно городить еще один?

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

Приложение планирую развивать. Мне интересно добавить харение значений в базедынных, и для файлов конфигурации использовать какую-либо библиотеку по чтению ini-подобных файлов. Всё это для меня новое - поэтому считаю что велосипед сделал не зря.

Цель же обозначена - приобретение навыков, откуда еще узнать, что за полтора часа с кофе и разговорами программу не напишешь. А по делу, текстовых файлов в дропбоксе со списком программ «must have» и списком установленных пакетов на случай падения диска вполне достаточно, имхо.

0.5 явно было лишним.

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

Но оскорбление с вашей стороны лишнее.

Это не оскорбление. Ты действительно тот, как тебя назвали.

валил бы ты на винфак со своими «папками/мамками»

Я так понимаю, что есть три факультета - линфак, винфак и онанфак. На последнем почему то самые упоротые... из за мозолей?;-)

2TC - еще куча системных конфигов лежит в /etc/ А вообще то для таких целей С++ это лишнее... хватает и баша (если так хочется лисапед со стразиками).

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

Напиши одностстрочный скрипт, который выводит список установленныйх пакетов и сохраняет его в файл. Засунь этот скрипт в крон. Таким образом ты с заданной периодичностью (раз в неделю, например) будешь иметь список установленного софта.

При переустановке системы список пакетов скармливается штатному пакетному менеджеру.

Профит!

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

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

Вы имеете в виду, чтоб кроме название пакета запоминать время\дату его инсталяции\деинсталяции\обновления?

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

Так вот на плюсах такие вещи не делают, это извращение. Мало что ли нормальных задач под плюсы, в т.ч. для обучения...

да, удобный просмотр и поиск по дате, пакету, какой программой

Вы безспорно правы. Я же не спорю, микроскопом гвозди не хорошо. Но задача родилась, желанеи изучить С++ появилось, и они сами дру друга как-то нашли. Программа не сложная, правда пишется быстро. Ну чего там? передача параметров в вызываемую мной программу, запоминание этих параметров без повторения,пропущеные через фильтр отсеивания служебных параметров... делов-то. А новый метериал изучен.

«Дорогу осилит идущий»(с)

Я бы таки осмелился посоветовать, после изучения С++ сделать это на баше или питоне. Почувствовать разницу тык скыть;-)

Удачи!

А как считаете удобно реазизовывать поиск по дате, пакету и прочее? Программа прередаёт все параметры в инсталятор пакетов который вызывает. Не сложно создать свои параметры. Но как сделать, чтоб они не вступали в конфликт с параметрами пакетного менеджера? Или снова разделить программу на 2 программы - установщик и просмотрщик? Тоесть устанавливается пакет к примеру так

$rempac -Sy qtcreator при этом вызывается $yaourt\pacman\apt-get\...\ -Sy qtcreator qtcreator сохраняется в текстовом файле(или в базе данных sqlite)

А потом я хочу сделать поиск по дате, к примеру. Удобноето делать так rempac -filterdate from=1995-06-22 to=date +%F Или по пакету rempac -filterpac '$qt.+' Но как достоверно узнать, что -filterdate или -filterpac не являются параметрами менеджера пакетов?