Programmstart in C++
Jens Binder
Ich habe folgendes (einfaches) Problem, auf das ich trotz Literatur (noch)
keine antwort habe!
Ich möchte ein grafisches Frontend für ein Linux-Programm bauen! (mittels
C++ und Qt)
Auf Knopfdruck soll das Programm mit den vorher eingestellten Parametern
gestartet werden! Mit welchem Befehl kann ich nun dieses Programm starten
und gegebenenfalls die Ausgaben gleich auf ein anderes Programm pipen?!?
dank für jede Hilfe!
jens.
ps: im Netz fanden sich die Befehle execlp(..) oder sh(...) - hab' ich aber
noch nicht probiert
Michael Uplawski
Wenn ich schonmal da bin...
On Sat, 1 Dec 2001 11:50:23 +0100, Jens Binder <jen...@cs.tu-berlin.de> wrote:
> Auf Knopfdruck soll das Programm mit den vorher eingestellten Parametern
> gestartet werden! Mit welchem Befehl kann ich nun dieses Programm starten
> und gegebenenfalls die Ausgaben gleich auf ein anderes Programm pipen?!?
Irgendjemand würde jetzt schreiben: man system
Das wäre keine schlechte Antwort. Wie elegant brauchst du es?
Cheerio,
Der_Ups.
--
gpg / pgp: 1024D/EBF862F0 2048g/92FB166A
created: 2001-09-10 expires: 2002-09-10
fingerprint: 7AF1 8CDC 31F8 CF87 C5C0 1F6B DBF6 EED4 EBF8 62F0
User: Michael Uplawski <der...@web.de>
King Leo - Martin Oberzalek
> Hej zusamen!
>
> Ich habe folgendes (einfaches) Problem, auf das ich trotz Literatur (noch)
> keine antwort habe!
>
> Ich möchte ein grafisches Frontend für ein Linux-Programm bauen! (mittels
> C++ und Qt)
>
> Auf Knopfdruck soll das Programm mit den vorher eingestellten Parametern
> gestartet werden! Mit welchem Befehl kann ich nun dieses Programm starten
> und gegebenenfalls die Ausgaben gleich auf ein anderes Programm pipen?!?
Wenn du vielleicht eh ein KDE Programm bastelt entspricht KProcess, bzw
KProcIO vielleicht deinen Wünschen.
--
Even the smallest person can change the cause of the future.
Jens Binder
> Das wäre keine schlechte Antwort. Wie elegant brauchst du es?
>
> Cheerio,
>
nun dann werde ich mal ein wenig präziser:
Ich möchte ein Frontend zu a2ps schreiben auf reiner Qt-Basis - also ohne
KDE-Biliotheken.
letztendlich soll mein Programm also nur a2ps mit den vorher vom Benutzer
eingegebenen Parametern gestartet werden!
so was wie
cout << "a2ps" << "... Paramterliste ... "
wird mir dabei wohl kaum helfen...
also ...
Ich brauche einen C++ Befehl, welcher eben jenes a2ps mit den eingegebenen
Parametern startet und gegebenenfalls das Ergebnis gleich auf gv pipe't (für
preview)...
Oder klappt das:
<irgendwo im Code>
a2ps << 'parameter1' << 'par.2' ... usw.?!?
jens.
Felix von Leitner
> Oder klappt das:
> <irgendwo im Code>
> a2ps << 'parameter1' << 'par.2' ... usw.?!?
Du bist ja so derartig unwissend, vergiß das Projekt.
Wer sich selbst in so super-elementaren Dingen nicht selber helfen kann,
ist offenbar nicht selbständig lebensfähig. Such dir einen anderen
Beruf. Oh Gott, und sowas postet von einer Uni!
Michael Uplawski
>> Irgendjemand würde jetzt schreiben: man system
>> Das wäre keine schlechte Antwort. Wie elegant brauchst du es?
>
> a2ps << 'parameter1' << 'par.2' ... usw.?!?
Okay, das geht nicht (ohne weiteres). Du kannst freilich einiges in
C++-Klassen packen und kappseln und überladen und biegen und rühren...
bis das da oben doch funktioniert... - so ähnlich.. anders.
Ich glaube, du solltest (falls das wirklich neu war), doch system()
ansehen.
Der andere Vorschlag zielte auch auf ein KDE-Projekt ab, was du
ausschließen moechtest.
Sag' mir bescheid, wenn ich recht habe, anderenfalls: Sorry.
Um den Operator '<<' zu benutzen, musst du ihn passend überladen.
Und ein entsprechendes Objekt musst du auch konstruieren.
Ich habe das starke Gefühl, dass du das nicht willst.
Cheerio.
f'up to poster.
Michael.
Jens Binder
hatte das 'man system' völlig überlesen ...
"Felix von Leitner" <usenet-...@fefe.de> schrieb im Newsbeitrag
news:3c0a...@fefe.de...
Danke für die netten Worte!
Jens Binder
"Michael Uplawski" <upla...@quercus.franken.de> schrieb im Newsbeitrag
news:slrna0kkc5....@quercus.franken.de...>
> Ich glaube, du solltest (falls das wirklich neu war), doch system()
> ansehen.
Das habe ich in deinem ersten Posting übersehen ...
war dummerweise genau der benötigte Befehl ... mein zweiter Hilferuf ist
somit obsolet!
> Um den Operator '<<' zu benutzen, musst du ihn passend überladen.
> Und ein entsprechendes Objekt musst du auch konstruieren.
>
Das wollte ich nicht ... und wäre für's erste zu komplex!!
Danke für die Hilfe und verzeih' die konfusion durch meine unaufmerksamkeit
...
jens.
Michael Uplawski
<usenet-...@fefe.de> wrote:
> Du bist ja so derartig unwissend, vergiß das Projekt.
> Wer sich selbst in so super-elementaren Dingen nicht selber helfen kann,
> ist offenbar nicht selbständig lebensfähig. Such dir einen anderen
> Beruf. Oh Gott, und sowas postet von einer Uni!
Oh Gott, und sowas postet.
Rudolf Polzer
> On Sun, 2 Dec 2001 00:58:58 +0100, Jens Binder <jen...@cs.tu-berlin.de> wrote:
> >> Irgendjemand würde jetzt schreiben: man system
> >> Das wäre keine schlechte Antwort. Wie elegant brauchst du es?
> >
> > nun dann werde ich mal ein wenig präziser:
> (...)
>
> > a2ps << 'parameter1' << 'par.2' ... usw.?!?
>
> Okay, das geht nicht (ohne weiteres). Du kannst freilich einiges in
> C++-Klassen packen und kappseln und überladen und biegen und rühren...
> bis das da oben doch funktioniert... - so ähnlich.. anders.
> Sag' mir bescheid, wenn ich recht habe, anderenfalls: Sorry.
> Um den Operator '<<' zu benutzen, musst du ihn passend überladen.
> Und ein entsprechendes Objekt musst du auch konstruieren.
Und in diesem Objekt wahlweise system() oder eine der exec-Funktionen
aufrufen - womit man wieder beim Ausgangsproblem ist *eg*
Wobei ein
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <errno.h>
pid_t checked_fork ()
{
pid_t x = fork ();
if (x == -1)
throw errno;
return x;
}
// ...
pid_t pid = checked_fork ();
if (!pid)
{
execl ("/usr/bin/a2ps", "a2ps", "parameter1", "par.2" /* usw. */, 0);
exit (1);
}
else
waitpid (pid, 0, 0);
auch sehr lehrreicht ist. Aber die Pipe ist dann anders zu handhaben -
dann würde ich die execl-Zeile so schreiben:
execl ("/bin/sh", "sh", "-c", "a2ps parameter1 par.2 ... | gv ...", 0);
Dann kann man aber auch gleich system() nehmen, weil man hier in execl
genau das macht, was man durch dessen Verwendung eigentlich vermeiden
will: das Parsing von Argumenten durch die Shell, was bei Argumenten,
die von "außen" stammen, ziemlich unsicher ist.
Der Code ist allerdings ungetestet, insbesondere die waitpid-Zeile.
> f'up to poster.
Ignoriert, da eine Ergänzung einfach sein musste.
--
POST = Personen ohne sinnvolle Tätigkeit
[Dieter Bruegmann in dtj]
Michael Uplawski
On Mon, 3 Dec 2001 20:18:19 +0100, Rudolf Polzer <adsg...@durchnull.de> wrote:
(...)
> execl ("/usr/bin/a2ps", "a2ps", "parameter1", "par.2" /* usw. */, 0);
Das ist in der Tat schöner, als alles, was ich jetzt aus dem Ärmel
geschüttelt hätte. Aber vor dem Hintergrund des Initialpostings ...
naja.
Einen neuen Konverter für Ascii nach Postscript zu schreiben, der
meinetwegen doch über den Schiebeoperator gefüttert wird, käme dagegen
meiner Wunschlösung recht nahe... ;-)
> Der Code ist allerdings ungetestet, insbesondere die waitpid-Zeile.
>
>> f'up to poster.
>
> Ignoriert, da eine Ergänzung einfach sein musste.
So kann ich das auch akzeptieren.
Cheerio,
Der_Ups.
Lukas Mai
[...]
> execl ("/usr/bin/a2ps", "a2ps", "parameter1", "par.2" /* usw. */, 0);
[...]
Uh-oh, execl() ist eine Funktion, die beliebig viele Parameter
entgegennimmt. Abgeschlossen wird die Parameterliste durch einen
NULL-Zeiger. Du übergibst aber 0 (integer). Das könnte zu Problemen
führen, weil der Compiler ja nicht weiß, welchen Typ du genau brauchst.
Besser ist wohl (char *)0 oder (char *)NULL.
Nur meine 0.02 Euro.
Lukas
--
There is no .
Rudolf Polzer
Also (void *)0. Alles andere ist Overkill und unnötig. Oder muss das
ein char * sein? AFAIK müssen alle Pointertypen identisch repräsentiert
sein.
--
For the sake of who I am, I am myself. [EoE Part II, translated]
Lukas Mai
> Lukas Mai <lu...@saintmail.net> wrote:
>
> > Uh-oh, execl() ist eine Funktion, die beliebig viele Parameter
> > entgegennimmt. Abgeschlossen wird die Parameterliste durch einen
> > NULL-Zeiger. Du übergibst aber 0 (integer). Das könnte zu Problemen
> > führen, weil der Compiler ja nicht weiß, welchen Typ du genau
> > brauchst. Besser ist wohl (char *)0 oder (char *)NULL.
>
> Also (void *)0. Alles andere ist Overkill und unnötig. Oder muss das
> ein char * sein? AFAIK müssen alle Pointertypen identisch
> repräsentiert sein.
AFAIK garantiert der Standard nur, dass char * und void * die gleiche
Repräsentation haben. Z.B. muss ein int * nicht kompatibel zu einem
long * sein.
Da execl() lauter char *'s erwartet, würde ich auch ein (char *)NULL
übergeben. Wieso soll das Overkill sein? NULL kann auch gut als 0 oder
0L definiert sein.
Ich schätze aber mal, das void * hier genausogut funktionieren würde.
Alle andere Pointertypen müssen nicht kompatibel sein.
Felix von Leitner
> Ich schätze aber mal, das void * hier genausogut funktionieren würde.
> Alle andere Pointertypen müssen nicht kompatibel sein.
Nicht schätzen. Standard lesen.
0 ist ein völlig legaler Zeiger und er ist der NULL Zeiger, auch wenn
dieser im Speicher anders aussieht als der Integer 0.
Es gibt übrigens auch eine FAQ zu C. Wenn man die vor dem Posten liest,
macht man sich deutlich weniger zum Deppen.
Felix
Rudolf Polzer
> Rudolf Polzer schrob:
>
> > Lukas Mai <lu...@saintmail.net> wrote:
> >
> > > Uh-oh, execl() ist eine Funktion, die beliebig viele Parameter
> > > entgegennimmt. Abgeschlossen wird die Parameterliste durch einen
> > > NULL-Zeiger. Du übergibst aber 0 (integer). Das könnte zu Problemen
> > > führen, weil der Compiler ja nicht weiß, welchen Typ du genau
> > > brauchst. Besser ist wohl (char *)0 oder (char *)NULL.
> >
> > Also (void *)0. Alles andere ist Overkill und unnötig. Oder muss das
> > ein char * sein? AFAIK müssen alle Pointertypen identisch
> > repräsentiert sein.
>
> AFAIK garantiert der Standard nur, dass char * und void * die gleiche
> Repräsentation haben. Z.B. muss ein int * nicht kompatibel zu einem
> long * sein.
Wirklich? Jeder Pointertyp ist nach (void *) castbar. Ein solcher
cast muss AFAIK bijektiv sein, denn die Invariante
egalwas *a, *b;
(a < b) == ((void *)a < (void *)b);
muss gelten.
> Da execl() lauter char *'s erwartet, würde ich auch ein (char *)NULL
> übergeben. Wieso soll das Overkill sein?
Weil man immer den "schwächsten" Typ verwenden sollte, der möglich ist.
Das wäre hier void* und nicht char*.
> NULL kann auch gut als 0 oder
> 0L definiert sein.
> Ich schätze aber mal, das void * hier genausogut funktionieren würde.
> Alle andere Pointertypen müssen nicht kompatibel sein.
Die Frage bleibt im Raum.
--
2.4.5 in arch/sparc/kernel/sunos_ioctl.c(64):
Binary compatibility is good American knowhow fuckin' up.
Rudolf Polzer
> > Ich schätze aber mal, das void * hier genausogut funktionieren würde.
> > Alle andere Pointertypen müssen nicht kompatibel sein.
>
> Nicht schätzen. Standard lesen.
Wo gibts den, ohne ihn bezahlen zu müssen? Hab schon genügend für "The
C++ Programming Language" ausgegeben, und der Standard vom ANSI ist
nicht gerade billig.
> 0 ist ein völlig legaler Zeiger und er ist der NULL Zeiger, auch wenn
> dieser im Speicher anders aussieht als der Integer 0.
>
> Es gibt übrigens auch eine FAQ zu C. Wenn man die vor dem Posten liest,
> macht man sich deutlich weniger zum Deppen.
Gibt es auch eine gute zu C++?
Hast du die Frage überhaupt gelesen?
Es ging um eine Funktion
void foo (char *x ...);
und den Aufruf
foo ("hello", "world", 0);
Die 0 ist hier definitiv falsch, wenn int und void* unterschiedlich groß
sind, da sie hier als int und nicht als void* gelesen wird. Ansonsten dürfte
man hier keine 1 schreiben.
Und dann ging es darum, ob
(void *)0
und
(char *)0
innerhalb einer Ellipse gleich repräsentiert sein müssen. Und AFAIK
ist der >-Operator für Pointer so definiert, dass eine identische
Repräsentation folgt (bzw. dass void* eine Obermenge aller Pointertypen
ist, es aber durchaus zulässig wäre, wenn int* nur gerade Werte annehmen
darf).
Interessant wäre es jetzt, wenn ein int* als "Speicheradresse/4" und ein
void* als "Speicheradresse" repräsentiert würde...
--
The easiest way to kill a Linux system:
www42:~ # rm /dev/null
Also possible:
www42:~ # chmod 000 /dev/null
Lukas Mai
>
> Wirklich? Jeder Pointertyp ist nach (void *) castbar. Ein solcher
> cast muss AFAIK bijektiv sein, denn die Invariante
>
> egalwas *a, *b;
> (a < b) == ((void *)a < (void *)b);
>
> muss gelten.
In C auf jeden Fall nicht. Da ist a < b für Pointer nicht zwingend
definiert, außer falls a und b aus dem selben Objekt stammen. Ansonsten
kannst du nur != und == verwenden.
Wenn du einen Pointer nach (void *) und wieder zurückcastest, muss
wieder der ursprüngliche Pointer herauskommen. Aber Achtung: Das geht
nur mit Zeigern auf unvollständige oder Objekt-Typen (z.B. also nicht
mit Funktionszeigern).
Holger Rasch
[...]
>> AFAIK garantiert der Standard nur, dass char * und void * die gleiche
>> Repräsentation haben. Z.B. muss ein int * nicht kompatibel zu einem
>> long * sein.
>
>Wirklich? Jeder Pointertyp ist nach (void *) castbar. Ein solcher
>cast muss AFAIK bijektiv sein, denn die Invariante
Noe, injektiv. [6.2.5.26] sagt:
A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type. Similarly, pointers to
qualified versions of compatible types shall have the same representation
and alignment requirements. All pointers to structure types shall have
the same representation and alignment requirements as each other. All
pointers to union types shall have the same representation and alignment
requirements as each other. Pointers to other types need not have the
same representation or alignment requirements.
Holger
Lukas Mai
> Thus spake Lukas Mai (lu...@saintmail.net):
> > Ich schätze aber mal, das void * hier genausogut funktionieren
> > würde. Alle andere Pointertypen müssen nicht kompatibel sein.
>
> Nicht schätzen. Standard lesen.
Hilft nicht unbedingt. Der Standard ist lang, englisch und selbst
Muttersprachler haben manchmal Verständnisprobleme ;-)
Kannst du mir sagen, ob ich hier (void *) verwenden dürfte?
> 0 ist ein völlig legaler Zeiger und er ist der NULL Zeiger, auch wenn
> dieser im Speicher anders aussieht als der Integer 0.
0 wird im Pointer-Kontext zum Null-Zeiger. In der Argumentliste einer
variadischen Funktion gibt es aber keinen Pointer-Kontext. Also wäre
printf("NULL ist %p\n", 0);
falsch.
> Es gibt übrigens auch eine FAQ zu C. Wenn man die vor dem Posten
> liest, macht man sich deutlich weniger zum Deppen.
Mag sein. Huch, Question 5.2 benutzt ja genau das execl()-Beispiel!
Aber es benutzt (char *)0.
Florian Zschocke
>
> Wo gibts den, ohne ihn bezahlen zu müssen? Hab schon genügend für "The
> C++ Programming Language" ausgegeben, und der Standard vom ANSI ist
> nicht gerade billig.
US$ 18, nicht gerade billig? Billiger als fast jedes Fachbuch,
wuerde ich sagen.
http://www.ncits.org/cplusplus.htm
Hmm, wenn ich im ANSI Online Store kucke, kostet er allerdings
inzwischen US$ 245. Aua!
http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A1998
Den '96er Draft zum Standard kannst Du Dir hier ziehen:
http://www.fz-juelich.de/zam/cxx/
Aber der Stroustrup ist doch gar kein schlechter Anfang. Vierte
Auflage, deutsche Ausgabe:
S.96, 5.1.1: "In C war es populaer, ein Makro NULL zu definieren,
um den Nullzeiger zu repraesentieren. Durch die engere Typpruefung
von C++ fuehrt die Benutzung der einfachen 0 anstelle des
NULL-Makros zu weniger Problemen."
Aber S.165,7.6(Unspezifitierte Anzahl an Argumenten): "Wenn ein
Argument nicht deklariert wurde, hat der Compiler natuerlich auch
nicht die noetige Information, um die Standardtyppruefung und
-typkonvertierung durchzufuehren. [Beispiel einer Ellipsis] Man
beachte, dass die Benutzung der Zahl 0 als Endekennzeichen nicht
portabel gewesen waere; bei einigen Implementierungen haben die
Zahl 0 und der Nullzeiger nicht dieselbe Repraesentation."
"Nicht portabel" wuerde ich ja nicht als "definitv falsch"
uebersetzen, aber mit const char* Null_cp = 0; faehrt man wohl
eindeutig besser.
Gruss,
Florian.
Rudolf Polzer
> Rudolf Polzer wrote:
> >
> > Wo gibts den, ohne ihn bezahlen zu müssen? Hab schon genügend für "The
> > C++ Programming Language" ausgegeben, und der Standard vom ANSI ist
> > nicht gerade billig.
>
> US$ 18, nicht gerade billig? Billiger als fast jedes Fachbuch,
> wuerde ich sagen.
>
> http://www.ncits.org/cplusplus.htm
Sowas muss man erst mal wissen...
> Hmm, wenn ich im ANSI Online Store kucke, kostet er allerdings
> inzwischen US$ 245. Aua!
>
> http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A1998
Genau da war ich.
> Den '96er Draft zum Standard kannst Du Dir hier ziehen:
>
> http://www.fz-juelich.de/zam/cxx/
Wieviel hat sich da geändert?
> Aber der Stroustrup ist doch gar kein schlechter Anfang. Vierte
> Auflage, deutsche Ausgabe:
[...]
> Aber S.165,7.6(Unspezifitierte Anzahl an Argumenten): "Wenn ein
> Argument nicht deklariert wurde, hat der Compiler natuerlich auch
> nicht die noetige Information, um die Standardtyppruefung und
> -typkonvertierung durchzufuehren. [Beispiel einer Ellipsis] Man
> beachte, dass die Benutzung der Zahl 0 als Endekennzeichen nicht
> portabel gewesen waere; bei einigen Implementierungen haben die
> Zahl 0 und der Nullzeiger nicht dieselbe Repraesentation."
>
> "Nicht portabel" wuerde ich ja nicht als "definitv falsch"
> uebersetzen, aber mit const char* Null_cp = 0; faehrt man wohl
> eindeutig besser.
Warum ein char *? Ein void * wäre hier IMHO deutlich sinnvoller,
da dann eventuelle Fehler vermieden werden können. Also ganz
einfach (void*)0...
--
#!/usr/bin/perl -- Exercise: prove _or_ disprove that _all_ digits
############################ displayed are 1! s/^/4711081542426/g;
use strict;$|=@_=$0=2;for(;;){do{++$0}while('@'x$0)=~/^(..+)\1+$/;
push@_,$0;for((2-@_)..0){$_[-$_]=abs($_[-$_]-$_[1-$_])}print$_[0]}
Rudolf Polzer
> "Nicht portabel" wuerde ich ja nicht als "definitv falsch"
> uebersetzen
Ich schon.
--
#!/usr/bin/perl -- Forget the express prospect!#Which was the original text?
use LWP'Simple;use URI'Escape;print"e> ";<STDIN>=~/(.*)/;for(en_de=>'de_en')
{get("http://babelfish.altavista.com/tr?doit=done&tt=urltext&lp=$_&urltext="
.uri_escape$1)=~/(?:d bgcolor=white|q")>(.*?)</s;print"$1 - (c)babelfish\n"}
Florian Zschocke
>
> Wieviel hat sich da geändert?
k.A.
> Warum ein char *? Ein void * wäre hier IMHO deutlich sinnvoller,
> da dann eventuelle Fehler vermieden werden können. Also ganz
> einfach (void*)0...
Der char* war jetzt aus dem Beispiel im Stroustrup, um im Kontext
zu bleiben. Ich persoenlich wuerde wohl void* ebenfalls vorziehen.
Gruss,
Florian.