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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
