Sono migrato a Ubuntu 16.04 solo 2 giorni fa da Windows. Mi piace il modo in cui possiamo personalizzare Unity Desktop. Sto solo giocando con l'aspetto grafico dell'ambiente desktop. Proprio come in Windows, volevo che il programma di avvio fosse nella parte inferiore dello schermo. Su Google ho trovato un comando che dice:
gsettings set com.canonical.Unity.Launcher launcher-position Bottom
Inoltre, ci sono lo strumento unity-tweak-tool e l'editor dconf per portare a termine il lavoro. Ma questi sono l'approccio GUI per portare a termine le cose.
Le mie domande sono:
- Queste applicazioni basate su GUI eseguono lo stesso comando anche in background?
- Come dare un'occhiata al funzionamento interno di queste applicazioni? Voglio dire, c'è un modo per guardare effettivamente i comandi che vengono eseguiti ad ogni clic del pulsante?
- Queste applicazioni aprono un terminale in background ed eseguono questi comandi?
La risposta qui spiega come ottenere il descrittore di file standard del processo. Ma non ho ottenuto nulla nell'output.
Inoltre, strace -p pid -o output.txt il comando genera un'enorme quantità di testo nel file.
Quindi, in breve, fare cose usando le applicazioni della GUI è lo stesso che fare cose dalla riga di comando?
Risposta accettata:
Queste applicazioni basate su GUI eseguono lo stesso comando anche in background?
Sì e no. Scrivono nel dconf database di impostazioni, ma potrebbero utilizzare diversi modi per farlo. I programmi scritti in Python utilizzeranno probabilmente gi.repository.Gio module (lo so perché lo uso molto) oppure possono invece usare gsettings come comando esterno chiamando subprocess.Popen(['gsettings','org.some.schema','some-key','value']) , e fondamentalmente verrà eseguito come comando di shell. Un programma C utilizzerà qualcosa di simile, probabilmente un gio.h libreria, oppure potrebbe anche usare exec() famiglia di funzioni per fare lo stesso di Popen fa in pitone. Quindi, per rispondere alla domanda del titolo:"L'applicazione basata su GUI esegue i comandi della shell in background?" Possono, ma probabilmente non è necessario perché esiste una libreria per qualsiasi lingua in cui è scritta l'app e probabilmente sarà un po' più veloce usare una funzione di libreria, piuttosto che generare un nuovo processo.
Per darti un esempio di come è fatto con le librerie/moduli, sentiti libero di dare un'occhiata al codice sorgente del mio indicatore dell'elenco di avvio. Lì ho scritto una funzione per creare un'istanza di Gio.Settings class e quindi utilizzalo per modificare Unity launcher a seconda del tipo di elenco che desideri avere lì.
Come dare un'occhiata al funzionamento interno di queste applicazioni? Voglio dire, c'è un modo per guardare effettivamente i comandi che vengono eseguiti ad ogni clic del pulsante?
No. Se vuoi vedere quale comando viene emesso nel linguaggio di programmazione di quell'app mentre premi un pulsante o fai clic sugli elementi della finestra, non è possibile. Leggere il codice sorgente dell'applicazione, se è possibile ottenerlo. Puoi usare dconf watch / per vedere quali impostazioni vengono modificate, ma non come è stato fatto.
Tecnicamente, se sai come utilizzare un debugger, leggere indirizzi di memoria e conoscere alcuni linguaggi assembly, puoi sapere cosa fa un'app a livello di CPU e memoria. Questo è noto come ingegneria inversa del software ed è spesso utilizzato dai professionisti della sicurezza per analizzare il software dannoso e scoprire le vulnerabilità nel software legittimo.
Queste applicazioni aprono un terminale in background ed eseguono questi comandi?
No, non c'è nessun terminale collegato. Molti programmi sanno dove si trova dconf il database per l'utente si trova e scrive lì. C'è anche un bus di comunicazione tra processi noto come dbus , dove i programmi possono inviare segnali e un programma sarà come "Ehi, questo è un messaggio per me!"
Addendum
-
Le applicazioni possono eseguire altre applicazioni? Sì, è possibile tramite
fork()standard eexecve()chiamate di sistema. L'essenza della creazione di processi su Linux e altri sistemi *nix è ampiamente basata su questi due. Il meccanismo della shell per l'esecuzione di comandi non integrati lo usa molto in particolare. Quando corri in modo interattivo$ lsla shell creerà un nuovo processo tramite
fork(), quel processo eseguiràexecve()che avvieràls. A causa di comeexecve()quel nuovo processo biforcato saràls. Ilpipe()la chiamata di sistema è ciò che aiuterà a rileggere l'output dils. Suggerisco vivamente di leggere la mia risposta per Qual è la differenza tra pipe e reindirizzamento per capire come funziona il meccanismo della pipe:non è solo|operatore, ma in realtà una syscall. -
Le applicazioni possono eseguire comandi di shell? No. La sintassi della shell è compresa solo dalla shell stessa. Quello che puoi fare, tuttavia, è avviare una shell con una riga di comando
-ccambiare e fornire i comandi appropriati. Questo è spesso usato per scorciatoie personalizzate impostate in GNOME o altri ambienti desktop, poiché le scorciatoie personalizzate operano su eseguibili e non esiste una shell per comprendere la sintassi. Ad esempio, farestibash -c 'xdotool key Ctrl+Alt+T'per eseguire indirettamentexdotoolcomando obash -c 'cd $HOME/Desktop; touch New_File'per creare un nuovo file sul desktop tramite collegamento. Questo è un esempio particolarmente interessante in quanto puoi usare una variabile di shell, dato che stai usando una shell in modo esplicito.