[Geany-Devel] Placeholder replacement in (build) commands

Lex Trotman elextr at xxxxx
Thu Apr 2 00:40:32 UTC 2015

On 2 April 2015 at 04:50, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> On 01.4.2015 г. 04:33, Lex Trotman wrote:
>> On 1 April 2015 at 04:45, Dimitar Zhekov<dimitar.zhekov at gmail.com>  wrote:
>>> On 31.3.2015 г. 03:16, Lex Trotman wrote:
>>> - In all default Geany commands, the placeholders are unquoted, meaning
>>> that
>>> any file name with space(s) currently breaks. Shame on us. :)
>> Well some of the default commands are double quoted, but not all IIRC
>> (filetypes.c uses all double quotes for eg).
> Really... with double quotes, very nice for Windows. :)

Are you sure they don't?  see

Says they work, no better than they work on sh though :)

>>> - The quotes are different under Unix/Win~1: single vs. double.
>> So in fact we should have two sets of filetype files, one for
>> linstalls and one for winstalls with different quotes on their
>> commands.
> Or remove them if we do minimal native quotation.

Indeed, but the link above says the rules are different for win and lin, sigh.

>>> I think there is an absolute minimum we can do about it: quote the
>>> file/directory name placeholders natively, but if, and only if, the
>>> entire
>>> command does not contain any single or double quotes. I don't see a way
>>> this
>>> can fail, but maybe elextr can prove me wrong.
>> Only for the commands run under the shell, if you mean "no quote
>> character in the command *and* all the replacement texts"[1] then it
>> would work on Linux but that makes its behaviour depend on the command
>> text and the replacement text so I forsee much confusion.  Better to
>> be consistent.
> I should have clarified: if the original command, before any placeholder
> expansion, does not contain any quotes. If there is at least a single quote,
> we assume the user knows what (s)he is doing.

Well, its a simple rule, but on win, paths ending in backslash will
break because you get prog "c:\dir with spaces\" and the closing quote
is escaped.  So its no improvement on the current situation.

Note that the quotes on the C filetype build commands may be because
of the system() hack, since it passes stuff through cmd before
creating the process and cmd has *another* set of quotes, see the link

Also if I read the win rules right, quoting %d would prevent you doing
"%d\filename with spaces" or "%d\%f" to get absolute paths, since it
doesn't do the catenation of separately quoted parts that sh does (as
I read it).  On sh you would do %d'\filename with spaces' or %d\\%f.

>> And if we use double quotes on Linux, then $ and ` (at least) will
>> have special powers[2] which you may not want in a filename, but may
>> want elsewhere.  So again we don't know if we should escape the
>> special chars or not.
> Quote it *natively*. That is "name" under Windows (can not contain "), and
> 'name' under Unix, with ' escaped.

For Posix sh you simply can't put single quotes inside single quotes
because backslash is not an escape inside single quotes.  You have to
end the single quotes just before the single quote, double quote the
single quote and then single quote the rest. eg cmd 'no $ \ ` special
chars here except '"'"' or here'

> For file and directory name placeholders
> only. I don't think any child program will want to receive file names with
> spaces split into several arguments.

Awww, thats no fun :)

>> Maybe we should throw away running under the shell, who's silly idea
>> was it anyway :)
> It'll be a good thing to do IMHO, but won't help in this case. We split the
> non-shell commands under Unix with glib's g_shell_parse_argv(), which uses
> the shell syntax. So quoting with 'name' and escaping ' is always right.

Not under sh, see above.  But if we threw away sh and did our own
thing then maybe.  Lets invent a new quoting standard for Geany
command splitting https://xkcd.com/927/ :)

>> [1] think of %f being "fred's data" inside single quotes
> 'fred'\''s data' (I guess you don't mean " as part of the name, but they
> won't be problematic either)
>> [2] think of the %f being "$amounts", that will confuse the shell, and
>> will be real fun if amounts is defined :)
> '$amounts'. Our current double-quoted placeholders make it "$amounts", so
> the users users of Geany can have fun.

As the shell substitutes whatever amounts is defined to be :) But
maybe I *want* to substitute $CFLAGS into the command.

So I still think we should either do nothing, or get it RIGHT.

Adding lots of code to just swap the current issues for a different
set doesn't sound sensible, but I'm not sure we have quite hit on
"right" yet.

For me right means:

- that it "just works" most of the time,
- there are no situations where the user is screwed totally and can't
get what they want, and
- existing quoting either still works or crashes loudly, it never
silently does something different.

And there is still those commands that are not run in the shell to
consider, how are they quoted so they split up right.

And windows.



> --
> E-gards: Jimmy
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel

More information about the Devel mailing list