[Scons-users] Controlling display of a builder

[Bill Deegan]

So for this command all strings should be quoted?
Or at least that would do no harm?


On Sat, Oct 17, 2015 at 4:12 PM, Carnë Draug <carandraug+dev at gmail.com>
wrote:

> On 18 October 2015 at 00:01, Bill Deegan <bill at baddogconsulting.com>
> wrote:
> >
> > On Sat, Oct 17, 2015 at 3:11 PM, Carnë Draug <carandraug+dev at gmail.com>
> > wrote:
> >>
> >> On 17 October 2015 at 22:53, William Blevins <wblevins001 at gmail.com>
> >> wrote:
> >> > On Sat, Oct 17, 2015 at 10:29 PM, Carnë Draug <
> carandraug+dev at gmail.com>
> >> > wrote:
> >> >>
> >> >> On 17 October 2015 at 20:57, Bill Deegan <bill at baddogconsulting.com>
> >> >> wrote:
> >> >> >
> >> >> > On Sat, Oct 17, 2015 at 11:55 AM, Carnë Draug
> >> >> > <carandraug+dev at gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hi
> >> >> >>
> >> >> >> I have been using the possibility to pass extra arguments to
> Command
> >> >> >> to have them used in a builder.  I am doing something like the
> >> >> >> following:
> >> >> >>
> >> >> >>     scons_subprocess_call = (lambda target, source, env
> >> >> >>                                     : subprocess.call(env['ARGS'],
> >> >> >> source[0]))
> >> >> >>
> >> >> >>     data = env.Command(
> >> >> >>       source = "foo.pl",
> >> >> >>       target = "bar.log",
> >> >> >>       action = scons_subprocess_call,
> >> >> >>       ARGS   = ['homo sapiens', 'Reference GRCh'])
> >> >> >>
> >> >> >> The problem with this is that the output of SCons won't display
> >> >> >> anything
> >> >> >> useful:
> >> >> >>
> >> >> >>     $ scons
> >> >> >>     [...]
> >> >> >>     scons: Building targets ...
> >> >> >>     <lambda>(["bar.log"], ["foo.pl"])
> >> >> >>     [...]
> >> >> >>
> >> >> >> The main reason I am doing this is to avoid the shell since some
> of
> >> >> >> the
> >> >> >> arguments have whitespace, single and double quotes, and even
> >> >> >> wildcards.
> >> >> >> This makes generation of a command problematic.  I have tried to
> >> >> >> write
> >> >> >> my
> >> >> >> own builder but the problem remains.  I create a Builder either by
> >> >> >> setting a `action`, and continue with the problem of not having
> the
> >> >> >> actual
> >> >> >> call made displayed, or by setting a `generator`, and face the
> >> >> >> problem
> >> >> >> of
> >> >> >> escaping any weird stuff in the arguments.
> >> >> >>
> >> >> >>
> >> >> >> Short of having the builder print() something, is there any way to
> >> >> >> create
> >> >> >> a Builder that does not boil down to create a command line for the
> >> >> >> shell,
> >> >> >> while still controlling what SCons displays?
> >> >> >>
> >> >> >> (I am aware that this means that what gets displayed will not
> match
> >> >> >> a command line.  However, it would still be more informative)
> >> >> >>
> >> >> >> Thank you,
> >> >> >> Carnë
> >> >> >
> >> >> > Carnë,
> >> >> >
> >> >> > No need to do all that coding.  SCons will expand and escape
> >> >> > arguments
> >> >> > for
> >> >> > you..
> >> >> >
> >> >> >
> >> >> > env=Environment()
> >> >> >
> >> >> >
> >> >> > if False:
> >> >> >     scons_subprocess_call = (lambda target, source, env
> >> >> >                              : subprocess.call(env['ARGS'],
> >> >> > source[0]))
> >> >> >     data = env.Command(
> >> >> >         source = "foo.pl",
> >> >> >         target = "bar.log",
> >> >> >         action = scons_subprocess_call,
> >> >> >         ARGS   = ['homo sapiens', 'Reference GRCh'])
> >> >> > else:
> >> >> >     data = env.Command(
> >> >> >         source = "./foo.pl",
> >> >> >         target = "bar.log",
> >> >> >         action = "${SOURCE.abspath} $ARGS  > $TARGET",
> >> >> >         ARGS   = ['homo sapiens', 'Reference GRCh'])
> >> >> >
> >> >> >
> >> >> >
> >> >> > Produces:
> >> >> > python ~/devel/scons/hg/scons/bootstrap.py
> >> >> > /usr/bin/python
> >> >> > /Users/bdbaddog/devel/scons/hg/scons/bootstrap/src/script/scons.py
> >> >> > scons: Reading SConscript files ...
> >> >> > scons: done reading SConscript files.
> >> >> > scons: Building targets ...
> >> >> > /Users/bdbaddog/devel/scons/bugs/10_17_2015/foo.pl "homo sapiens"
> >> >> > "Reference
> >> >> > GRCh" > bar.log
> >> >> > scons: done building targets.
> >> >> >
> >> >>
> >> >> This is pretty cool.  I didn't know that.  However, it still does not
> >> >> work
> >> >> for my case because it's not escaping wildcards (my ARGS are simple
> >> >> regular
> >> >> expression for gene symbols such as 'HIST1*').  Is this a bug and
> >> >> should
> >> >> I report it?
> >> >>
> >> >> Here's a full example.  The one liner perl prints back all of the
> >> >> script
> >> >> arguments.  Note how "bar*" and "foo*" get expanded to the list of
> >> >> files,
> >> >> and how the script never receives the "bar*" and "foo*".
> >> >>
> >> >>     $ mkdir scons-playground
> >> >>     $ cd scons-playground/
> >> >>     $ cat > foo.pl
> >> >>     print "$_\n" for @ARGV;
> >> >>     $ cat > SConstruct
> >> >>     env = Environment()
> >> >>     env.Command(
> >> >>       source="foo.pl",
> >> >>       target="foo.log",
> >> >>       action="perl $SOURCE $ARGS > $TARGET",
> >> >>       ARGS = ["bar*", "foo*"])
> >> >>     $ touch foobar bar bar1 bar2 bar3
> >> >>     $ scons
> >> >>     scons: Reading SConscript files ...
> >> >>     scons: done reading SConscript files.
> >> >>     scons: Building targets ...
> >> >>     perl foo.pl bar* foo* > foo.log
> >> >>     scons: done building targets.
> >> >>     $ cat foo.log
> >> >>     bar
> >> >>     bar1
> >> >>     bar2
> >> >>     bar3
> >> >>     foo.pl
> >> >>     foobar
> >> >>
> >> >>
> >> >> Carnë
> >> >
> >> > Can you use Glob() here?
> >> >
> >>
> >> You missunderstood my issue.  I don't want the widlcard expansion, I
> want
> >> the argument "foo*" to be passed as an argument to the application.  I
> >> don't
> >> want the shell to be involved in any way.  This example was showing the
> >> bug
> >> (or possible bug, I'm still not sure if SCons is meant to escape
> >> wildcards,
> >> I only heard about that feature now).
> >>
> >> Carnë
> >
> > Good question.
> >
> > I can see both instances where you'd want to quote and also not quote
> > wildcarded arguments.
> >
> > Can you manually quote them
> >
> > '"bar*"' ?
>
> The arguments that will be used and come with wildcards are build options.
> So yes, I could manually quote them, but I'd rather avoid the business of
> manipulating the input strings and risk messing it up somehow (some of the
> options will already include quotes, e.g., '"homo sapiens"[organism]').
>
> Which is why I was using subprocess.call() at the start. I want to pass
> those options untouched to application.
>
> Carnë
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20151017/1ed15a7c/attachment-0001.html>