ist in der zeile

patch -p0 /usr/share/zenity/zenity.glade < /home/YourUserName/home/Desktop/zenity-2.24.0-focus.patch

nicht ein "home" zuviel?

übrigens erhalte ich eine fehlermeldung, scheint also für karmic so nicht zu funktionieren, hier gibt es die datei nicht!

 **** Can't find file /usr/share/zenity/zenity.glade : No such file or directory

zer schrieb:

ist in der zeile

patch -p0 /usr/share/zenity/zenity.glade < /home/YourUserName/home/Desktop/zenity-2.24.0-focus.patch

nicht ein "home" zuviel?

Ja. Ich würde da auch ~/Desktop/zenity-2.24.0-focus.patch statt /home/YourUserName/Desktop/zenity-2.24.0-focus.patch nehmen

übrigens erhalte ich eine fehlermeldung, scheint also für karmic so nicht zu funktionieren, hier gibt es die datei nicht!

 **** Can't find file /usr/share/zenity/zenity.glade : No such file or directory

Ist in 9.10 /usr/share/zenity/zenity.ui - vermutlich aber anderes Format (gtk.Builder statt libglade).

Hi!

Hab' das im Wiki abgeändert, und allgemeiner formuliert. Was mich wundert ist, dass der bug weiterhin auftritt; angeblich sei er ab 9.04 gefixt (so steht es zumindest im verlinkten Bugreport...). Und bei mir poppt das Zenity-Fenster unter Karmic auch brav im Vordergrund auf...

so long
hank

Der Patch ändert alle vorkommen von

  <property name="focus_on_map">False</property>

in

  <property name="focus_on_map">True</property>

In 9.10 enthält

/usr/share/zenity/zenity.ui

diese Änderungen schon, ich hab die Seite entsprechend geändert.

Es wäre sinnvoll, zu schauen, für welche Versionen der Patch nötig ist.

Evtl. wäre es auch sinnvoller, statt dem Patch direkt eine geänderte /usr/share/zenity/zenity.glade für die jeweiligen Versionen zu verlinken und in der Anleitung außerdem zu beschreiben, wie man mit dpkg-divert verhindert, dass die Datei bei einem Update überschrieben wird.

Hi!

diesch schrieb:

In 9.10 enthält

/usr/share/zenity/zenity.ui

diese Änderungen schon, ich hab die Seite entsprechend geändert.

Danke!

Es wäre sinnvoll, zu schauen, für welche Versionen der Patch nötig ist.

Da hast du definitiv Recht; zenity-2.24.0 dürfte wohl hardy oder intrepid sein. Werd' ich mich noch mal dran setzen...

Evtl. wäre es auch sinnvoller, statt dem Patch direkt eine geänderte /usr/share/zenity/zenity.glade für die jeweiligen Versionen zu verlinken und in der Anleitung außerdem zu beschreiben, wie man mit dpkg-divert verhindert, dass die Datei bei einem Update überschrieben wird.

Ja, auch eine Möglichkeit - wo gibts die entsprechend angepassten zenity.glade-Dateien? Müssten wir die basteln und anhängen? (und das verhindern geht sicher auch anders, allgemeingütltiger, oder?)

so long
hank

Heinrich Schwietering schrieb:

Es wäre sinnvoll, zu schauen, für welche Versionen der Patch nötig ist.

Da hast du definitiv Recht; zenity-2.24.0 dürfte wohl hardy oder intrepid sein. Werd' ich mich noch mal dran setzen...

Hier unter Hardy

zenity --version
2.22.1

Gruß...busfahrer

Hi!

@ busfahrer

Danke! Dann ist es wohl intrepid, jaunty checke ich gleich noch mal auf meiner Parallel-Installation... edit: und es ist 2.26.0 in Jaunty.

Hast du denn unter Hardy auch Probleme mit Zenity und im Hintergrund geöffneten Fenstern?

so long
hank

Heinrich Schwietering schrieb:

Hast du denn unter Hardy auch Probleme mit Zenity und im Hintergrund geöffneten Fenstern?

Bei mir geht das Zenity-Fenster im Vordergrund auf.Ich weiss allerdings nicht ob ich irgendwann mal nach einer Lösung für das Hintergrundproblem gesucht und gefunden habe,oder ob mein Zenity noch im original Zustand ist,da ich es eigentlich nicht nutze(zumindest nicht wissentlich).

Gruß...busfahrer

Heinrich Schwietering schrieb:

Evtl. wäre es auch sinnvoller, statt dem Patch direkt eine geänderte /usr/share/zenity/zenity.glade für die jeweiligen Versionen zu verlinken und in der Anleitung außerdem zu beschreiben, wie man mit dpkg-divert verhindert, dass die Datei bei einem Update überschrieben wird.

Ja, auch eine Möglichkeit - wo gibts die entsprechend angepassten zenity.glade-Dateien? Müssten wir die basteln und anhängen?

Falls sich sosnst nichts zwischen den Versionen geändert hat, könnte man sie von 9.10 nehmen, andernfalls muss man selbst patchen. Ich hab hier nur 9.10 da, daher kann ich nicht vergleichen.

(und das verhindern geht sicher auch anders, allgemeingütltiger, oder?)

sudo dpkg-divert --divert /usr/share/zenity/zenity.glade.original --rename  /usr/share/zenity/zenity.glade

sorgt dafür, dass dpkg die /usr/share/zenity/zenity.glade aus dem Paket auch bei allen Updates als /usr/share/zenity/zenity.glade.original speichert und die handgestrickte /usr/share/zenity/zenity.glade in Ruhe lässt.

Mit

sudo dpkg-divert --rename --remove /usr/share/zenity/zenity.glade

macht man das wieder rückgängig.

Ui - jetzt ist mir nach 30 Minuten schreiben, testen u. Layout die Verbindung eingebrochen, und weg war der Text. Jetzt schreibe ich nicht alles auf, was mir misfiel, sondern stelle nur noch Original u. meinen Vorschlag gegenüber.

• Original, Beispiel dd-Backup

1
2
3
4
5
6
7
8

#!/bin/bash
zenity --info --text "Im folgenden Auswahlfenster runterscrollen und das zu sichernde Laufwerk auswählen. Der Syntax lautet sdx.x" --title "Quelle"
cd / && cd /dev &&  Quelle=$(zenity --file-selection)
zenity --info --text "Jetzt wird der Ort ausgewählt, wohin das Image gespeichert werden soll" --title "Zielordner"
cd / && Ziel=$(zenity --file-selection --directory .)
zenity --info --text "Dateiname des Images festlegen. Das Image muss mit der Dateiendung .img (backup.img) gespeichert werden." --title "Imagename festlegen"
Dateiname=$(zenity --entry --title "Dateiname" --text "Beispiel: backup-sda1.img")
sudo dd if=$Quelle bs=1M of=$Ziel/$Dateiname & ddpid=$! ; while [ "$(ps -a | grep $ddpid)" ]; do sudo kill -SIGUSR1 $ddpid; sleep 5; done  

• Meine Änderungen

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

#!/bin/bash
zenity --info --title "Quelle" --text "Im folgenden Fenster die zu sichernde Partition auswählen."
cd /dev && Quelle=$(zenity --title "zu sichernde Partition auswählen" --file-selection --file-filter=sd??)
# exit if $Ziel is zero
[[ -z $Quelle ]] && exit 1
#
cd / && Ziel=$(zenity --file-selection --title "Ziel" --text "Jetzt wird der Ort ausgewählt, wohin das Image gespeichert werden soll" --directory .)
# exit if $Ziel is zero
[[ -z $Ziel ]] && exit 2
#
zenity --info --title "Imagename" --text "Imagename festlegen. Das Image soll mit der Dateiendung .img gespeichert werden."
Dateiname=$(zenity --entry --width=700 --title "Imagename Bsp.: sda1.img")
# exit if $Dateiname is zero
[[ -z $Dateiname ]] && exit 3
#
sudo dd if=$Quelle bs=1M of=$Ziel/$Dateiname & ddpid=$!
while [ "$(ps -p $ddpid)" ]
do
   sudo kill -SIGUSR1 $ddpid
sleep 5
done

Ich bin mir unsicher, wie unten das mit 'kill -SIGUSR1' arbeitet.

Das ernsteste Problem war, dass auch wenn der User 'Abbruch' tippte, unverdrossen dd gestartet wurde.

Weiter unten gibt es noch ein Beispiel mit find. Kann mir jemand

1

find ${1-.}

erklären?

Hallo,

deine Version des Skripts sieht in der Tat besser aus.

Zu dem SIGUSR1 und find kann ich dir leider auch nichts sagen.

Gruß, noisefloor

user unknown schrieb:

Ich bin mir unsicher, wie unten das mit 'kill -SIGUSR1' arbeitet.

Die manpage sagt:

Sending a USR1 signal to a running dd' process makes it print I/O statistics to standard error and then resume copying.

Es ist also für die Statusanzeige zuständig.

Gruß, cornix

Aha, d.h. SIGUSR1 ist ein 1., frei vom user (daher der Name) definierbares Signal (daher der Name), und dd nutzt das Signal, um mit dem Fortschritt zu antworten. Klingt einleuchtend, danke.

Und wer kennt ${1-.}?

user unknown schrieb:

Aha, d.h. SIGUSR1 ist ein 1., frei vom user (daher der Name) definierbares Signal (daher der Name)

Ja. Beispiel:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#!/bin/bash

COUNT=0

trap statusbericht SIGUSR1
trap exit SIGUSR2

function statusbericht () {
    echo -e "${0} läuft seit ${COUNT} Sekunden"
}

while true
  do
    sleep 1
    let COUNT++
  done

Und wer kennt ${1-.}?

Da bin ich auch neugierig. Nach meinen Tests wird es von der Bash nicht anders behandelt als ${1}. Wozu mag es gut sein?

edit:

Nach meinen Tests wird es von der Bash nicht anders behandelt

Ich nehme alles zurück, behaupte das Gegenteil und teste weiter.

edit2: Ich glaube, ich habe es. In einer Funktion entspricht ${PARAMETER-ERSATZ} dem ${PARAMETER} des Skriptes; wurde das Skript ohne Parameter aufgerufen, wird der Ersatz benutzt. Richtig?