[Geany-Devel] Spawn module API

[Dimitar Zhekov]

On 27.6.2015 г. 04:40, Lex Trotman wrote:

> My concern is that, for a given platform, all commands a user enters
> into Geany or plugins should use the same meta chars and quoting.
> [...]

Well, after we could not agree on universal syntax, the next best thing 
would be to at least have consistent syntax on each platform.

> Many plugins currently do their own command parsing to get an argv and
> others use g_spawn_command (which is hard wired to unix rules, it uses
> g_shell_parse_argv).  On windows these plugins will now use different
> rules to the build commands because the build commands use spawn_* and
> get platform dependent rules.

They will, though not that different. Most important when specifying a 
windows command with the *nix rules is you need to use either \\ or / as 
directory separator. Both will work, Win~1 supports that.

> These plugins should be encouraged to switch to the same rules as
> Geany, ie to use spawn_* calls with a cmd not an argv.  That means the
> appropriate spawn_* API should be available.

As of me, they should be encouraged to use the native Windows rules for 
the benefit of the users. Unless we design Geany for *nix users which 
run Win~1 from time to time. :)

(I assume be "cmd" you mean "command line", not cmd.exe).

> The API we need to expose for this is the API that allows an unparsed
> command to be used, not versions that only allow argv.

All spawn calls support both a CL and an argv. If both are passed, argv 
is appended to CL.

> So the spawn API that is a drop in replacement for g_spawn is only
> needed where g_spawn doesn't work, and then it should only be used as
> a temporary workaround __until the plugins move to using the cmd
> version__.

Sometimes it's native to use argv (scope: <gdb-executable>, "--quiet", 
"--interpreter=mi2"). Having only CL would mean that one needs to create 
it from argv, and we currently have no platform independent mechanism 
for that (it's not hard to write one, but still).

> So to me that means:
>
> /* platform dependent checking */
>
> spawn_get_program_name

Do we actually have a use case for this one?..

> spawn_check_command
>
> /* platform dependent running */
>
> spawn_with_callbacks
> spawn_async
> spawn_sync
>
> /* associated support functions */
>
> spawn_kill_process

This one is "platform dependent killing".

> spawn_write_data

This one looks "platform independent", but it's actually very easy to 
create a stdin-write function that blocks under Windows...

> spawn_get_exit_status_callback

If you mean spawn_get_exit_status_cb, that only copies int status into 
gint *exit_status. You can check the status using the WIF* macros. With 
spawn.h included, the basic ones are defined on both *nix and Win~1.

--

Well, if spawn_sync and spawn_async remain public, for easier plugin 
migration, and the functions that Scope needs remain public, that means 
only spawn_get_program_name, spawn_async_with_pipes and 
spawn_get_exit_status_cb will be hidden.

Personally I'm for making spawn_async_with_pipes static until somebody 
requests it. It's powerful, but very hard to use properly.

And spawn_get_exit_status_cb should be static as well. That's just a 
one-liner, and somebody may confuse it with a function that processes 
the child exit status in some way.

--

An updated list of the API-s asked to remain public:

me	WIF*
lex	spawn_get_program_name
lex	spawn_check_command
me/lex	spawn_kill_process
	spawn_async_with_pipes
lex	spawn_async
me/lex	spawn_with_callbacks
me	spawn_write_data
lex?	spawn_get_exit_status_cb
lex	spawn_sync

--
E-gards: Jimmy