Enable setting configuration arguments for Mojo applications with mojo_shell

Enable setting configuration arguments for Mojo applications with mojo_shell.

Applications can retrieve the configuration arguments with the ApplicationImpl args() method (see https://codereview.chromium.org/568173003).

A Mojo application can be specified with a URL followed by one or more arguments, so long as the entire expression is within quotes:

  mojo_shell 'mojo://mojo_wget http://www.google.com'

The "args-for" switch can be used to specify arguments for Mojo applications that are started by the specified app:

  mojo_shell args-for='mojo:mojo_native_viewport_service foo bar' mojo:mojo_surfaces_app

The args-for switch can be used repeatedly to specify arguments for multiple Mojo apps.

BUG=418797
Committed: https://crrev.com/00b23e2a533a185c672f3cbacbc61176cd2800e4
Cr-Commit-Position: refs/heads/master@{#297924}

[hansmuller, 2014-09-30 17:47:15]

hansmuller@chromium.org changed reviewers:
+ davemoore@chromium.org

[hansmuller, 2014-09-30 17:52:39]

I modified the wget example app to use this feature. PTAL.

[DaveMoore, 2014-10-01 21:21:16]

The code looks fine, but I'm not sure about the syntax. --args-for seems wordy.
I'm torn on the 'mojo:foo a b' syntax too. Leaving out the single quotes is
going to result in a difficult to diagnose error.

Originally we had talked about something like

mojo_shell mojo:foo --args mojo:foo a b --args mojo:bar c d

Perhaps we would have to enforce that no other args can be passed after the
first --args instance

--args mojo:foo --disable-cache c d 

is ambiguous.

I bet there's a better solution though that I'm not thinking of

[hansmuller, 2014-10-01 21:32:51]

On 2014/10/01 21:21:16, DaveMoore wrote:
> The code looks fine, but I'm not sure about the syntax. --args-for seems
wordy.
> I'm torn on the 'mojo:foo a b' syntax too. Leaving out the single quotes is
> going to result in a difficult to diagnose error.
> 
> Originally we had talked about something like
> 
> mojo_shell mojo:foo --args mojo:foo a b --args mojo:bar c d
> 
> Perhaps we would have to enforce that no other args can be passed after the
> first --args instance
> 
> --args mojo:foo --disable-cache c d 
> 
> is ambiguous.
> 
> I bet there's a better solution though that I'm not thinking of

Creating a single command-line argument by enclosing space separated text in
quotes is conventional and supported by all shells. Bracketing a command-line
argument with --args isn't even conventional.

How about changing -args-for to just '-args'?

[hansmuller, 2014-10-01 23:47:49]

On 2014/10/01 21:21:16, DaveMoore wrote:
> The code looks fine, but I'm not sure about the syntax. --args-for seems
wordy.
> I'm torn on the 'mojo:foo a b' syntax too. Leaving out the single quotes is
> going to result in a difficult to diagnose error.
> 
> Originally we had talked about something like
> 
> mojo_shell mojo:foo --args mojo:foo a b --args mojo:bar c d
> 
> Perhaps we would have to enforce that no other args can be passed after the
> first --args instance
> 
> --args mojo:foo --disable-cache c d 
> 
> is ambiguous.
> 
> I bet there's a better solution though that I'm not thinking of

What's needed is a way to specify the command-lines for the apps that are being
launched by mojo_shell directly and the command-lines for apps that might be
launched indirectly. In other words the arguments to mojo_shell are
command-lines embedded in the mojo-shell command line. A switch (or switches)
are needed to distinguish the apps that to be launched directly, from the ones
that have only been specified to associate a Mojo URL with a command-line.

If you choose to bracket the mojo_shell's embedded command-lines with something
other than quotes, users will still have to carefully quote embedded command
line arguments to avoid having the shell expand them.

Inventing a special mojo_shell syntax using switches and special-case rules
would obviate quoting each embedded command-line in its entirety. But then
you're asking developers to learn and apply our syntax, and tangle with its
failure modes.

I think simply quoting the embedded command-lines is a better approach since it
avoids the pitfalls of inventing our own syntax and with the inadvertent
expansion of the shell's special characters. 

If a better solution is proposed then I'd be glad to pitch quoting in favor of
that better solution.

[DaveMoore, 2014-10-02 15:06:20]

Ok. I can't think of anything better so moving forward with what you have is
fine.

LGTM
On 2014/10/01 23:47:49, hansmuller wrote:
> On 2014/10/01 21:21:16, DaveMoore wrote:
> > The code looks fine, but I'm not sure about the syntax. --args-for seems
> wordy.
> > I'm torn on the 'mojo:foo a b' syntax too. Leaving out the single quotes is
> > going to result in a difficult to diagnose error.
> > 
> > Originally we had talked about something like
> > 
> > mojo_shell mojo:foo --args mojo:foo a b --args mojo:bar c d
> > 
> > Perhaps we would have to enforce that no other args can be passed after the
> > first --args instance
> > 
> > --args mojo:foo --disable-cache c d 
> > 
> > is ambiguous.
> > 
> > I bet there's a better solution though that I'm not thinking of
> 
> What's needed is a way to specify the command-lines for the apps that are
being
> launched by mojo_shell directly and the command-lines for apps that might be
> launched indirectly. In other words the arguments to mojo_shell are
> command-lines embedded in the mojo-shell command line. A switch (or switches)
> are needed to distinguish the apps that to be launched directly, from the ones
> that have only been specified to associate a Mojo URL with a command-line.
> 
> If you choose to bracket the mojo_shell's embedded command-lines with
something
> other than quotes, users will still have to carefully quote embedded command
> line arguments to avoid having the shell expand them.
> 
> Inventing a special mojo_shell syntax using switches and special-case rules
> would obviate quoting each embedded command-line in its entirety. But then
> you're asking developers to learn and apply our syntax, and tangle with its
> failure modes.
> 
> I think simply quoting the embedded command-lines is a better approach since
it
> avoids the pitfalls of inventing our own syntax and with the inadvertent
> expansion of the shell's special characters. 
> 
> If a better solution is proposed then I'd be glad to pitch quoting in favor of
> that better solution.

[hansmuller, 2014-10-02 15:30:02]

The CQ bit was checked by hansmuller@chromium.org

[commit-bot: I haz the power, 2014-10-02 15:31:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/617943002/1

[commit-bot: I haz the power, 2014-10-02 16:05:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-10-02 16:05:57]

Try jobs failed on following builders:
  win_chromium_compile_dbg on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[hansmuller, 2014-10-02 18:04:41]

The CQ bit was checked by hansmuller@chromium.org

[commit-bot: I haz the power, 2014-10-02 18:06:02]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/617943002/20001

[hansmuller, 2014-10-02 18:22:25]

The CQ bit was unchecked by hansmuller@chromium.org

[hansmuller, 2014-10-02 21:26:32]

The CQ bit was checked by hansmuller@chromium.org

[commit-bot: I haz the power, 2014-10-02 21:28:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/617943002/60001

[commit-bot: I haz the power, 2014-10-02 22:27:19]

Committed patchset #4 (id:60001) as b357ba4cb46fd7ccafa7df92c98d49456803681e

[commit-bot: I haz the power, 2014-10-02 22:28:20]

Patchset 4 (id:??) landed as
https://crrev.com/00b23e2a533a185c672f3cbacbc61176cd2800e4
Cr-Commit-Position: refs/heads/master@{#297924}