Ubuntu – Do GUI based application execute shell commands in the background

command linedconfgsettingslauncherunity

I have migrated to Ubuntu 16.04 just 2 days ago from Windows. I like the way we can customise the Unity Desktop. I am just playing around with the look and feel of the Desktop environment. Just like in Windows, I wanted the launcher to be at the bottom of the screen. On Googling, I found a command which goes like:

gsettings set com.canonical.Unity.Launcher launcher-position Bottom

Also, there are the unity-tweak-tool and dconf editor to get the job done. But these are the GUI approach of getting things done.

My questions are:

Do these GUI-based applications also execute the same command in the background?
How to have a peep at the internal working of these applications? I mean, is there any way of actually looking at the commands that are being executed at every click of button?
Do these applications open up a terminal in the background and execute these commands?

The answer here tells how to get the process's standard file descriptor. But, I did't get anything in the output.

Moreover, the strace -p pid -o output.txt command throws a huge amount of text into the file.

So, in short, is doing things using GUI applications same as doing stuff from the commandline?

Best Answer

Do these GUI-based applications also execute the same command in the background?

Yes and no. They write to the dconf database of settings, but they could be using different ways to do so. Programs written in Python will likely use the gi.repository.Gio module (I know because I use it a lot) or they can instead use gsettings as an external command by calling subprocess.Popen(['gsettings','org.some.schema','some-key','value']), and it will basically run as a shell command. A C program will use something similar, likely a gio.h library, or it could even use the exec() family of functions to do the same as Popen does in python. So to answer your title question: "Do GUI based application execute shell commands in the background?" They can, but likely it's not necessary because there's a library for whatever language that app is written in, and likely it's gonna be a bit faster to use a library function, than spawning a new process.

To give you a sample of how it's done with libraries/modules, feel free to take a look at the source code of my launcher list indicator. There I have written a function to create an instance of the Gio.Settings class and then use it to modify the Unity launcher depending on the type of list you want to have there.

How to have a peep at the internal working of these applications? I mean, is there any way of actually looking at the commands that are being executed at every click of button?

No. If you want to see which command is issued in that app's programming language as you press a button or click on window elements, then it's not possible. Read the source code of application, if it is possible to obtain it. You can use dconf watch / to see what settings are being changed, but not how it's done.

Technically, if you know how to operate a debugger, read memory addresses, and know some assembly language, then you can know what an app does on the CPU and memory level. This is known as software reverse engineering and is frequently used by security professionals to analyze malicious software and discover vulnerabilities in legitimate software.

Do these applications open up a terminal in the background and execute these commands?

No, there's no terminal attached. Many programs know where the dconf database for the user is located and write there. There's also an inter-process communication bus known as dbus, where programs can send signals, and a program will be like "Hey, that's a message for me!"

Addendum

Can applications run other applications ? Yes, that's done via standard fork() and execve() system calls. The essence of creating processes on Linux and other *nix systems is largely based on these two. Shell mechanism for running non-builtin commands uses that a lot in particular. When you run interactively
```
$ ls 
```
the shell will create a new process via fork(), that process will run execve() which will start ls. Because of how execve() that new forked process will be ls. The pipe() system call is what will help read back the output of ls. I strongly suggest reading my answer for What is the difference between pipe and redirection to understand how pipe mechanism works - it's not just | operator, but actually a syscall.
Can applications run shell commands ? No. Shell syntax is only understood by shell itself. What you can do, however, is start a shell with a command-line -c switch and provide appropriate commands. This is often used for custom shortcuts set in GNOME or other desktop environments, since custom shortcuts operate on executables and there is no shell to understand the syntax. Thus as an example, you'd do bash -c 'xdotool key Ctrl+Alt+T' to indirectly run xdotool command or bash -c 'cd $HOME/Desktop; touch New_File' to create new file on desktop via shortcut. This is particularly interesting example as you can use a shell variable, since you are using a shell explicitly.

Related Solutions

Ubuntu – Confused about what makes up the Ubuntu GUI

The GUI on Ubuntu is made up of a large number of pieces, working together. At the base level is Gnome 3 (Not to be confused with Gnome Shell). Gnome 3 uses GTK "widgets" to display all the parts of applications on the screen. On top of Gnome 3, Ubuntu uses Compiz and Unity to give the shell, which consists of the launcher, the menu bar, and the other Ubuntu pieces. Unity is the actual shell, while Compiz is what's known as a compositor - it deals with all of the graphics, transparencies, and animations you see.

So, any Gnome 3 theme will theme your Ubuntu box.

Hope this helps!

Ubuntu – Editing Gsettings unsuccesful when initiated from cron

The solution

It turned out the blind spot was a hole in my knowledge. The reason for not running specific commands in the python script (gsettings set) was because cron uses a very restricted set of environment variables.

To run a gsettings *set* command from cron (in general), it takes more than just running it from your personal cron file; the environment variable DBUS_SESSION_BUS_ADDRESS is needed for correct execution.

For reasons of convenience and flexibility, I solved it, inspired by- and based on the information in this post on stack overflow, by creating an "intermediate" script that both exports the variable and calls the actual script. The actual script edits gsettings. Since (normally) a process inherits the environment of its parent, now the script runs fine.

#!/bin/bash

PID=$(pgrep gnome-session)
export DBUS_SESSION_BUS_ADDRESS=$(grep -z DBUS_SESSION_BUS_ADDRESS /proc/$PID/environ|cut -d= -f2-);/path/to/script.py

(assuming script.py is executable)

Including the DBUS_SESSION_BUS_ADDRESS variable in a python script

To make editing gsettings possible by a python script, run by cron (and make an intermediate script unnecessary) the function below could be included in the script. It should be called before the gsettings set function in the script.

#!/usr/bin/env python3
import os
import subprocess

def set_envir():
    pid = subprocess.check_output(["pgrep", "gnome-session"]).decode("utf-8").strip()
    cmd = "grep -z DBUS_SESSION_BUS_ADDRESS /proc/"+pid+"/environ|cut -d= -f2-"
    os.environ["DBUS_SESSION_BUS_ADDRESS"] = subprocess.check_output(
        ['/bin/bash', '-c', cmd]).decode("utf-8").strip().replace("\0", "")

Best Answer

Addendum

Related Solutions

Ubuntu – Confused about what makes up the Ubuntu GUI

Ubuntu – Editing Gsettings unsuccesful when initiated from cron

Related Question