The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
Function proposal: SDL_Execute
Sik


Joined: 26 Nov 2011
Posts: 905
Here's a suggestion for a new SDL function: SDL_Execute(). It
basically just behaves like the standard library system() function,
the idea of this function is to help work around differences that may
exist between platforms.

The syntax would be (the string is UTF-8, as usual):
int SDL_Execute(const char *str)

Depending on the platform, this is what happens:

- On platforms where you aren't allowed to run other programs, this
function just returns -1 (like it had failed to execute the command).
This would also be the dummy implementation.

- On Windows, this function converts the string to UTF-16 and calls
_wsystem(), and then returns whatever value that function returns.

- Everywhere else it just calls system() directly (I think all other
systems just use UTF-8 so this should work, if I'm wrong then
conversion would happen as with the Windows case).

So yeah, that's pretty much it. Really mainly meant for PC since on
mobile it's kind of pointless (as it can't be used there). Anyway,
what do you think? (proposing this as I'm finding myself calling some
external programs for some functions not present in SDL2 such as
screen reader output)
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Function proposal: SDL_Execute
Melker Narikka
Guest

That could be useful.


I'd much rather have an exec(3) -style function, something like SDL_ExecVP()and/or SDL_ExecVP(). (With system() -like semantics when it comes to actual
process management.) Escaping arguments for a system() call is somewhat
terrifying, as someone would probably inevitably try to do so anyway.


A flag to have it go into the background and forget about it *might* be useful,
but then again you could very well in such a case just call it from another thread.


--
Melker Narikka







On Tue, Nov 11, 2014 at 8:21 PM, Sik the hedgehog wrote:
Quote:
Here's a suggestion for a new SDL function: SDL_Execute(). It
basically just behaves like the standard library system() function,
the idea of this function is to help work around differences that may
exist between platforms.

The syntax would be (the string is UTF-8, as usual):
int SDL_Execute(const char *str)

Depending on the platform, this is what happens:

- On platforms where you aren't allowed to run other programs, this
function just returns -1 (like it had failed to execute the command).
This would also be the dummy implementation.

- On Windows, this function converts the string to UTF-16 and calls
_wsystem(), and then returns whatever value that function returns.

- Everywhere else it just calls system() directly (I think all other
systems just use UTF-8 so this should work, if I'm wrong then
conversion would happen as with the Windows case).

So yeah, that's pretty much it. Really mainly meant for PC since on
mobile it's kind of pointless (as it can't be used there). Anyway,
what do you think? (proposing this as I'm finding myself calling some
external programs for some functions not present in SDL2 such as
screen reader output)
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Function proposal: SDL_Execute
Sik


Joined: 26 Nov 2011
Posts: 905
2014-11-11 16:35 GMT-03:00, Melker Narikka:
Quote:
I'd much rather have an exec(3) -style function, something like
SDL_ExecVP()
and/or SDL_ExecVP(). (With system() -like semantics when it comes to actual
process management.) Escaping arguments for a system() call is somewhat
terrifying, as someone would probably inevitably try to do so anyway.

Ugh right, and in fact that's the very thing I'm doing x_x OK, adapt
it for that then. The important thing is that the functionality is
there.

Quote:
A flag to have it go into the background and forget about it *might* be
useful,
but then again you could very well in such a case just call it from another
thread.

Well, it could still be worth having to make things simpler to program
(it's easier to just do the call than to spawn a thread with a
callback that calls the function).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Function proposal: SDL_Execute
Andreas Schiffler
Guest

There was work done on something like this for the GSoC visualtest
project, since the visual test harness needed to launch an SDL
application as independent process (i.e. to be able to capture
screenshots of a windowed SDL app).

An actual implementation of this was just done for Windows (source is
here: SDL/visualtest/src/windows) since the project ran out of time
while extending it to Unix, but the API had a well thought-out interface
which includes some important functionality (checking if a process is
running, killing a process) and encapsulating platform specific details
in structs.

I'd suggest to consider something like this:
int SDL_LaunchProcess(char* file, char* args, SDL_ProcessInfo* pinfo)
int SDL_GetProcessExitStatus(SDL_ProcessInfo* pinfo,
SDL_ProcessExitStatus* ps)
int SDL_IsProcessRunning(SDL_ProcessInfo* pinfo)
int SDL_QuitProcess(SDL_ProcessInfo* pinfo, SDL_ProcessExitStatus* ps)
int SDL_KillProcess(SDL_ProcessInfo* pinfo, SDL_ProcessExitStatus* ps)

--Andreas

On 11/11/2014 10:21 AM, Sik the hedgehog wrote:
Quote:
Here's a suggestion for a new SDL function: SDL_Execute(). It
basically just behaves like the standard library system() function,
the idea of this function is to help work around differences that may
exist between platforms.

The syntax would be (the string is UTF-8, as usual):
int SDL_Execute(const char *str)

Depending on the platform, this is what happens:

- On platforms where you aren't allowed to run other programs, this
function just returns -1 (like it had failed to execute the command).
This would also be the dummy implementation.

- On Windows, this function converts the string to UTF-16 and calls
_wsystem(), and then returns whatever value that function returns.

- Everywhere else it just calls system() directly (I think all other
systems just use UTF-8 so this should work, if I'm wrong then
conversion would happen as with the Windows case).

So yeah, that's pretty much it. Really mainly meant for PC since on
mobile it's kind of pointless (as it can't be used there). Anyway,
what do you think? (proposing this as I'm finding myself calling some
external programs for some functions not present in SDL2 such as
screen reader output)
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Function proposal: SDL_Execute
Sik


Joined: 26 Nov 2011
Posts: 905
2014-11-12 0:46 GMT-03:00, Andreas Schiffler:
Quote:
int SDL_LaunchProcess(char* file, char* args, SDL_ProcessInfo* pinfo)

I'm not sure you'd want to pass args as a single string, due to what
was mentioned earlier about escaping.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Function proposal: SDL_Execute
Andreas Schiffler
Guest

Yup, agreed. Should probably be char *argv[] - it is probably still good
to separate our the executable from the arguments.

On 11/11/2014 8:21 PM, Sik the hedgehog wrote:
Quote:
2014-11-12 0:46 GMT-03:00, Andreas Schiffler:
Quote:
int SDL_LaunchProcess(char* file, char* args, SDL_ProcessInfo* pinfo)
I'm not sure you'd want to pass args as a single string, due to what
was mentioned earlier about escaping.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Function proposal: SDL_Execute
Jared Maddox
Guest

Quote:
Date: Tue, 11 Nov 2014 21:35:50 +0200
From: Melker Narikka
To: SDL Development List
Subject: Re: [SDL] Function proposal: SDL_Execute
Message-ID:

Content-Type: text/plain; charset="utf-8"

That could be useful.

I'd much rather have an exec(3) -style function, something like SDL_ExecVP()
and/or SDL_ExecVP(). (With system() -like semantics when it comes to actual
process management.) Escaping arguments for a system() call is somewhat
terrifying, as someone would probably inevitably try to do so anyway.

A flag to have it go into the background and forget about it *might* be
useful,
but then again you could very well in such a case just call it from another
thread.


A flag to have it REPLACE the current thread/process would probably be
worthwhile as well, since the caller might just be some sort of loader
(or might be making the call to run an updater program: on Windows you
can't overwrite an executable that's running, so actual program
updates require this sort of dance).


Quote:
Date: Tue, 11 Nov 2014 17:20:29 -0300
From: Sik the hedgehog
To: SDL Development List
Subject: Re: [SDL] Function proposal: SDL_Execute
Message-ID:
<CAEyBR+W_HQn5uL=
Content-Type: text/plain; charset=UTF-8

2014-11-11 16:35 GMT-03:00, Melker Narikka:
Quote:
I'd much rather have an exec(3) -style function, something like
SDL_ExecVP()
and/or SDL_ExecVP(). (With system() -like semantics when it comes to actual
process management.) Escaping arguments for a system() call is somewhat
terrifying, as someone would probably inevitably try to do so anyway.

Ugh right, and in fact that's the very thing I'm doing x_x OK, adapt
it for that then. The important thing is that the functionality is
there.


A different name than Exec might be wise as well, since every Exec
function that I've ever heard of REPLACES the current program.


Quote:
Date: Tue, 11 Nov 2014 19:46:14 -0800
From: Andreas Schiffler
To: SDL Development List
Subject: Re: [SDL] Function proposal: SDL_Execute
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

There was work done on something like this for the GSoC visualtest
project, since the visual test harness needed to launch an SDL
application as independent process (i.e. to be able to capture
screenshots of a windowed SDL app).

An actual implementation of this was just done for Windows (source is
here: SDL/visualtest/src/windows) since the project ran out of time
while extending it to Unix, but the API had a well thought-out interface
which includes some important functionality (checking if a process is
running, killing a process) and encapsulating platform specific details
in structs.

I'd suggest to consider something like this:
int SDL_LaunchProcess(char* file, char* args, SDL_ProcessInfo* pinfo)
int SDL_GetProcessExitStatus(SDL_ProcessInfo* pinfo,
SDL_ProcessExitStatus* ps)
int SDL_IsProcessRunning(SDL_ProcessInfo* pinfo)
int SDL_QuitProcess(SDL_ProcessInfo* pinfo, SDL_ProcessExitStatus* ps)
int SDL_KillProcess(SDL_ProcessInfo* pinfo, SDL_ProcessExitStatus* ps)


This ALMOST sounds like a SDL pipes implementation that I did. I
haven't touched it in a while (never had anything ready for it, so
never tried to compile it either), but I'll attach the code that I
have convenient.


Quote:
Date: Wed, 12 Nov 2014 01:21:30 -0300
From: Sik the hedgehog
To: SDL Development List
Subject: Re: [SDL] Function proposal: SDL_Execute
Message-ID:
<CAEyBR+W_CVrJks2MuDkEWyxeEep=
Content-Type: text/plain; charset=UTF-8

2014-11-12 0:46 GMT-03:00, Andreas Schiffler:
Quote:
int SDL_LaunchProcess(char* file, char* args, SDL_ProcessInfo* pinfo)

I'm not sure you'd want to pass args as a single string, due to what
was mentioned earlier about escaping.



So:
int SDL_LaunchProcess
(
char *file,
int argn, char **args,
SDL_ProcessInfo *pinfo
);

Or:
int SDL_LaunchProcess
(
char *file,
char **args,
SDL_ProcessInfo *pinfo
);
With the requirement that a null pointer be the last entry in the argument list?

I personally prefer the variant with the length argument, since I
think it's less likely to get misunderstood.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org