Як знайти всі системні файли, які я редагував за допомогою `gedit`?


2

Спочатку я збирався задати питання "Знайти всі файли, які я створив / змінив після встановлення?" але це дублікат ( Знайти всі файли у файловій системі, яку я відредагував або створив ), на яку немає задовільної відповіді, оскільки вона включає матеріали, завантажені та ніколи не змінені, а також тисячі мініатюр, які Nautilus створив під моїм невідомим для мене ідентифікатором користувача .

Причиною цієї потреби є те, що я написав чудовий сценарій для відключення USB-порту на своєму ноутбуці, який завжди має потужність, щоб виграти виграш.

Зараз я дуже незадоволений тим, що мій завжди живий USB-порт за проектом вимикається під час призупинення або відключення. Я хочу відстежувати та повертати програми ті системні конфігурації, з якими я налаштований gedit. Маючи слабку пам'ять для імпровізованих речей, я не можу пригадати, що я змінив.

Як знайти всі файли, які я створив або змінив gedit?

Я створив сценарій оболонки під назвою , gsuякий використовує pkexecдля заміни gksu gedit( Як я можу створити нову команду «gksu» на основі pkexec? ). Я зміню його, щоб увімкнути всі системні файли, відредаговані з останньою датою.

Тим часом хтось натякнув на це посилання, всі команди sudo за допомогою gedit десь були записані. Питання в тому, де і як їх скласти перелік grepчи що завгодно?

Зверніть увагу, я можу знайти це за допомогою інших трудомістких засобів, але вважаю, що це важливе питання, яке може виникнути також у багатьох інших.


1
:) Ти падаєш у ту саму яму, як і раніше. Я навчився залишати спеціальний тег, де б я щось змінив у конфігурації, наприклад, моє старе ім’я користувача ##sneetsher: commentабо //sneetsher: commentщоб я міг їх збирати, використовуючи grepперед перевстановленням або оновленням. Але якщо всі ваші правки використовуються gedit, gedit за замовчуванням залишає прихований файл резервної копії, його ім'я закінчується на ~. Таким чином, ви можете знайти свої відредаговані файли серед результатів sudo updatedb; locate -br ~$
user.dz

1
Насправді я розміщую коментарі майже до всіх сценаріїв, коли я змінюю їх із причин. Потім я записую ім'я скрипта в електронну таблицю, що кот вводить код за допомогою команди "grep" і скидає вихід у сусідні комірки. У цьому випадку з питанням щедрості для іншої людини я не став :(
WinEunuuchs2Unix

Відповіді:


2

Я щойно відредагував "системний" файл за допомогою цієї команди, щоб відкрити файл:

sudo -H gedit /etc/gtk-3.0/settings.ini

Потім я оглянув останній запис ~/.local/share/recently-used.xbelі побачив це:

  <bookmark href="file:///etc/gtk-3.0/settings.ini" added="2016-11-14T02:04:05Z" modified="2016-11-14T02:04:05Z" visited="2016-11-14T02:04:05Z">
    <info>
      <metadata owner="http://freedesktop.org">
        <mime:mime-type type="text/plain"/>
        <bookmark:groups>
          <bookmark:group>gedit</bookmark:group>
        </bookmark:groups>
        <bookmark:applications>
          <bookmark:application name="gedit" exec="&apos;gedit %u&apos;" modified="2016-11-14T02:04:05Z" count="1"/>
        </bookmark:applications>
      </metadata>
    </info>
  </bookmark>

Обмеження:

  • що recently-used.xbelзміст не показує , як ви викликали gedit.
  • необов’язково, щоб файл мав редагуватися чи створюватися за допомогою gedit; просто перегляд файлу з geditотримує файл у списку.

Візуальний огляд файлу здається безпечнішим, ніж використання коду для отримання необхідної інформації. Щось подібне grep -B5 '<bookmark:group>gedit</bookmark:group>' recently-used.xbel | grep 'bookmark href=' | grep -v '///home/'може допомогти виділити системні файли, які редагував gedit. Але це спрацює лише в тому випадку, якщо geditперша програма буде вказана в bookmark:groupфайлі для саме цього файлу. Якщо ви відредагували файл раніше за допомогою іншої програми, в яку записуєтесь recently-used.xbel, ви можете не захопити цей файл.

    <bookmark:groups>
      <bookmark:group>geany</bookmark:group>
      <bookmark:group>gedit</bookmark:group>
    </bookmark:groups>

У будь-якому випадку це вихід grepкоманди:

~/.local/share $ grep -B5 '<bookmark:group>gedit</bookmark:group>' recently-used.xbel | grep 'bookmark href=' | grep -v '///home/'
  <bookmark href="file:///usr/share/themes/Adwaita/gtk-2.0/gtkrc" added="2016-10-15T09:38:31Z" modified="2016-10-15T09:38:31Z" visited="2016-10-15T09:38:31Z">
  <bookmark href="file:///usr/share/themes/Numix/gtk-2.0/gtkrc" added="2016-10-15T09:40:25Z" modified="2016-10-15T09:40:25Z" visited="2016-10-15T09:40:25Z">
  <bookmark href="file:///usr/share/themes/Lubuntu-default/gtk-3.0/gtk-lubuntu.css" added="2016-10-27T03:26:38Z" modified="2016-10-27T03:26:38Z" visited="2016-10-27T03:26:38Z">
  <bookmark href="file:///etc/gtk-3.0/settings.ini.dpkg-old" added="2016-11-14T02:03:44Z" modified="2016-11-14T02:03:44Z" visited="2016-11-14T02:03:44Z">
  <bookmark href="file:///etc/gtk-3.0/settings.ini" added="2016-11-14T02:04:05Z" modified="2016-11-14T02:04:05Z" visited="2016-11-14T02:04:05Z">
~/.local/share $ 

Коли я скопіював і вставив команду, він створив помилку на моєму Ubuntu 16.04:$ ~/.local/share $ grep -B5 '<bookmark:group>gedit</bookmark:group>' recently-used.xbel | grep 'bookmark href=' | grep -v '///home/' bash: /home/rick/.local/share: Is a directory
WinEunuuchs2Unix

А як щодо чогось простішого, як просто grep '<bookmark:group>gedit</bookmark:group>' recently-used.xbel? Це теж не працює? Для чого потрібні атрибути файлів recently-used.xbelу вашій системі? Мої є -rw-------(теж 16.04).
ДК Бозе

0

Усі sudoвиклики реєструються за замовчуванням, а не лише sudo gedit. Див /var/log/auth.log, або в сучасних системах journalctl $(which sudo). Точно так же для pkexec: journalctl $(which pkexec).

Це запитання має приклад sudoвідображення у /var/log/auth.log:

Jul 16 11:50:56 laptop sudo: mv : 3 incorrect password attempts ; TTY=unknown ; PWD=/home/mv ; USER=root ; COMMAND=/usr/bin/env -u LANGUAGE LC_MESSAGES=C /bin/sh /tmp/tmpBHXhYV/:script:

Що вам потрібно - це COMMAND=...розділ.


Я не закликаю gedit використовувати sudo. Я завжди раніше використовував gksu. Використання команди: 1 $ journalctl $ (що gksu) `призводить до -- No entries --використання того ж з sudoпараметром, перераховує 23 записи з сьогоднішнього дня, жоден з яких не містить gksu. Чи варто вважати, що gksu geditв системних файлах немає файлу журналу ?
WinEunuuchs2Unix

@ WinEunuuchs2Unix gksuсам по собі не робить ніякої автентифікації, це, по суті, обгортка навколо suабо sudo. Подивіться, чи suє auth.logзаписи.
муру

$ journalctl $ (що су) - Немає записів -
WinEunuuchs2Unix

Хм, тоді мені потрібно встановити, gksuщоб побачити, куди він скидає журнали. Ще одна причина не використовувати gksuабо gksudo, коли звичайна sudo -iпрацює чудово.
муру

Щойно я отримав .bashrc скопійований на / root, так що sudo -i дарує мені приємні кольори сьогодні вночі. Я думав, що судо для редагування було персоною нон-грата.
WinEunuuchs2Unix
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.