Schrift
[thread]12795[/thread]

chmod nutzlos? - Ubuntu

Leser: 1


<< |< 1 2 >| >> 14 Einträge, 2 Seiten
Snicker
 2008-11-20 20:32
#116455 #116455
User since
2008-08-09
25 Artikel
BenutzerIn
[default_avatar]
Hi,
hab ein Programm geschrieben, dass auf Windows XP soweit gut läuft. Nun muss ich es noch modifizieren, so dass es auch auf einer Unix Umgebung lauffähig ist. Hierbei habe ich jedoch zwei Probleme.
Es soll eine "Einstellungen" Datei erstellt werden, die vom Benutzer geöffnet werden und anschließend automatisch ausgelesen werden kann.

1. Um der "Einstellungen" Datei volle Rechte zu gewähren, wollte ich mittels chmod die neuen Rechte zuweisen.
Code (perl): (dl )
chmod (744, $einstellungen);

Leider werden die neuen Rechte nicht übertragen. Liegt das möglicher Weise daran, dass ich Ubuntu als Live-CD gebootet habe? Die Datei "Einstellungen" wird auf einen USB-Stick gespeichert.

2. Problem: Die Datei wird nicht geöffnet. Eigentlich sollte ein Fenster mit den Einstellungen aufpopen.
Die betreffende Zeile funktioniert unter Windows, aber nicht unter Unix.
Code (perl): (dl )
open (EINSTELLUNGEN, "|$einstellungen");
GwenDragon
 2008-11-20 20:40
#116456 #116456
User since
2005-01-17
14533 Artikel
Admin1
[Homepage]
user image
1. dein chmod ist falsch. chmod braucht oktale Zahlen.
2. Du solltest sowohl bei chmod und open prüfen, warum es nicht klappte.
3. Warum eine Pipe? ist $einstellungen kein Dateiname?

Vielleicht so:
Code: (dl )
chmod (0744, $einstellungen) or die ("$!");

und
Code: (dl )
open (EINSTELLUNGEN, "|$einstellungen") or die ("$!");


Etwas schwierig, so zu vermuten mit nur zwei Zeilen Code, ohne das Skript zu sehen.
die Drachin, Gwendolyn


Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel

Linuxer
 2008-11-20 21:09
#116459 #116459
User since
2006-01-27
3870 Artikel
HausmeisterIn

user image
Da GwenDragon bereits das wesentliche genannt hat, hier noch eine weitere Anmerkung von mir:

Was ist denn bitte in $einstellungen für eine Datei angegeben.

Wenn Du ein open() mit einer Pipe machst, sollte in $einstellungen schon ein ausführbares Programm sein, dass Eingaben von STDIN erwartet/verarbeitet...

Ich hätte eher erwartet, dass dort eine Textdatei angegeben ist; also wäre wahrscheinlich ">" oder "<" als Filemode sinnvoller.

Allgemein wird die 3-Argument-Form des open() als sicherer erachtet. z.B.
Code (perl): (dl )
1
2
3
4
5
# $mode muss nicht sein; der Mode kann ruhig direkt angegeben sein;
# habe es hier nur zwecks Dokumentation in eine benannte Variable gepackt.
open my $filehandle, $mode, $path_of_file or die "$path_of_file: open($mode) failed: $!\n";
# ...
close $filehandle or die "$path_of_file: close($mode) failed: $!\n";


Ansonsten hätte Dir die Prüfung auf Erfolg und Ausgabe der Fehlermeldung entsprechendes verraten.

perlopentut
perldoc perlopentut

edit: Einleitung eingefügt.
meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
murphy
 2008-11-20 23:42
#116463 #116463
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
<haarspalterei>
GwenDragon+2008-11-20 19:40:32--
1. dein chmod ist falsch.


Vermutlich wahr, wenn es nicht den Zweck hatte, die Dateirechte auf "Benutzer darf schreiben und ausführen, Gruppe darf lesen und ausführen, andere düfen nichts, Datei ist sticky" zu setzen.

Quote
chmod braucht oktale Zahlen. [...]


Das braucht es nicht. chmod 484, $einstellungen funktioniert genausogut wie chmod 0744, $einstellungen...
</haarspalterei>
When C++ is your hammer, every problem looks like your thumb.
GwenDragon
 2008-11-21 10:00
#116466 #116466
User since
2005-01-17
14533 Artikel
Admin1
[Homepage]
user image
@murphy
natürlich geht jede Zahl.
Ich hätte sagen müssen: Bei chmod werden die Rechte meistens als Oktalzahl (wie in Unix üblich) angegeben.

Aber beim chmod mit 744 (also wohl ein Flüchtigkeitsfehler) sah es für mich nach 0744 = rwxr--r-- aus, denn sein chmod klappte ja nicht.

Allerdings kann ich hier auch nur vermuten, denn wir wissen nicht wo der Fehler steckt.
die Drachin, Gwendolyn


Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel

Snicker
 2008-11-21 17:51
#116493 #116493
User since
2008-08-09
25 Artikel
BenutzerIn
[default_avatar]
GwenDragon+2008-11-20 19:40:32--
1. dein chmod ist falsch. chmod braucht oktale Zahlen.
2. Du solltest sowohl bei chmod und open prüfen, warum es nicht klappte.
3. Warum eine Pipe? ist $einstellungen kein Dateiname?

Vielleicht so:
Code: (dl )
chmod (0744, $einstellungen) or die ("$!");

und
Code: (dl )
open (EINSTELLUNGEN, "|$einstellungen") or die ("$!");


Etwas schwierig, so zu vermuten mit nur zwei Zeilen Code, ohne das Skript zu sehen.


1.
beim chmod ändert sich leider nichts. Eine Fehlermeldung bekomme ich auch nicht zurück. Tippe mal, dass es an der Live session liegt.
Es ist schon richtig, dass 0744 = rwxr--r-- ist. Unter dem aktuellen User soll die Datei ausführbar sein. Dachte, dass ich dadurch die Textdatei $einstellungen in einem Fenster öffnen lassen könnte.

2./3.
das | ist, wie ich es nun nachgelesen habe auf Unix falsch. Bei Windows führt es dazu, dass das Programm / Datei im UI aufpoppt. In Windows wurde hier immer der Editor gestartet, der mit die Werte aus meiner Textdatei $einstellungen angezeigt hat.
Wie schaffe ich es, dass unter Unix sich z.B. gedit öffnet und den Inhalt der Textdatei $einstellungen anzeigt? Der User soll in der Lage sein, die Textdatei, ohne sie suchen zu müssen, modifizieren zu können.
Linuxer
 2008-11-21 18:03
#116494 #116494
User since
2006-01-27
3870 Artikel
HausmeisterIn

user image
Muss der Editor unbedingt fest angegeben sein?

Ich würde auf eine Umgebungsvariable $EDITOR prüfen; wenn sie existiert, diese auch nutzen; wenn nicht auf einen (fest kodierten) Standardeditor zurückfallen.

Beim Aufruf des Editors sollte man angeben können, dass er von STDIN lesen soll;

Auf Kommandoebene:
Code: (dl )
echo "Hallo Welt" | $EDITOR -


Im Perl:
Code (perl): (dl )
1
2
3
4
5
6
7
# ideal wäre noch ein Test, ob X oder Terminal verfügbar ist, oder nicht
# danach könnte man den festen Editor festlegen
my $editor = $ENV{EDITOR} || '/usr/bin/gvim';

open my $pipe, '|-', "$editor -" or die "Cannot open pipe to $editor: $!\n";
print $pipe $daten_fuer_editor;
close $pipe or die "Cannot close pipe to $editor: $!\n";

meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
murphy
 2008-11-21 18:09
#116495 #116495
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
Snicker+2008-11-21 16:51:25--
[...]
1.
beim chmod ändert sich leider nichts. Eine Fehlermeldung bekomme ich auch nicht zurück. Tippe mal, dass es an der Live session liegt.


Wenn die Datei auf einem unixfremden Dateisystem liegt, also zum Beispiel auf einem FAT-formatierten USB-Stick, kann es in der Tat sein, dass chmod wirkungslos ist. In dem Falle muss man notfalls die Mountoptionen für das betreffende Dateisystem so anpassen, dass die Rechte passend gesetzt sind.

Quote
Es ist schon richtig, dass 0744 = rwxr--r-- ist. Unter dem aktuellen User soll die Datei ausführbar sein. Dachte, dass ich dadurch die Textdatei $einstellungen in einem Fenster öffnen lassen könnte.


Das ist allerdings ein Trugschluss. Wenn man eine Datei ausführbar macht, wird der Kernel versuchen sie auszuführen, wenn er angewiesen wird, das zu tun. Bei einer reinen Textdatei ohne #!-Zeile wird das aber immer fehlschlagen.

Ein Mechanismus, der das "Starten" von Dateien und Anwendungsprogrammen in der gleichen Weise ermöglicht, ist unter Unix anders als unter Windows nicht in den Systemkern integriert. Ich persönlich halte dieses andere Verhalten auch für ein sinnvolles sicherheitsrelevantes Feature, aber das mag Geschmackssache sein.

Wenn Du ein Verhalten ähnlich wie unter Windows auslösen willst, musst Du eine API Deiner Desktopumgebung ansprechen. Unter Ubuntu also vermutlich irgendeine Funktion aus den GNOME-Bibliotheken. Da diese Bibliotheken in C geschrieben sind, wirst Du eventuell ein paar Probleme haben, sie mit Perl direkt anzusprechen, daher empfehle ich Dir, vielleicht einfach die Manpage des Programmes gnome-open durchzulesen und selbiges dann von Perl aus über -f system anzusteuern.

Quote
2./3.
das | ist, wie ich es nun nachgelesen habe auf Unix falsch. Bei Windows führt es dazu, dass das Programm / Datei im UI aufpoppt. In Windows wurde hier immer der Editor gestartet, der mit die Werte aus meiner Textdatei $einstellungen angezeigt hat.
[...]


Die Datei als Pipe zu öffnen, ist auch unter Windows falsch. Es mag zwar zufällig manchmal funktionieren, aber je nachdem was für ein Programm mit der Datei verknüpft ist, kann dabei alles mögliche unverhergesehene passieren, da die Eingabe dann eventuell an das Programm gesendet würde und nicht in die Datei.

Dieses unvorhersehbare, von Rechner zu Rechner unterschiedliche Verhalten, ist der genau der Grund, warum ich die Herangehensweise von Windows an das "Starten" einer Datei für nicht sehr glücklich halte.

Ich würde Dir also auch für die Windowsvariante Deines Programmes eher empfehlen, erst normal in die Datei zu schreiben und dann per -f system den Kommandozeilenbefehl start zu benutzen oder über ein geeignetes Modul direkt auf die entsprechende Funktion der Win32-API zuzugreifen.
When C++ is your hammer, every problem looks like your thumb.
murphy
 2008-11-21 18:17
#116497 #116497
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
Linuxer+2008-11-21 17:03:53--
Ich würde auf eine Umgebungsvariable $EDITOR prüfen; wenn sie existiert, diese auch nutzen; wenn nicht auf einen (fest kodierten) Standardeditor zurückfallen. [...]


Besser wäre es jedoch, zuerst die Umgebungsvariable VISUAL zu testen, dann EDITOR und dann auf ein Standardprogramm zurückzugreifen.

Traditionell gibt nämlich VISUAL ein Editorprogramm an, welches unter umständen eine grafische, zumindest aber eine bildschirmfüllende Benutzerschnittstelle wie vim oder emacs hat, während EDITOR ein Editorprogramm angibt, das mit minimalen Anforderungen an das Terminal zurechtkommt und deswegen unter Umständen wirklich auf einen primitiven zeilenweiser Editor wie ed eingestellt ist.

In den meisten Fällen sind auf modernen Unices allerdings sowohl EDITOR als auch VISUAL auf den gleichen Editor eingestellt :-)
When C++ is your hammer, every problem looks like your thumb.
topeg
 2008-11-21 22:24
#116508 #116508
User since
2006-07-10
2611 Artikel
BenutzerIn

user image
Ich denke es ist wünschenswert ein Graphisches Programm zu starten.
Wenn das misslingt, kann man immer noch auf VISUAL und EDITOR zurückgreifen.

Viele Distributionen folgen mittlerweile der LSB. ("lsb_release" gibt Information darüber)
darunter existieren auch die "XDG"-Tools unter anderem "xdg-open" Das öffnet eine Datei im vom Benutzer (Distribution) spezifizierten Editor (näheres dazu entweder mit "xdg-open --manual" oder "man xdg-open")

Leider haben die Programmierer nicht an uns gedacht und starten die Programme unabhängig.
Hier ein Beispiel wie man dennoch darauf warten kann, dass der Nutzer mit dem Bearbeiten fertig ist.
Code (perl): (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
#!/usr/bin/perl
use strict;
use warnings;

my $file='/tmp/test.txt';

# Datei erzeugen und mit irgendwas füllen
# echo ist einfach am kürzesten :)
system("echo Das ist ein test > $file");
# es gibt module,
# die zuverlässig unbenutzte temporäre Dateienamen erzeugen.
# für das Beispiel hier nutze ich sie nicht...


# Die xdg-tools des LSB sind der portabelste Weg,
# Benutzerspezifische Programme zu starten.
# Editor starten
system("xdg-open",$file) == 0 or die "$@";
# leider werden alle Prozesse unabhängig gestartet,
# sodass xdg-open sofort zurückkehrt.
# es wird also eine anderer weg benötigt,
# um heraus zu finden, wann der Nutzer mit dem Editieren fertig ist.

# Ein weg währe mittels "ps" abzufragen,
# wer den Dateinamen als Kommandozeilenoption übergeben bekommen hat.
# der Nachteil ist, dass es Möglichkeiten gibt
# Kommandos an ein Programm zu übergeben,
# die in der Kommandozeile nicht auftauchen.
# Also schaue ich in /proc um zu sehen,
# welche Programme die Datei geöffnet haben.
# zusätzlich überprüfe ich die Kommandozeile,
# vielleicht habe ich Glück. :)
# auch das ist nicht zuverlässig,
# denn das Programm könnte die Datei zwischenzeitlich schließen

# ein wenig warten...
select(undef,undef,undef,0.2);

# herausfinden welches Programm die Datei geöffnet hat
my @prgs;
# /proc auflisten
for my $prg (grep{m!/\d+$!}glob("/proc/*"))
{
  # eigens Programm ausschließen
  next if($prg=~/$$/);

  # nur Programme des Benutzers sind interessant
  if(-o $prg)
  {
    # enthält die Kommandozeile den Dateinamen?
    my $cmdline=do{local(@ARGV,$/)="$prg/cmdline"; <>};
    if($cmdline=~/\Q$file\E/)
    {
      my $exe = readlink("$prg/exe");
      my ($pid) = $prg=~m!/(\d+)$!;
      push(@prgs,[$pid,$exe]);
      last;
    }

    # Dateinamen der geöffneten Dateien vergleichen
    for my $fd (map{readlink($_)}glob("$prg/fd/*"))
    {
      # Wenn die Pfade gleich sind haben wir es gefunden
      if($fd eq $file)
      {
        my $exe = readlink("$prg/exe");
        my ($pid) = $prg=~m!/(\d+)$!;
        push(@prgs,[$pid,$exe]);
        last;
      }
    }
  }
}

# mal ausgeben wer es ist...
for my $prg (@prgs)
{ print "Running $prg->[1] to edit $file\n"; }

# darauf warten, dass das Programm beendet wird
my $still_running=@prgs;
while($still_running)
{
  sleep 1;
  $still_running=0;
  for my $prg (@prgs)
  { $still_running++ if(-e "/proc/".$prg->[0] && readlink("/proc/".$prg->[0]."/exe") eq $prg->[1]) }
}

# Datei wieder einlesen
my $data=do{ local(@ARGV,$/)=$file; <>; } warn "$!";
# Datei löschen
unlink($file) or warn "$!";
# daten ausgeben/verarbeiten
print "DATA:\n$data\n" if($data);


edit:
Fehlermeldungen hinzugefügt, aber jeder weiß ja wie er das zu handhaben hat :-)
<< |< 1 2 >| >> 14 Einträge, 2 Seiten



View all threads created 2008-11-20 20:32.