#943 quotes and build command


Hi there !

I have a problem with custom build command since i upgrade to 1.23 on Wind~.
I define my build command as :
command : "C:\Documents and Settings\xxx\Application Data\geany\tools\jsl-0.3.0\jsl.exe" -process "%d\%f" -conf jsl.default.conf
work path : "C:\Documents and Settings\xxx\Application Data\geany\tools\jsl-0.3.0\"

And now with 1.23 it produce an error (in french) :
"C:\Documents and Settings\xxx\Application Data\geany\tools\jsl-0.3.0\jsl.exe" -process "D:\pathToFile\file.js" -conf jsl.default.conf (dans le dossier : "C:\Documents and Settings\xxx\Application Data\geany\tools\jsl-0.3.0\")
'C:\Documents' n'est pas reconnu en tant que commande interne
ou externe, un programme ex cutable ou un fichier de commandes.

If i use single quote instead of double quote i have this message (in french) :
Syntaxe du nom de fichier, de r pertoire ou de volume incorrecte.

I seen in the mailing list there was some changes near the management of quotes in the build command, maybe there is an edge effect for a Wind~ environment.

There is also an error with accentuated character ("ex cutable" / "r pertoire"). maybe it was present on previous version i don't remember

Thanks for your reading and consideration

Duplicates of this bug: [#969], [#980], [#996]


Bugs: #969
Bugs: #980
Bugs: #996


<< < 1 2 3 4 5 > >> (Page 3 of 5)
  • Nick Treleaven

    Nick Treleaven - 2013-10-30

    Dimitar: Thanks for your work. I've just tried the patch, and unfortunately I get the same issue as with git master without SYNC_SPAWN defined. I.e. when I run Make Object, the errors are not shown in the message window. Also async spawn on Windows has the same issue as this bug report (quoted spaces are not preserved as one argument), so we will need some kind of fix to build.c similar to my PR even when using GLib async spawning.

  • Dimitar Zhekov

    Dimitar Zhekov - 2013-10-30

    The quoting problem is because Geany does g_strsplit(cmd_string, " ", 0) under win32, irrespective of whether SYNC_SPAWN is used. It's not a spawn problem, all spawn/exec family use argv[] in the first place. A possible solution would be replacing both g_strsplit() [win32] and "/bin/sh" "-c" ... assignments [*nix] in build_spawn_cmd() with g_shell_parse_argv(), as in tools.c:tools_execute_custom_command().

    I'll try Make Object tomorrow. Both FiF and tools returned errors in my tests, so it's interesting when/why build does not. When finished, I'll post an updated patch with g_shell_parse_argv() and Make Object fix if one is needed/possible/whatever.

  • Dimitar Zhekov

    Dimitar Zhekov - 2013-10-31

    OK, I tested build under win~1, and the results are not rosy.

    g_shell_parse_argv() works, but feels a bit awkward: ' also quotes, and \ is an escape character, so you need \\ or / for directory separator. The advantage is that we can pass double quotes to the command, which is impossible with the regular win~1 syntax AFAIK (grep text-with-" under cmd is a PITA). Of course, I can write a small utils_parse_argv() function which calls g_shell_parse_argv() under *nix and implements the win~1 parsing, no big deal. Comments?

    As of the missing Make Object error messages:

    make object ::= cc -o build.o build.c

    [blue] cc -o build.o build.c (in directory: C:\tmp\scp\geany-2013-06-11\src)
    [blue] Compilation failed.
    [light red] In file included from build.c:31:0:
    [light red] geany.h:28:21: fatal error: gtk/gtk.h: No such file or directory
    [dark red] compilation terminated.

    make object ::= make build.o

    [blue] make build.o (in directory: C:\tmp\scp\geany-2013-06-11\src)
    [black] cc -c -o build.o build.c
    [blue] Compilation failed.
    [dark red] make: *** [build.o] Error 1

    make build.o from cmd.exe CL:

    cc -c -o build.o build.c
    In file included from build.c:31:0:
    geany.h:28:21: fatal error: gtk/gtk.h: No such file or directory
    compilation terminated.
    make: *** [build.o] Error 1

    What we see here is that Geany properly captures the error messages from make, which appear after the gcc error messages. So it's not a matter of buggy client reading from stderr. The reason we don't receive the subprocess messages may be (a) the glib execution helper program, or (b) GNU make trying to be too smart, and running the commands with cmd/COMSPEC if needed (it even recognizes 4NT), or without cmd/COMSPEC if not needed, or with sh/SHELL if one exists. It's horribly broken and misses more often than hits. Or (c) we may need to specify G_SPAWN_LEAVE_DESCRIPTORS_OPEN - if that does'nt work, there will be no easy solution...

  • Dimitar Zhekov

    Dimitar Zhekov - 2013-11-01

    As expected, G_SPAWN_LEAVE_DESCRIPTORS_OPEN did nothing.
    The loss of stderr is does not depend on the program: when Geany start X, and it starts Y, the output of Y is lost, but cmd /c X >& output.txt captures all stdout/err from X and Y.

    Why glib uses a helper program to start programs under win~1 is described at http://lists-archives.com/gtk/02371-regarding-helper-process-in-glib-2-8-4.html

    The funny thins is that CreateProcess() supports working dir... Considering that some of our spawns need command line (tools, build), others argument vector (utils_spawn_[a]sync), and yet others both (grep), I plan to write something like:

    gboolean utils_start_async_with_pipes(
        const gchar *command_text,
        const gchar *working_directory,
        gchar **argv,
        gchar **envp,
        GPid *child_pid,
        gint *standard_input,
        gint *standard_output,
        gint *standard_error,
        GError **error

    where either command_text or argv may be NULL, and both may be non-null. The *nix implementation will call g_shell_parse_argv(command_text) and g_spawn_async_with_pipes(), under win~1 it'll create a full command line and call CreateProcess() directly (our win32.c contains some of the required code). If that works, I can write a proper win32_spawn with async support, and end the spawning saga for good.

    Last edit: Anonymous 2013-11-02
    • Lex Trotman

      Lex Trotman - 2013-11-02

      Do we need the argv option? IIRC all Geany uses start with a command string, so it would be better to have an operating system dependent breakup as part of the utils function if its needed, rather than encouraging Geany and plugin code to do incorrect hacks to break the command string up.

      PS I assume the gchars are pointers but that SF formatting ate the stars

  • Anonymous

    Anonymous - 2013-11-02

    Not sure if it helps, but there's also CommandLineToArgvW which IIUC is the win32 equivalent of g_shell_parse_argv.

  • Dimitar Zhekov

    Dimitar Zhekov - 2013-11-02

    Here is a low-level create_process_with_pipes() for win~1 with a read(std{out,err}) test. No write(stdin) test yet, but I don't expect any problems. A comment in execute.c explains why the err/out may appear mixed (shoudn't be a problem in Geany).

    @Lex: I think we need both arguments. For example, FiF has a "grep command", while the text to search is certainly a separate argument, which may contain quotes. I don't want the calling functions to format something (sometimes with bugs, as in the current build.c) just so that I reformat it later. And there's the matter of utils_spawn_[a]sync(), both of which are currently in use.

    What I failed to mention is that if both command and argv are present, both will be used, with command_text before argv, and the non-native argument will be converted.

    (Yes, SF ate the asterisks).

    @Matthew: Argv[A|W]ToCommandLine would have been helpful, but I don't know of any, and haven't seen such a call in the windows crtl-s. The test in execute.c does a crude conversion, but I'll need to inspect this more carefully.

    I'm not sure what high level function(s) will be best, for example a sync/async spawn with callbacks instead of out/err fd-s, but in any case I'll create a new module, execute.c or something, and put all spawn related code there (except the client calls, of course). Enough hunting in utils, build, win32 and who knows where else.

  • Dimitar Zhekov

    Dimitar Zhekov - 2013-11-03

    Here's an updated version of execute. I'll probably name the new module spawn.[ch], and all functions will have spawn_ prefix. BTW, redirecting one or two of the pipes, while leaving the other(s) intact, seems to be a problem under win~1 - it's either all or none, the documentation of GetStdHandle() suggests otherwise.

  • Dimitar Zhekov

    Dimitar Zhekov - 2013-11-23

    The attached archive contains:

    • spawn.[ch] - spawning functions and tests, not Geany-dependent
    • Makefile - to compile the spawning tests under *nix/win~1
    • emit.c - a useful program to spawn
    • spawn.rsp - as in "./spawn < spawn.rsp"
    • respawn.diff - patch for Makefile.am, wscript, build.c and tools.c

    Changes since 0.8 which was sent to the ML:

    • added spawn_with_capture() and a test for it
    • altered tools.c to use spawn_with_capture()
    • added spawn.c to wscript
    • fixed passing mixed NULL and non-NULL hStd* to win~1 programs (it's not good, despite what the win~1 documentation says or does not say)
    • killed build.c SYNC_SPAWN and simplified the functions a bit
    • build.c tests: build geany/plugins with waf under win~1 and with autotools under *nix etc.
    • added documentation to spawn.c about the module and the various win~1 spawning problems
  • Dimitar Zhekov

    Dimitar Zhekov - 2013-11-29

    Changes since 0.9:

    • restored build.c kill process functionality
    • using g_win32_error_messages instead of error codes
    • patch and a bugfix for search.c
    • small fixes in spawn.c
    • small patches for notebook.c and templates.c
    • redirected utils_spawn_* to spawn_ functions
    • finally, cleanup patches of win32.[ch]
    • new file geanyvc.diff with a small geanyvc patch

    Note that you can apply the respawn patches separately, like splitdiff -a respawn.diff and then patch Makefile.am and build.c only; win32.[ch] should always be patched last.

    There are more calls that require change, for example g_shell_parse_argv (and thus g_spawn_command_line_*) should never be used under Windows directly. But I'll stop the spawning rewrite until the current changes are applied, rejected, fixed, or left to rot, as it sometimes happens.

<< < 1 2 3 4 5 > >> (Page 3 of 5)

Log in to post a comment.