:: Re: [DNG] Systemd Shims
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Edward Bartolo
日付:  
To: dng, Steve Litt
題目: Re: [DNG] Systemd Shims
At the moment I am stuck trying to use sudo to run ifup from within my
frontend. This testing phase is important as I need to ascertain
myself that the class I am using can actually capture CLI output.

If anyone from Devuan knows of a Lazarus function that I can use to
capture the output of an external program running with root
privileges, it will be much of an impulse for my coding exercise.

I am using the TProcess class. The program runs sudo -s ifup wlan0
successfully but it is failing to capture the CLI output.

In the meantime I will continue debugging until I find a way of succeeding.

Edward.

On 18/08/2015, Edward Bartolo <edbarx@???> wrote:
> Lazarus frontend can now run external programs capturing their textual
> output. Hopefully, within a few days, the frontend will be Alpha. :)
>
> On 17/08/2015, Edward Bartolo <edbarx@???> wrote:
>> The Lazarus backend interface unit is as follows but still unfinished:
>>
>> ----------------------------------------
>> unit backend;
>>
>> {$mode objfpc}{$H+}
>>
>> interface
>>
>> uses
>> Classes, SysUtils, stdctrls;
>>
>> procedure Backend_Save(essid, pw: string);
>> procedure Backend_Save_Connect(essid, pw: string);
>> function Backend_Query_Connect(connection: string; var pw: string):
>> boolean;
>> function Backend_Delete_Connect(essid: string): boolean;
>> function Backend_Connection_Connect(essid: string): boolean;
>> function Backend_Disconnect_Active_Connection: boolean;
>> procedure Backend_Scan(aListBox: TListBox);
>> procedure Backend_Load_Existing(aListBox: TListBox);
>>
>> implementation
>>
>> const
>> opSave = 0;
>> opSaveConnect = 1;
>> opQueryConnect = 2;
>> opDeleteConnect = 3;
>> opConnectionConnect = 4;
>> opDisconnectActiveConnection = 5;
>> opScan = 6;
>> opLoadExisting = 7;
>>
>>
>> procedure Backend_Save(essid, pw: string);
>> begin
>> // backend opSave essid pw
>> end;
>>
>> procedure Backend_Save_Connect(essid, pw: string);
>> begin
>> // backend opSaveConnect essid pw
>> end;
>>
>> function Backend_Query_Connect(connection: string; var pw:string):
>> boolean;
>> begin
>> // backend opQueryConnect essid pw
>> end;
>>
>> function Backend_Delete_Connect(essid: string): boolean;
>> begin
>> // backend opDeleteConnect essid
>> result := true;
>> end;
>>
>> function Backend_Connection_Connect(essid: string): boolean;
>> begin
>> // backend opConnectionConnect essid
>> end;
>>
>> function Backend_Disconnect_Active_Connection: boolean;
>> begin
>> // backend opDisconnectActiveConnection
>> end;
>>
>> procedure Backend_Scan(aListBox: TListBox);
>> begin
>> // backend opScan stringlist
>> end;
>>
>> procedure Backend_Load_Existing(aListBox: TListBox);
>> begin
>> // backend opLoadExisting stringlist
>> end;
>>
>> end.
>> ---------------------------------------------
>>
>> On 17/08/2015, Edward Bartolo <edbarx@???> wrote:
>>> The Progress of My Coding Till Now:
>>>
>>> I am attaching two images of the GUI's main window and the only
>>> dialog. The GUI is programmed in Lazarus Pascal.
>>>
>>> The backend is in C. The code till now, although it doesn't do anything
>>> useful.
>>> ----------------------------------------------
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <string.h>
>>> #include <unistd.h>
>>>
>>>
>>> using namespace std;
>>>
>>>
>>> #define opSave                0
>>> #define opSaveConnect            1
>>> #define opQueryConnect            2
>>> #define opDeleteConnect            3
>>> #define opConnectionConnect        4
>>> #define opDisconnectActiveConnection    5
>>> #define opScan                6
>>> #define opLoadExisting            7

>>>     
>>> /*
>>> 1) Glib::spawn_sync instead of a pipe stream, provides a slot.
>>> 2) cmd trying to call an inexistent command still returns a valid
>>> pointer!
>>>    verify cmd exists before calling exec
>>> */

>>>
>>> inline bool file_exists(char* name) {
>>> return (access(name, F_OK) != -1);
>>> }
>>>
>>>
>>> int exec(const char* cmd, char* out)
>>> {
>>>     const int buf_size = 128;

>>>         
>>>     FILE * pipe = popen(cmd, "r");
>>>     char buffer[buf_size];
>>>     while(!feof(pipe)) {
>>>         if(fgets(buffer, buf_size, pipe) != NULL)
>>>         {
>>>             if (out != NULL)
>>>                 strcat(out, buffer);
>>>                 else strcpy(out, buffer);
>>>         }
>>>     }

>>>         
>>>     return pclose(pipe);
>>> }

>>>
>>> int main(int argc, char *argv[])
>>> {
>>>     char *out = 0;
>>>     int switch_item = -1;
>>>     if (argc > 1) switch_item = atoi(argv[1]);

>>>     
>>>     switch (switch_item) {
>>>         case opSave:
>>>             //saveFile(argv[2], argv[3]);
>>>             exec("cat /etc/network/interfaces", out);
>>>             //out[0] = ' ';
>>>             printf(out);

>>>         
>>>             return 0;

>>>             
>>>         case opSaveConnect:
>>>             //saveFile(argv[2], argv[3]);
>>>             //Connect(argv[2]);
>>>             return 0;

>>>             
>>>         case opQueryConnect:

>>>             
>>>             return 0;

>>>             
>>>         case opDeleteConnect:

>>>         
>>>             break;

>>>             
>>>         case opConnectionConnect:

>>>             
>>>             break;

>>>             
>>>         case opDisconnectActiveConnection:

>>>         
>>>             break;

>>>             
>>>         case opScan:

>>>             
>>>             break;

>>>             
>>>         case opLoadExisting:

>>>         
>>>             return 0;
>>>     }

>>>     
>>>     return -1; // parameter not in range
>>> }
>>> ----------------------------------------------------------------

>>>
>>>
>>> On 17/08/2015, Rainer Weikusat <rainerweikusat@???> wrote:
>>>> James Powell <james4591@???> writes:
>>>>> While there are packages that can be invisible and unintrusive into
>>>>> the system, there are some that cannot.
>>>>>
>>>>> The problem is responsibility.
>>>>>
>>>>> Who wants to remain responsible for boot scripts? Upstream or vendor?
>>>>>
>>>>> Who wants responsibility for providing interoperability between
>>>>> projects? Upstream or downstream bazaar?
>>>>>
>>>>> Who wants responsibility for the userland? Upstream or the downstream
>>>>> bazaar?
>>>>
>>>> It's possible to frame this in more technical terms: Who'll end up
>>>> doing
>>>> system integration, system integrators or application developers? The
>>>> answer should (hopefully) be obvious.
>>>> _______________________________________________
>>>> Dng mailing list
>>>> Dng@???
>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>>>
>>>
>>
>