Могу ли я увидеть в файле журнала все задачи на основе графического интерфейса в альтернативном формате командной строки?

9

Например, я обычно открываю коврик для мыши (эквивалент gfit для xfce) из меню приложений. Тем не менее, я знаю, что вы также можете сделать это в терминале, набрав mousepad.

Следуя этому примеру, я хочу, чтобы всякий раз, когда я открывал коврик для мыши через графический интерфейс, в файле журнала записывалась новая строка, в которой указывалось что-то вроде Sep 5 15:35:11 lucho@lucho:~$ mousepad. В общем, я хочу регистрировать все действия с графическим интерфейсом, которые потенциально выполнимы через командную строку (например, открытие программ, изменение разрешений, изменение системных настроек и т. Д.), Но записанные в альтернативном формате выполнения командной строки . Я хочу это, чтобы улучшить мои знания о том, как использовать командную строку (не просматривая manстраницы). Есть много вещей, которые я делаю через графический интерфейс, которые я не делаю через командную строку (некоторые потенциально автоматизируются с помощью скрипта или сочетаний клавиш), и наличие этого файла журнала было бы хорошим способом изучить их.

Я знаю о существовании файла системного журнала, /var/logно это не то, что мне нужно. Насколько я знаю, приложение Activity Log Manager из репозиториев Ubuntu не показывает формат командной строки. Мне нужно что-то вроде файла .bash_history, который существует в моей домашней папке, но записывает мои действия на основе графического интерфейса.


источник
Вы можете использовать такой инструмент, как strace, чтобы заглянуть в работающую программу и посмотреть, какие системные вызовы она вызывает, хотя это сгенерирует огромные объемы данных
Amias
Если вы ищете программу, которая просто регистрирует двоичные имена программ, которые открываются в графическом интерфейсе, я могу сделать это в сценарии. Если это то, что вы хотите, дайте мне знать. Было бы лучше, если бы вы уточнили, каковы ваши требования на самом деле, поэтому, пожалуйста, отредактируйте свой вопрос. Запись действий на основе графического интерфейса, таких как нажатие кнопок или открытие новой вкладки в браузере, не может быть легко записана, потому что они не связаны с реальными командами оболочки
Сергей Колодяжный
@Serg Журнал, который вы предлагаете, наверняка будет тем, что я ищу. Что-то вроде журнала «Диспетчер задач» на основе имен CLI вместо имен GLI, которые, как предполагает существующий ответ, могут не совпадать. Например, если я открою «Поддержка языков» в настройках, я хочу знать его эквивалент CLI. И т.д ...
@luchonacho Хорошо, я начну писать сегодня, опубликую, когда он будет готов. Кстати, «Языковая поддержка» в настройках не имеет своего эквивалента. Некоторые вещи, такие как меню Bluetooth или фоновое меню, делают - вы можете указать unity-control-center backgroundили gnome-control-center background(в зависимости от вашего рабочего стола, Unity или XFCE или GNOME). Но внешний мир, наверное, только увидитgnome-control-center
Сергей Колодяжный
Существует множество способов выяснить, какую задачу выполняют приложения с графическим интерфейсом, и выяснить, каков их эквивалент. Мне кажется совершенно неэффективным пытаться слепо фиксировать все, что происходит грубой силой, будучи уверенным, что вы не поймаете все. Лучше выяснить в конкретных случаях, используя конкретные инструменты.
Джейкоб Влейм

Ответы:

2

Введение

Хотя невозможно зарегистрировать все действия графического интерфейса, такие вещи, как команды регистрации, соответствующие открытым окнам, могут быть выполнены. Ниже приведен простой скрипт Python, который делает эту работу. Он все еще находится в разработке, но выполняет 90% необходимой задачи.

Исходный код

#!/usr/bin/env python3
import gi
gi.require_version('Gtk', '3.0')
gi.require_version('Gdk', '3.0')
from gi.repository import Gdk,Gtk
import time
import os
import subprocess

def run_cmd(cmdlist):
    """ Reusable function for running external commands """
    new_env = dict(os.environ)
    new_env['LC_ALL'] = 'C'
    try:
        stdout = subprocess.check_output(cmdlist, env=new_env)
    except subprocess.CalledProcessError:
        pass
    else:
        if stdout:
            return stdout
def print_info(stack,event):
    base_xprop = ['xprop','-notype']
    for xid in stack:
        pid = None
        check_pid = run_cmd(base_xprop + [ '_NET_WM_PID', '-id',str(xid)])
        if check_pid:
            pid = check_pid.decode().split('=')[1].strip()
        with open('/proc/'+pid+'/cmdline') as fd:
            command = fd.read()
        print(time.strftime("%D %H:%M:%S" + " "*3) + event + pid + " " + command)

def main():
    sc = Gdk.Screen.get_default()
    old_stack = None

    while True:
        stack = [ win.get_xid() for win in sc.get_window_stack() ]
        if old_stack:
            # Difference between current and old stack will show new programs
            diff = set(stack) - set(old_stack)
            if diff:
                print_info(diff," 'New window open' ")
        else:
            print_info(stack," 'Script Started' ")

        old_stack = stack
        time.sleep(2)

if __name__ == '__main__': main()

Тестовый забег:

$ ./log_open_windows.py                                                                                                
01/25/17 15:33:13    'Script Started' 2915 nautilus-n
01/25/17 15:33:13    'Script Started' 3408 /opt/google/chrome/chrome
01/25/17 15:33:13    'Script Started' 12540 /usr/bin/python/usr/bin/x-terminal-emulator
01/25/17 15:33:13    'Script Started' 2454 compiz
01/25/17 15:33:13    'Script Started' 2454 compiz
01/25/17 15:33:13    'Script Started' 2454 compiz
01/25/17 15:33:13    'Script Started' 2454 compiz
01/25/17 15:33:13    'Script Started' 2454 compiz
01/25/17 15:33:21    'New window open' 15143 /usr/lib/firefox/firefox-new-window
01/25/17 15:33:27    'New window open' 15196 unity-control-center

Сценарий показывает метку времени, тип события, PID окна и соответствующую команду.

Как пользоваться

Применяются стандартные правила любого сценария. Убедитесь, что вы храните скрипт в ~/binкаталоге. Если у вас нет ~/binкаталога, создайте его. Сохраните файл скрипта там и убедитесь, что он исполняется с chmod +x ~/bin/log_open_windows.py. После этого вы можете запустить его из командной строки в любое время, позвонив ~/log_open_windows.pyв командной строке.

Сергей Колодяжный
источник
Спасибо. Выглядит многообещающе! Два вопроса. Как запустить это? Чего не хватает 10%?
Острота! +1 от меня!
Fabby
@luchonacho Я добавил параграф об использовании. Я бы порекомендовал вам использовать его вручную из командной строки, как я описал. Вы можете запустить его автоматически при запуске, но я не рекомендую делать это. Недостающие 10% - это несколько других функций, которые я хотел добавить, но я не думаю, что собираюсь их добавлять. Пока это работает достаточно хорошо. Но, может быть, я снова передумаю
Сергей Колодяжный
Это, вероятно, самое близкое к тому, что я искал, зная, что идеального решения не существует. Спасибо!
4

Предложение такого рода файла журнала в качестве основы для обучения - действительно блестящая идея!

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

Но у меня есть решение для части проблемы: имя программы в GUI иногда отличается от имени программы, которое нужно знать для команды оболочки, - не только если имя GUI переводится на местный язык.

Например, как запустить программу Filesв командной строке?

Нам нужно посмотреть все *.desktopфайлы на имя. Там мы находим команду в Execстроке:

locate -b '.desktop' | xargs grep -ls '^Name.*=Files$' | xargs grep '^Exec.*'

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

С помощью команды, я считаю , Filesможет быть nautilus, dolphinили active-filebrowser:

/etc/xdg/autostart/nautilus-autostart.desktop:Exec=nautilus -n
/usr/share/app-install/desktop/nemo:nemo.desktop:Exec=nemo %U
/usr/share/app-install/desktop/plasma-active:kde4__active-filebrowser.desktop:Exec=active-filebrowser -graphicssystem raster %u
/usr/share/applications/nautilus-folder-handler.desktop:Exec=nautilus %U
/usr/share/applications/nautilus.desktop:Exec=nautilus --new-window %U
/usr/share/applications/nautilus.desktop:Exec=nautilus --new-window
Volker Siegel
источник
Ммм, мой вопрос лежит в основе представления Linux с масштабируемой сложностью, где более сложные программы основаны на более простом коде, поэтому я подумал, что любое приложение с графическим интерфейсом полагается на команды терминала, но это может быть не так, поскольку терминал основан на коде bash, тогда как программное обеспечение может быть написано на Python или C ++ или др. Я не прав?
Уровни сложности существуют, но по-разному: в общем, есть системные вызовы, библиотечные функции и, кроме того, графический интерфейс пользователя или интерфейс командной строки - они являются альтернативами.
Фолькер Сигел,