[Scons-users] escaping brackets () in file path

[Bill Deegan]

Carnë,

See comments inline.

On Sun, Feb 28, 2016 at 7:32 AM, Carnë Draug <carandraug+dev at gmail.com>
wrote:

> On 28 February 2016 at 03:24, Bill Deegan <bill at baddogconsulting.com>
> wrote:
> > Also I see you filed a bug.
>
> The original bug from this email was already existed.  I commented on that
> bug which was open in 2008:
>
>     http://scons.tigris.org/issues/show_bug.cgi?id=2225


O.k. thanks for highlighting it.


>
>
> I did report a new bug which is related to scons displaying one command
> but actually be running another one:
>
>     http://scons.tigris.org/issues/show_bug.cgi?id=3023


I'm going to mark this as invalid because this is by design. See comments
on bug as follows:




*It is ok for SCons to display one thing and the command which runs to be
another.This is by design.(see *COM vs *COMSTR in the manpage and also the
section on Action objects search for "The second argument is
optional")http://scons.org/doc/production/HTML/scons-man.html
<http://scons.org/doc/production/HTML/scons-man.html>*


>
>
> > We ask that users bring bugs to the users mailing list and only file
> bugs if
> > we've determined that it is a bug, and also that it's not a duplicate.
> > (this is to a) make that problems get more eyes (here on the users
> mailing
> > list), and b) try to minimize the noise in the bug tracking system and
> keep
> > the signal high.. )
>
> If the developers are following both the mailing list and the bug tracker
> (which I guess they are since they're filtering bugs from the first), then
> they'll be affected by the same noise.
>

You're assuming that the only people capable of helping a scons user with
their issue is one of the developers.
That's a flawed assumption.
A great many times other users have run into the issue and resolved it (or
had help in resolving it) and help out the other users.
Users rarely subscribe to the issues mailing list.


>
> Actually, it will cause more work for everyone because: 1) it needs to be
> reported on the mailing list first, filtered, and then reported on bug
> tracker again; and 2) the discussion will be fragmented making it harder
> to later find all the discussion related to it.
>

Actually not. If the user gets the answer on the mailing list
- known bug
- you're using the tool wrong

Then it's far less work.
And 95% of the time issues are caused by users unfamiliarity with how SCons
works and/or ways to make what they are trying to do work in SCons.

That leaves (maybe) 5% where there actually is a bug, we'll need to ask the
user to make a minimal test case (if possible) to attach to the bug so that
developers can reproduce it without a huge testcase.


>
> There would be more tickets on the tracker, so you'd get more hits when
> searching.  But you're using a quite powerful bug tracker.  You can easily
> search for bugs that are not "invalid", "wontfix", "duplicate", and
> "worksforme".
>
> That's just my experience.  Still, your project, your rules.  I won't do
> it again.
>
> > I don't believe any of the developers have yet requested that you file a
> > bug.
> >
> > If you take a look at the manpage there are several items which will
> > probably help you resolve your issue:
> > ( http://scons.org/doc/production/HTML/scons-man.html )
> > SPAWN
> >
> > A command interpreter function that will be called to execute command
> line
> > strings. The function must expect the following arguments:
> >
> > def spawn(shell, escape, cmd, args, env):
> >
> > sh is a string naming the shell program to use. escape is a function that
> > can be called to escape shell special characters in the command line.
> cmd is
> > the path to the command to be executed. args is the arguments to the
> > command. env is a dictionary of the environment variables in which the
> > command should be executed.
> >
> > ESCAPE
> >
> > A function that will be called to escape shell special characters in
> command
> > lines. The function should take one argument: the command line string to
> > escape; and should return the escaped command line.
> >
> >
> > SHELL
> >
> > A string naming the shell program that will be passed to the $SPAWN
> > function. See the $SPAWN construction variable for more information.
> >
> > I"m guessing changing env['ESCAPE'] to point to a function which properly
> > handles escaping your parens in the path (that's a new one for me) and/or
> > changing SHELL or SPAWN should be the simplest way to resolve this.
>
> That's still not working.  I'm not sure exactly what but I believe it has
> to
> do with extra quotes (it's hard to figure out exactly what is going on
> because
> the displayed commands work fine).  I have replaced ESCAPE with str() so
> that nothing is escaped.  Still:
>
>     $ cat SConstruct
>     #!/usr/bin/env python
>     # -*- coding: utf-8 -*-
>
>     env = Environment()
>     env['ESCAPE'] = str
>
>     env.Command(target='foo (bar) qux', source=None,
>                 action='python  -c "import sys; print sys.argv" $TARGET')
>
>     $ scons
>     scons: Reading SConscript files ...
>     scons: done reading SConscript files.
>     scons: Building targets ...
>     python -c "import sys; print sys.argv" "foo (bar) qux"
>     sh: 1: Syntax error: "(" unexpected
>     scons: *** [foo (bar) qux] Error 2
>     scons: building terminated because of errors.
>
> But that command is a perfectly valid command.  No idea what is happening:
>
>     $ python -c "import sys; print sys.argv" "foo (bar) qux"
>     ['-c', 'foo (bar) qux']
>
>
I ran (on a linux system):
strace -o logfile -s 32078 scons
grep python logfile and got the following:
write(1, "python -c \"import sys; print sys.argv\" \"foo (bar) qux\"\n",
55) = 55

When you run: python -c \"import sys; print sys.argv\" \"foo (bar) qux\
You get:
-bash: syntax error near unexpected token `('


So that is the escaping that was coming from string.

Here's a sample SConstruct with a new escape function, and the posix escape
function with debug output added.
Note that I've explicitly created an Action object and a string function
which calls the ESCAPE function specified in the Command().

https://pastebin.mozilla.org/8861630

If you run it, you'll get the following:

python /scons/as_scons/src/script/scons.py
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
Actual Command:touch escape\ \(bar\)\ qux
Actual Command:touch "posix_escape \(bar\) qux"
scons: done building targets.
bdbaddog at ubuntu1404-32bit:~/tmp$ ls -l *esc*
-rw-rw-r-- 1 bdbaddog bdbaddog 0 Feb 28 14:55 escape (bar) qux
-rw-rw-r-- 1 bdbaddog bdbaddog 0 Feb 28 14:55 posix_escape \(bar\) qux

So this new escape function solves the issue you initially listed (with the
touch command).
However I'm not sure if that's a vast simplification of the problem you're
encountering.
Also whether the  provided new escaping function resolves your real issue.

Please let us know.




>
> > Any reason in particular you want to have parens in your file
> names/paths?
>
> What?  Why do I need a reason?  It's a perfectly valid filename.  And
> unfortunately, it's a 4 years old choice that can't be changed now.
>

No you don't need a reason. Just curious.


Hope that helps.
-Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160228/48fd26c6/attachment-0001.html>