Hi guys,
You probably saw the mail from Jan Lieskovsky about the "security issue" of not escaping filenames and other placeholders in the build commands. Although I don't really think it's important from the security POV, I think it would be great to fix it for users not to get weird errors if their files actually contain some weird characters (even only spaces if their build command misses quoting around the placeholder).
So, how to fix it?
What comes to mind immediately is to escape the placeholder replacements. It would work, but we need to take a little more care than that, because the build command may or may not already have the placeholder quoted (like gcc -c "%f" -o %e.o).
The other solution I thought about was not to build another string but directly an `argv` vector, but it's not really doable I think because we want to be able to replace placeholders not only in argv but also in directory paths & friends. And actually it doesn't really fix anything since we don't want a placeholder to correspond to a whole argument anyway (like int %e.o).
So, I wrote a not-that-trivial replacement of `build_replace_placeholder()` (patch attached) that takes care of the replacement quoting (using `g_shell_quote()`) and quotes in the input.
Apart some more testing, I had some doubts about Windows compatibility here. Will the windows spawn code deal correctly with the escapes? If not, how to escape for Windows too?
Voila, so could you test, and what do you think?
Cheers, Colomban
PS: my patch also fixes replacing of a placeholder in an previous replacement, e.g. if the replacement for %f contains the literal %e it won't be replaced.
On Fri, 14 Dec 2012 17:53:06 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
Apart some more testing, I had some doubts about Windows compatibility here. Will the windows spawn code deal correctly with the escapes? If not, how to escape for Windows too?
Win~1 filenames can not contain " \ ? * and some other characters. Whether filenames with spaces are automatically quoted when creating a win~1 command line depends on the exec/spawn function used; the actual CreateProcess() uses a string, not char **.
As of the win~1 escaping, here is a small program I wrote 10(?) years ago, which takes **argv, quotes them and creates a string, so that if a system() call is executed, the program started receives the same args.
The WIN32 shell re-quoting looks pretty simple, but I can't remember why isn't \ escaped too, or whether a fully correct re-quoting is possible for win~1 cmd. Hope that helps...
On 15 December 2012 03:53, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi guys,
You probably saw the mail from Jan Lieskovsky about the "security issue" of not escaping filenames and other placeholders in the build commands.
Hi Colomban,
No, a reference would be useful ;).
Although I don't really think it's important from the security POV, I think it would be great to fix it for users not to get weird errors if their files actually contain some weird characters (even only spaces if their build command misses quoting around the placeholder).
I don't think Geany should be interpreting what a user meant by their command, there are too many edge cases that don't conform to the "usual" gcc or other rules. That space may be meant to be there, Geany has no way of knowing. Also what if the command has globs in it, quoting them stops them working :(
So, how to fix it?
Don't, its not broke :)
What comes to mind immediately is to escape the placeholder
Do you mean escape or quote above, the rest of the sentence seems to suggest quoting not escaping.
replacements. It would work, but we need to take a little more care than that, because the build command may or may not already have the placeholder quoted (like gcc -c "%f" -o %e.o).
As I said above, you can't know what is meant, sure the "usual" case may be an error, but you can't tell.
The other solution I thought about was not to build another string but directly an `argv` vector, but it's not really doable I think because we want to be able to replace placeholders not only in argv but also in directory paths & friends. And actually it doesn't really fix anything since we don't want a placeholder to correspond to a whole argument anyway (like int %e.o).
So, I wrote a not-that-trivial replacement of `build_replace_placeholder()` (patch attached) that takes care of the replacement quoting (using `g_shell_quote()`) and quotes in the input.
I am not in a situation where I can try, and reading it doesn't make sense?? Can you explain what you are trying to do.
Apart some more testing, I had some doubts about Windows compatibility here. Will the windows spawn code deal correctly with the escapes? If not, how to escape for Windows too?
Voila, so could you test, and what do you think?
I suspect it will break anything but the "usual" commands, and thats bad :(
Cheers Lex
Cheers, Colomban
PS: my patch also fixes replacing of a placeholder in an previous replacement, e.g. if the replacement for %f contains the literal %e it won't be replaced.
How do you know its a literal? Ok, in this case it "probably" is, but still ...
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 12-12-14 08:34 PM, Lex Trotman wrote:
On 15 December 2012 03:53, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi guys,
You probably saw the mail from Jan Lieskovsky about the "security issue" of not escaping filenames and other placeholders in the build commands.
Hi Colomban,
No, a reference would be useful ;).
It was sent directly to Geany developers, regarding: https://bugs.gentoo.org/show_bug.cgi?id=446986
Although I don't really think it's important from the security POV, I think it would be great to fix it for users not to get weird errors if their files actually contain some weird characters (even only spaces if their build command misses quoting around the placeholder).
I don't think Geany should be interpreting what a user meant by their command, there are too many edge cases that don't conform to the "usual" gcc or other rules. That space may be meant to be there, Geany has no way of knowing. Also what if the command has globs in it, quoting them stops them working :(
I think the idea is to just escape the filenames being replaced into %f et al placeholders, not the whole command en masse. IIRC, the only thing placed into the placeholders is filenames/paths, which should be able to be safely escaped/sanitized without messing up the whole command.
So, how to fix it?
Don't, its not broke :)
The concern as raised in the bug report('s link) above is that one could (somehow) inject malicious code in the command.
FWIW, the general consensus seemed to be that while bad things could happen, from a security perspective, it's no worse than using `make` or GCC or whatever directly with malicious filenames/misquoting. The fact that the user has to enter the command manually (or have $HOME hacked) and also explicitly initiate the command with a maliciously-named file open pretty much negates the _security_ concerns.
[...] So, I wrote a not-that-trivial replacement of `build_replace_placeholder()` (patch attached) that takes care of the it's no worse than using `make` or GCC or whatever directly with malicious filenames. T replacement quoting (using `g_shell_quote()`) and quotes in the input.
I am not in a situation where I can try, and reading it doesn't make sense?? Can you explain what you are trying to do.
IIUC, the idea is to avoid replacing something like this:
gcc -c "%f"
With the following:
gcc -c "foo.c"; rm -rf /; cat /etc/passwd"
Where the %f placeholder gets replaced with the document's maliciously-named file ('foo.c"; rm -rf /; cat "/etc/passwd') without being escaped/sanitized.
Disclaimer: I haven't state my own opinion in this email and so shouldn't be disagreed or argued with about the validity of the concerns that were raised by others, just sharing the details FYI :)
Cheers, Matthew Brush
Le 15/12/2012 06:58, Matthew Brush a écrit :
On 12-12-14 08:34 PM, Lex Trotman wrote:
On 15 December 2012 03:53, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi guys,
You probably saw the mail from Jan Lieskovsky about the "security issue" of not escaping filenames and other placeholders in the build commands.
Hi Colomban,
No, a reference would be useful ;).
It was sent directly to Geany developers, regarding: https://bugs.gentoo.org/show_bug.cgi?id=446986
Thanks Matthew. And sorry Lex, I didn't think you might not have got it.
Although I don't really think it's important from the security POV, I think it would be great to fix it for users not to get weird errors if their files actually contain some weird characters (even only spaces if their build command misses quoting around the placeholder).
I don't think Geany should be interpreting what a user meant by their command, there are too many edge cases that don't conform to the "usual" gcc or other rules. That space may be meant to be there, Geany has no way of knowing. Also what if the command has globs in it, quoting them stops them working :(
Calm down Lex, I'm not trying to break your whole Geany. Breathe. Inspire; Expire. Ok ;)
I think the idea is to just escape the filenames being replaced into %f et al placeholders, not the whole command en masse. IIRC, the only thing placed into the placeholders is filenames/paths, which should be able to be safely escaped/sanitized without messing up the whole command.
That's it. Another example like Matthew's one: what I want to do is only to make sure that e.g. "%f" is never replaced by something that will be interpreted as a command. Those placeholders (%f, %d, %e and %p) represent filenames or paths and never user-typed commands, so they should never be interpreted as a command.
For example, the simple command:
gcc "%f" -c -o "%e.o"
Given the current file named:
holy "crap.c
would currently expand to:
gcc "holy "crap.c" -c -o "holy "crap.o"
Which, huh, doesn't mean what you want at all! The commands will be understood as:
argv[0] = gcc argv[1] = holy crap.c -c -o holy argv[2] = crap.o
(if my shell unquoting skills are correct ;))
What the user actually expected was:
argv[0] = gcc argv[1] = holy "crap.c argv[2] = -c argv[3] = -o argv[4] = holy "crap.o
Obviously, it's not the same :(
So again, what I want is to make sure the placeholders (%f & co.) are properly escaped/quoted/whatever so they never get misinterpreted like above. And as I said, to actually achieve this we have to somewhat understand the quoting in the user command because we can't escape the same inside or outside shell quotes -- e.g. %f (without quotes) cannot be escaped the same way as "%f" (with the quotes).
But still nothing really clever trying to understand a meaning, just knowing the basics like '' and "" are quotes, and \ is an escape so we can know how to escape. Actually the implementation I proposed simply closes any open quote before replacing a quoted placeholder, and then re-opens it.
I.e. for the above example, it would replace as:
gcc ""'holy "crap.c'"" -c -o ""'holy "crap.o'""
That's a bit ugly but you don't have to see it, and it's perfectly safe. Also, just to make sure you see what I mean, if the user command didn't quote the %f and %e, and the filename simply contained a space:
command: gcc %f -c -o %e.o filename: file name.c current replacement: gcc file name.c -c -o file name.o fixed replacement: gcc 'file name.c' -c -o 'file name'.o
You see? :)
So, how to fix it?
Don't, its not broke :)
Yes it is, although it's not really annoying because commands have quotes around placeholders and filenames generally don't include " literals. But try compiling a file whose name contains a " literal and you'll see it's broken ;)
Hope it's clearer now :)
Cheers, Colomban
[...]
I don't think Geany should be interpreting what a user meant by their command, there are too many edge cases that don't conform to the "usual" gcc or other rules. That space may be meant to be there, Geany has no way of knowing. Also what if the command has globs in it, quoting them stops them working :(
Calm down Lex, I'm not trying to break your whole Geany. Breathe. Inspire; Expire. Ok ;)
Hi Colomban,
Hehe, sorry, this email arrived just after another project just did something similar to "sanitise" inputs and broke my setup, making me very cranky, so I didn't want to have it happen to Geany :)
I agree that the security risk exists, but then it needs a peculiar filename, the only way to fix that would be to ban any shell metacharacters in filenames, but some users won't like that.
As for spaces in filenames, see below.
I think the idea is to just escape the filenames being replaced into %f et al placeholders, not the whole command en masse. IIRC, the only thing placed into the placeholders is filenames/paths, which should be able to be safely escaped/sanitized without messing up the whole command.
That's it. Another example like Matthew's one: what I want to do is only to make sure that e.g. "%f" is never replaced by something that will be interpreted as a command. Those placeholders (%f, %d, %e and %p) represent filenames or paths and never user-typed commands, so they should never be interpreted as a command.
For example, the simple command:
gcc "%f" -c -o "%e.o"Given the current file named:
holy "crap.cwould currently expand to:
gcc "holy "crap.c" -c -o "holy "crap.o"Which, huh, doesn't mean what you want at all! The commands will be understood as:
argv[0] = gcc argv[1] = holy crap.c -c -o holy argv[2] = crap.o
(if my shell unquoting skills are correct ;))
Understand, I think thats right.
What the user actually expected was:
argv[0] = gcc argv[1] = holy "crap.c argv[2] = -c argv[3] = -o argv[4] = holy "crap.o
Obviously, it's not the same :(
Thats obviously whats expected, and yes its not the same. Although inconvenient the above erroneous input would of course just give an error, "holy crap.c -c -o holy" not found. Well unless it is found :)
So again, what I want is to make sure the placeholders (%f & co.) are properly escaped/quoted/whatever so they never get misinterpreted like above. And as I said, to actually achieve this we have to somewhat understand the quoting in the user command because we can't escape the same inside or outside shell quotes -- e.g. %f (without quotes) cannot be escaped the same way as "%f" (with the quotes).
or %e.* for example?
But still nothing really clever trying to understand a meaning, just knowing the basics like '' and "" are quotes, and \ is an escape so we can know how to escape. Actually the implementation I proposed simply closes any open quote before replacing a quoted placeholder, and then re-opens it.
I.e. for the above example, it would replace as:
gcc ""'holy "crap.c'"" -c -o ""'holy "crap.o'""That's a bit ugly but you don't have to see it, and it's perfectly safe. Also, just to make sure you see what I mean, if the user command didn't quote the %f and %e, and the filename simply contained a space:
command: gcc %f -c -o %e.o filename: file name.c current replacement: gcc file name.c -c -o file name.o fixed replacement: gcc 'file name.c' -c -o 'file name'.o
You see? :)
Yeah, thats a normal command, but continuing my example from above, what do you get if I have
cmd %e.*
because if lets say the filename is xxx.c, if you get
cmd "xxx.*"
then the * won't be treated as a glob since its quoted, so my command won't work. It needs to be
cmd "xxx."*
So is g_shell_quote smart enough for all possibilities of shell metacharacters? Including the full range of shell patterns, and backquote command substitution and etc. Then again what if the filename has a literal * in it, how does g_shell_quote know its literal or if we meant a glob?
So, how to fix it?
Don't, its not broke :)
Yes it is, although it's not really annoying because commands have quotes around placeholders and filenames generally don't include " literals. But try compiling a file whose name contains a " literal and you'll see it's broken ;)
Heh, ok, but so is using a " literal in a filename in that case :)
Hope it's clearer now :)
Clearer that its probably wrong, and needs mindreading to be right, see example above :)
Cheers Lex
Cheers, Colomban _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Le 16/12/2012 00:00, Lex Trotman a écrit :
[...]
I don't think Geany should be interpreting what a user meant by their command, there are too many edge cases that don't conform to the "usual" gcc or other rules. That space may be meant to be there, Geany has no way of knowing. Also what if the command has globs in it, quoting them stops them working :(
Calm down Lex, I'm not trying to break your whole Geany. Breathe. Inspire; Expire. Ok ;)
Hi Colomban,
Hehe, sorry, this email arrived just after another project just did something similar to "sanitise" inputs and broke my setup, making me very cranky, so I didn't want to have it happen to Geany :)
Oh, ok, but we have you to make sure we don't brake anything, you're Geany's regression test suite by yourself ;)
I agree that the security risk exists, but then it needs a peculiar filename, the only way to fix that would be to ban any shell metacharacters in filenames, but some users won't like that.
No, the solution is to escape or quote the replacements, so that any shell metacharacter in them wouldn't be interpreted by the shell.
As for spaces in filenames, see below.
I think the idea is to just escape the filenames being replaced into %f et al placeholders, not the whole command en masse. IIRC, the only thing placed into the placeholders is filenames/paths, which should be able to be safely escaped/sanitized without messing up the whole command.
That's it. Another example like Matthew's one: what I want to do is only to make sure that e.g. "%f" is never replaced by something that will be interpreted as a command. Those placeholders (%f, %d, %e and %p) represent filenames or paths and never user-typed commands, so they should never be interpreted as a command.
For example, the simple command:
gcc "%f" -c -o "%e.o"Given the current file named:
holy "crap.cwould currently expand to:
gcc "holy "crap.c" -c -o "holy "crap.o"Which, huh, doesn't mean what you want at all! The commands will be understood as:
argv[0] = gcc argv[1] = holy crap.c -c -o holy argv[2] = crap.o
(if my shell unquoting skills are correct ;))
Understand, I think thats right.
What the user actually expected was:
argv[0] = gcc argv[1] = holy "crap.c argv[2] = -c argv[3] = -o argv[4] = holy "crap.o
Obviously, it's not the same :(
Thats obviously whats expected, and yes its not the same. Although inconvenient the above erroneous input would of course just give an error, "holy crap.c -c -o holy" not found. Well unless it is found :)
It would probably just throw a "file not found" error in this case, but who know what's the filename and as you pointed out yourself, who knows what was the actual command.
So again, what I want is to make sure the placeholders (%f & co.) are properly escaped/quoted/whatever so they never get misinterpreted like above. And as I said, to actually achieve this we have to somewhat understand the quoting in the user command because we can't escape the same inside or outside shell quotes -- e.g. %f (without quotes) cannot be escaped the same way as "%f" (with the quotes).
or %e.* for example?
No, it's the same as unquoted %e, since it's outside a quote.
But still nothing really clever trying to understand a meaning, just knowing the basics like '' and "" are quotes, and \ is an escape so we can know how to escape. Actually the implementation I proposed simply closes any open quote before replacing a quoted placeholder, and then re-opens it.
I.e. for the above example, it would replace as:
gcc ""'holy "crap.c'"" -c -o ""'holy "crap.o'""That's a bit ugly but you don't have to see it, and it's perfectly safe. Also, just to make sure you see what I mean, if the user command didn't quote the %f and %e, and the filename simply contained a space:
command: gcc %f -c -o %e.o filename: file name.c current replacement: gcc file name.c -c -o file name.o fixed replacement: gcc 'file name.c' -c -o 'file name'.o
You see? :)
Yeah, thats a normal command, but continuing my example from above, what do you get if I have
cmd %e.*
It would give:
cmd 'xxx'.*
because if lets say the filename is xxx.c, if you get
cmd "xxx.*"
then the * won't be treated as a glob since its quoted, so my command won't work. It needs to be
cmd "xxx."*
Nope, it needs to be
cmd 'xxx'.*
since we don't have to know what a . means, we just quote the placeholder replacement.
So is g_shell_quote smart enough for all possibilities of shell metacharacters? Including the full range of shell patterns, and backquote command substitution and etc. Then again what if the filename has a literal * in it, how does g_shell_quote know its literal or if we meant a glob?
`g_shell_quote()` escapes (or actually, quotes) the string we gives it, no matter what, we just don't pass it the user command. I think we have a misunderstanding here, so let's be clear and since we all are programmers, let's write code :) So here's a incredibly naive (and not correct enough, but see my real one for a less naive one) implementation in pseudo code:
def replace_placeholders(doc, cmd): f = os.path.basename(doc.filename) e = os.path.splitext(f)[0] d = os.path.dirname(doc.filename) p = app.project_path
cmd.replace('%f', g_shell_quote(f)) cmd.replace('%e', g_shell_quote(e)) cmd.replace('%d', g_shell_quote(d)) cmd.replace('%p', g_shell_quote(p))
return cmd
So you see that only the *replacement* is escaped/quoted, nothing else. So nobody will touch your * literal or whatever.
OK, to chose appropriate quoting you may argue one needs to understand sub-command syntax. Expanding the command:
cmd "$(cmd2 %f)"
to
cmd "$(cmd2 "'xxx.c'")"
is incorrect -- and that's what my patch would do, because it doesn't understand sub-shells. We may or may not want to make sure to support sub-shells -- that's not that hard, but may also not be that useful, but whatever.
So, how to fix it?
Don't, its not broke :)
Yes it is, although it's not really annoying because commands have quotes around placeholders and filenames generally don't include " literals. But try compiling a file whose name contains a " literal and you'll see it's broken ;)
Heh, ok, but so is using a " literal in a filename in that case :)
Agreed :) However, I think one shouldn't need to explicitly quote the placeholders in the build commands (and I think we don't quote %e in `make %e.o` by default); so it also holds for spaces or any other shell metacharacter.
Cheers, Colomban
Le 16/12/2012 01:47, Colomban Wendling a écrit :
[...]
OK, to chose appropriate quoting you may argue one needs to understand sub-command syntax. Expanding the command:
cmd "$(cmd2 %f)"
to
cmd "$(cmd2 "'xxx.c'")"
is incorrect -- and that's what my patch would do, because it doesn't understand sub-shells. We may or may not want to make sure to support sub-shells -- that's not that hard, but may also not be that useful, but whatever.
Attached an updated version of my patch to deal with `` and $() sub-shell syntax.
Cheers, Colomban
[...]
Hi Colomban,
Hehe, sorry, this email arrived just after another project just did something similar to "sanitise" inputs and broke my setup, making me very cranky, so I didn't want to have it happen to Geany :)
Oh, ok, but we have you to make sure we don't brake anything, you're Geany's regression test suite by yourself ;)
Heh, don't bet on it ;)
I agree that the security risk exists, but then it needs a peculiar filename, the only way to fix that would be to ban any shell metacharacters in filenames, but some users won't like that.
No, the solution is to escape or quote the replacements, so that any shell metacharacter in them wouldn't be interpreted by the shell.
Ok, yes if done correctly.
As for spaces in filenames, see below.
I think the idea is to just escape the filenames being replaced into %f et al placeholders, not the whole command en masse. IIRC, the only thing placed into the placeholders is filenames/paths, which should be able to be safely escaped/sanitized without messing up the whole command.
That's it. Another example like Matthew's one: what I want to do is only to make sure that e.g. "%f" is never replaced by something that will be interpreted as a command. Those placeholders (%f, %d, %e and %p) represent filenames or paths and never user-typed commands, so they should never be interpreted as a command.
For example, the simple command:
gcc "%f" -c -o "%e.o"Given the current file named:
holy "crap.cwould currently expand to:
gcc "holy "crap.c" -c -o "holy "crap.o"Which, huh, doesn't mean what you want at all! The commands will be understood as:
argv[0] = gcc argv[1] = holy crap.c -c -o holy argv[2] = crap.o
(if my shell unquoting skills are correct ;))
Understand, I think thats right.
What the user actually expected was:
argv[0] = gcc argv[1] = holy "crap.c argv[2] = -c argv[3] = -o argv[4] = holy "crap.o
Obviously, it's not the same :(
Thats obviously whats expected, and yes its not the same. Although inconvenient the above erroneous input would of course just give an error, "holy crap.c -c -o holy" not found. Well unless it is found :)
It would probably just throw a "file not found" error in this case, but who know what's the filename and as you pointed out yourself, who knows what was the actual command.
So again, what I want is to make sure the placeholders (%f & co.) are properly escaped/quoted/whatever so they never get misinterpreted like above. And as I said, to actually achieve this we have to somewhat understand the quoting in the user command because we can't escape the same inside or outside shell quotes -- e.g. %f (without quotes) cannot be escaped the same way as "%f" (with the quotes).
or %e.* for example?
No, it's the same as unquoted %e, since it's outside a quote.
But still nothing really clever trying to understand a meaning, just knowing the basics like '' and "" are quotes, and \ is an escape so we can know how to escape. Actually the implementation I proposed simply closes any open quote before replacing a quoted placeholder, and then re-opens it.
I.e. for the above example, it would replace as:
gcc ""'holy "crap.c'"" -c -o ""'holy "crap.o'""That's a bit ugly but you don't have to see it, and it's perfectly safe. Also, just to make sure you see what I mean, if the user command didn't quote the %f and %e, and the filename simply contained a space:
command: gcc %f -c -o %e.o filename: file name.c current replacement: gcc file name.c -c -o file name.o fixed replacement: gcc 'file name.c' -c -o 'file name'.o
You see? :)
Yeah, thats a normal command, but continuing my example from above, what do you get if I have
cmd %e.*
It would give:
cmd 'xxx'.*
because if lets say the filename is xxx.c, if you get
cmd "xxx.*"
then the * won't be treated as a glob since its quoted, so my command won't work. It needs to be
cmd "xxx."*
Nope, it needs to be
cmd 'xxx'.*
yeah, ok the . is stripped from the %e.
since we don't have to know what a . means, we just quote the placeholder replacement.
So is g_shell_quote smart enough for all possibilities of shell metacharacters? Including the full range of shell patterns, and backquote command substitution and etc. Then again what if the filename has a literal * in it, how does g_shell_quote know its literal or if we meant a glob?
`g_shell_quote()` escapes (or actually, quotes) the string we gives it, no matter what, we just don't pass it the user command. I think we have a misunderstanding here, so let's be clear and since we all are programmers, let's write code :) So here's a incredibly naive (and not correct enough, but see my real one for a less naive one) implementation in pseudo code:
def replace_placeholders(doc, cmd): f = os.path.basename(doc.filename) e = os.path.splitext(f)[0] d = os.path.dirname(doc.filename) p = app.project_path cmd.replace('%f', g_shell_quote(f)) cmd.replace('%e', g_shell_quote(e)) cmd.replace('%d', g_shell_quote(d)) cmd.replace('%p', g_shell_quote(p)) return cmdSo you see that only the *replacement* is escaped/quoted, nothing else. So nobody will touch your * literal or whatever.
Ok, I didn't get that before. Pseudo code is good :)
So is it *allways* going to be correct to just quote part of the command? (Apart from subcommands addressed below).
OK, to chose appropriate quoting you may argue one needs to understand sub-command syntax. Expanding the command:
cmd "$(cmd2 %f)"to
cmd "$(cmd2 "'xxx.c'")"is incorrect -- and that's what my patch would do, because it doesn't understand sub-shells. We may or may not want to make sure to support sub-shells -- that's not that hard, but may also not be that useful, but whatever.
If we don't support any particular shell capabilities we need to be very careful to document it, just so we have something to point to when people complain, having not read the manual. :)
We do need to support backquote subcommands since that is needed for GTK compilation to do pkg-config.
So, how to fix it?
Don't, its not broke :)
Yes it is, although it's not really annoying because commands have quotes around placeholders and filenames generally don't include " literals. But try compiling a file whose name contains a " literal and you'll see it's broken ;)
Heh, ok, but so is using a " literal in a filename in that case :)
Agreed :) However, I think one shouldn't need to explicitly quote the placeholders in the build commands (and I think we don't quote %e in `make %e.o` by default); so it also holds for spaces or any other shell metacharacter.
Heh, neither solution is always right, but the manual one is more flexible, and uses much less code ;) for example you still have to add code for the subshells and subcommands, but if its right then yes its more convenient.
Cheers Lex
Cheers, Colomban _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel