Repeatedly use grep to find some files in base/ and mojo/ that includes
base/stl_util.h but do not use any functions provided by
base/stl_util.h and base/cxx*_backports.h, and then remove the
base/stl_util.h include from them. Files that include base/stl_util.h,
but actually needs base/cxx*_backports.h, will be dealt with separately.
Fix the build by adding a missing include to base/process/memory_win.cc.
Bug: 1194078
Change-Id: I2f74ac6a64751ca9264f3a20f79b06b71e181cec
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2912135
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Auto-Submit: Lei Zhang <thestig@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#886625}
This change allows the installer to bypass a DCHECK in CommandLine.
The DCHECK enforces that no arguments are parsed by
QuoteForCommandLineToArgvW with syntax "%*", e.g., %1, %2, etc. These
argument placeholders are called "insert sequences" and are used by
the Windows shell.
The DCHECK is intended to prevent new code from generating a command
line for the Windows shell by parsing a string like "chrome.exe %1"
instead of using the purpose-built GetCommandLineStringForShell().
However, setup.exe does generate a command line from string for itself
that contains placeholders, and has no need for the special syntax
created by GetCommandLineStringForShell(). Its use case is known to be
safe because the insert sequence %1 is substituted by Google Update in
a safe way. In order to support this call site, this change adds
GetCommandLineStringWithUnsafeInsertSequences(), which skips the
DCHECK, and invokes it in the setup code in question.
Bug: 1181955
Change-Id: I4b7e64a7a83b887b32c57207ce4ac3850d40f874
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2727878
Reviewed-by: Greg Thompson <grt@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Jesse McKenna <jessemckenna@google.com>
Cr-Commit-Position: refs/heads/master@{#861452}
This reverts commit 2538167d39.
Reason for revert: This relands the two reverted CLs.
The original change to the command-line syntax (landed in two separate
CLs) caused the following issues:
* Temporary breakage after background update from `chrome.exe %1`
syntax to `chrome.exe --single-argument=%1` (crbug.com/1092913),
when a file is opened via the shell:
* Registry contains `--single-argument=%1`, running browser sees no
argument (only an unrecognized switch), opens new tab page
* Crashes after attempted fix that replaced `--single-argument=%1`
with `--single-argument %1` due to a CHECK in the first change
enforcing the presence of the `=` character:
* After background update, registry contains `--single-argument %1`,
running browser CHECKs for `=` and crashes (crbug.com/1096004)
* Windows 7 Dev channel (expecting `=`) default-browser check parses
Canary's registry command line (containing ` `) to get the default
browser path (crbug.com/1096964), triggering CHECK
* Crash when unregistering PWA file handlers on local Chromium build
(crbug.com/1096004#c3), presumed to be caused by parsing the
shell/open command written by file-handler registration on an
older version (as local Chromium builds don't background update)
What all the above issues have in common is that they are caused by
incompatibility between new and old versions. With this in mind, this
reland assumes that the old and new syntax can and will be mixed in
potentially unexpected ways.
This change replaces `chrome.exe %1` with
`chrome.exe --single-argument %1`, which is flexible enough to handle
the following cases:
* If registry contains old syntax and running browser expects new
syntax:
* Due to the absence of the `--single-argument` switch, the command
line will be parsed normally (potentially as multiple arguments)
* If registry contains new syntax and running browser expects old
syntax:
* The browser will ignore the unrecognized `--single-argument`
switch and parse the command line normally (as the argument still
appears after a space like in the current syntax)
* If browser parses command line from another channel with different
syntax:
* Covered by either the first or second case above
This reland also replaces the single remaining CHECK with a DCHECK.
Original change's description:
> Revert "Limit Windows-shell-based launches to one argument" and "Replace --single-argument= with --single-argument"
>
> This reverts commits 452f831564
> and 74ae85ac6e.
>
> Reason for revert: this CL and crrev.com/c/2238270, which introduced
> the --single-argument flag to the Windows command line, have caused
> issues (crbug.com/1092913, crbug.com/1096004, and crbug.com/1096964)
> related to incompatibility between the Chrome command line in the
> registry and that expected by the running browser. crrev.com/c/2238270
> was an attempt to fix those issues, but outstanding bug
> crbug.com/1096964 is still not well-understood and has made it to the
> Dev channel. This change reverts both CLs to prevent further issues
> and to enable a future reland that incorporates lessons learned.
> Reverting both CLs simultaneously is necessary to prevent trybot
> failures due to the same registry-browser command-line incompatibility
> issues (i.e., browser-test trybots having the current command-line
> syntax "chrome.exe --single-argument %1" in their registry, and
> failing to recognize the argument in the between-changes syntax
> "chrome.exe --single-argument=%1").
>
> Original change's description:
> > Limit Windows-shell-based launches to one argument
> >
> > This change adds "--single-argument" to launches done via the Windows
> > shell, which makes Chrome treat all text after "--single-argument=" as
> > Chrome's one and only argument. This limits shell-based launches to
> > passing only one argument to Chrome.
> >
> > Previously, Chrome's command line as registered with the Windows shell
> > was `chrome.exe "%1"`, %1 being Windows' filename placeholder. The
> > shell replaces this placeholder with the file/URL that Chrome has been
> > invoked on (e.g., if the link "https://www.chromium.org" were clicked,
> > Chrome would be run with command line
> > `chrome.exe "https://www.chromium.org"`.
> >
> > With this change, Chrome's command line is
> > `chrome.exe --single-argument=%1`, and the contents of %1 are treated
> > as a single argument regardless of quotes or spacing.
> >
> > Code that creates the command line string for the Windows shell (e.g.
> > code writing Chrome's command line to the registry) must use the new
> > format by calling GetCommandLineStringForShell(), which appends
> > "--single-argument=%1" to the returned string.
> >
> > Bug: 937179
> > Change-Id: I6c0d6f0abce7a8c9f65ca8b90d15438310db7c92
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2116596
> > Commit-Queue: Jesse McKenna <jessemckenna@google.com>
> > Reviewed-by: Lei Zhang <thestig@chromium.org>
> > Reviewed-by: Greg Thompson <grt@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#773398}
>
> TBR=thestig@chromium.org,grt@chromium.org,jessemckenna@google.com
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> Bug: 937179
> Change-Id: I014cd0b1acb5080b16b68268ea8d20eb18f9b431
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2255138
> Commit-Queue: Jesse McKenna <jessemckenna@google.com>
> Reviewed-by: Jesse McKenna <jessemckenna@google.com>
> Cr-Commit-Position: refs/heads/master@{#780559}
TBR=thestig@chromium.org,grt@chromium.org,jessemckenna@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: 937179
Change-Id: I3d83b82bddaf1a40235273bce94541c63322cc7a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2273598
Reviewed-by: Greg Thompson <grt@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Jesse McKenna <jessemckenna@google.com>
Commit-Queue: Jesse McKenna <jessemckenna@google.com>
Cr-Commit-Position: refs/heads/master@{#789641}
This reverts commits 452f831564
and 74ae85ac6e.
Reason for revert: this CL and crrev.com/c/2238270, which introduced
the --single-argument flag to the Windows command line, have caused
issues (crbug.com/1092913, crbug.com/1096004, and crbug.com/1096964)
related to incompatibility between the Chrome command line in the
registry and that expected by the running browser. crrev.com/c/2238270
was an attempt to fix those issues, but outstanding bug
crbug.com/1096964 is still not well-understood and has made it to the
Dev channel. This change reverts both CLs to prevent further issues
and to enable a future reland that incorporates lessons learned.
Reverting both CLs simultaneously is necessary to prevent trybot
failures due to the same registry-browser command-line incompatibility
issues (i.e., browser-test trybots having the current command-line
syntax "chrome.exe --single-argument %1" in their registry, and
failing to recognize the argument in the between-changes syntax
"chrome.exe --single-argument=%1").
Original change's description:
> Limit Windows-shell-based launches to one argument
>
> This change adds "--single-argument" to launches done via the Windows
> shell, which makes Chrome treat all text after "--single-argument=" as
> Chrome's one and only argument. This limits shell-based launches to
> passing only one argument to Chrome.
>
> Previously, Chrome's command line as registered with the Windows shell
> was `chrome.exe "%1"`, %1 being Windows' filename placeholder. The
> shell replaces this placeholder with the file/URL that Chrome has been
> invoked on (e.g., if the link "https://www.chromium.org" were clicked,
> Chrome would be run with command line
> `chrome.exe "https://www.chromium.org"`.
>
> With this change, Chrome's command line is
> `chrome.exe --single-argument=%1`, and the contents of %1 are treated
> as a single argument regardless of quotes or spacing.
>
> Code that creates the command line string for the Windows shell (e.g.
> code writing Chrome's command line to the registry) must use the new
> format by calling GetCommandLineStringForShell(), which appends
> "--single-argument=%1" to the returned string.
>
> Bug: 937179
> Change-Id: I6c0d6f0abce7a8c9f65ca8b90d15438310db7c92
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2116596
> Commit-Queue: Jesse McKenna <jessemckenna@google.com>
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Reviewed-by: Greg Thompson <grt@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#773398}
TBR=thestig@chromium.org,grt@chromium.org,jessemckenna@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: 937179
Change-Id: I014cd0b1acb5080b16b68268ea8d20eb18f9b431
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2255138
Commit-Queue: Jesse McKenna <jessemckenna@google.com>
Reviewed-by: Jesse McKenna <jessemckenna@google.com>
Cr-Commit-Position: refs/heads/master@{#780559}
This change changes the command-line single-argument switch, used for
launches from the Windows shell, from `--single-argument=` to
`--single-argument `. This fixes an issue where users who have updated
but not restarted Chrome are unable to open shell links (due to the
mismatch between the just-updated open command in the registry and the
expectations of the now-obsolete running browser).
crrev.com/c/2116596 changed the command line used by the Windows shell
(and set in the registry) from `"chrome.exe" "%1"` (where %1 is
replaced by the argument to launch by the shell) to
`"chrome.exe" --single-argument=%1` to enforce a limit of one
argument on shell-based launches.
This caused old versions (those which have updated but not restarted
Chrome) to receive `--single-argument=<arg>` when Chrome is invoked
from the shell, but be unable to interpret it. Because this change
replaces the `=` with ` `, it is more backwards-compatible with old
versions. They will simply ignore the `--single-argument` switch and
interpret the space-delimited <arg> as the argument until the user
restarts Chrome to launch the new version.
Bug: 1092913
Change-Id: Iba734fe290944176f7ad38d36e670a1bea04623b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2238270
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Jesse McKenna <jessemckenna@google.com>
Cr-Commit-Position: refs/heads/master@{#778584}
This change adds "--single-argument" to launches done via the Windows
shell, which makes Chrome treat all text after "--single-argument=" as
Chrome's one and only argument. This limits shell-based launches to
passing only one argument to Chrome.
Previously, Chrome's command line as registered with the Windows shell
was `chrome.exe "%1"`, %1 being Windows' filename placeholder. The
shell replaces this placeholder with the file/URL that Chrome has been
invoked on (e.g., if the link "https://www.chromium.org" were clicked,
Chrome would be run with command line
`chrome.exe "https://www.chromium.org"`.
With this change, Chrome's command line is
`chrome.exe --single-argument=%1`, and the contents of %1 are treated
as a single argument regardless of quotes or spacing.
Code that creates the command line string for the Windows shell (e.g.
code writing Chrome's command line to the registry) must use the new
format by calling GetCommandLineStringForShell(), which appends
"--single-argument=%1" to the returned string.
Bug: 937179
Change-Id: I6c0d6f0abce7a8c9f65ca8b90d15438310db7c92
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2116596
Commit-Queue: Jesse McKenna <jessemckenna@google.com>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#773398}
This change modifies base::CommandLine::StringType to be std::wstring on
Windows. It relies on changing base::FilePath::StringType to
std::wstring on Windows as well, in order to compile once base::string16
is no longer std::wstring.
Bug: 911896
Change-Id: I07accc7e043fadf2b584799b699881f300e18bb2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1875748
Reviewed-by: Robert Liao <robliao@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Jan Wilken Dörrie <jdoerrie@chromium.org>
Cr-Commit-Position: refs/heads/master@{#709226}
When there are multiple switches having the same key within the argv
array, CommandLine constructor only puts one of them within the
parsed-out switches map.
On the other hand, CommandLine::RemoveSwitch removes a switch from the
switches map. It should also drop all the switches having the same key
from the argv array.
BUG=957138
TEST=base_unittests --gtest_filter="CommandLineTest.*"
Change-Id: Ia4cf08bc497d4d53e0213879df71f85d945a4fec
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1724079
Auto-Submit: Andrei Polushin <anpol@yandex-team.ru>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682443}
This change prepares //base for the upcoming switch of base::string16 to
std::u16string.
Bug: 911896
Change-Id: I01ca2d0c2634503438f4e9f3b18681d182555b40
Reviewed-on: https://chromium-review.googlesource.com/c/1437195
Commit-Queue: Jan Wilken Dörrie <jdoerrie@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#628381}
This is a followup to http://crrev.com/366963 . That change made
the '--disable-web-security' flag have no effect unless the
'--user-data-dir' flag was also specified. This was done to encourage
the use of the '--disable-web-security' flag only for development
and not for general purpose use.
However, that change (locking '--disable-web-security' to
'--user-data-dir') was made only in one place in the Chromium code.
There are quite a few other places in Chromium that turn off security
features when '--disable-web-security' is specified, and none of
them lock it to the use of the '--user-data-dir' flag.
Therefore, move the lock to much earlier in Chromium startup, and if
the '--user-data-dir' flag isn't specified, remove the
'--disable-web-security' flag entirely from the CommandLine. That
way, this correctly locks together those two flags for all of
Chromium.
BUG=923523,327804
Change-Id: I9000f1fbd2c236a435d8dae25870dead870ddd55
Reviewed-on: https://chromium-review.googlesource.com/c/1423342
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Chris Palmer <palmer@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#625210}
This cleans up multi-platform code paths selection and prepares for
the removal of OS_POSIX for the Fuchsia build.
Bug: 836416
Change-Id: I3a8e6393d0a9981aa890fb6d8c302ed8d2bdd69d
Reviewed-on: https://chromium-review.googlesource.com/1031099
Commit-Queue: Fabrice de Gans-Riberi <fdegans@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559230}
Command line wrappers (e.g., --renderer-cmd-prefix) were previously
split into individual arguments purely based on whitespace. This fails
if the prefix has arguments with embedded whitespace (e.g., gdb -ex "set
height 0").
This patch fixes the issue by tokenizing the prefix based on whitespace
while using ' and " as quote characters.
BUG=546953
Review-Url: https://codereview.chromium.org/2778173003
Cr-Commit-Position: refs/heads/master@{#460443}
This avoids the string allocation when searching for a char* in a
std::map<std::string>.
CommandLine now maintains a parallel map of StringPieces that reference
the strings in |switches_|. StringPiece is trivial to construct from a
string, and only requires a strlen to construct from a char*.
On a profile with 2 extensions, HasSwitch is called ~12k times during
startup. In an ideal situation (no paging/cache pressure), the
string allocation under Windows takes ~137ns on a Xeon E5-2690 @
2.9Ghz. A strlen on a typical switch takes about 50ns, and 91% of calls
pass a char*, so there's a net saving of at least
(137 - 0.9 * 50)ns * 12k = 1.1ms from a typical startup with this
hardware. For context, Startup.BrowserMessageLoopStartTimeFromMainEntry
is typically 280-300ms on the same hardware, so we should get a ~0.4%
improvement.
BUG=472383
Review URL: https://codereview.chromium.org/1063933002
Cr-Commit-Position: refs/heads/master@{#330902}
At the moment, all compile-time switches are lowercase. By enforcing
this, we can skip converting it to lowercase on Windows, which saves
one string allocation per call.
On a profile with 2 extensions, HasSwitch is called ~12k times during
startup. In an ideal situation (no paging/cache pressure), the
string allocation under Windows takes ~137ns on an Xeon E5-2690 @
2.9Ghz. So this should shave off at least 1.6ms off a typical startup
with this hardware. For context,
Startup.BrowserMessageLoopStartTimeFromMainEntry is typically
280-300ms on the same hardware, so we should get a ~0.5% improvement.
BUG=472383
Committed: https://crrev.com/f58961749a980032241fe6c3fc829ac2e6652030
Cr-Commit-Position: refs/heads/master@{#325576}
Review URL: https://codereview.chromium.org/1046363002
Cr-Commit-Position: refs/heads/master@{#326219}
At the moment, all compile-time switches are lowercase. By enforcing
this, we can skip converting it to lowercase on Windows, which saves
one string allocation per call.
On a profile with 2 extensions, HasSwitch is called ~12k times during
startup. In an ideal situation (no paging/cache pressure), the
string allocation under Windows takes ~137ns on an Xeon E5-2690 @
2.9Ghz. So this should shave off at least 1.6ms off a typical startup
with this hardware. For context,
Startup.BrowserMessageLoopStartTimeFromMainEntry is typically
280-300ms on the same hardware, so we should get a ~0.5% improvement.
BUG=472383
Review URL: https://codereview.chromium.org/1046363002
Cr-Commit-Position: refs/heads/master@{#325576}
Prefix all CommandLine usage in the base/ directory with the
base:: namespace.
BUG=422426
Review URL: https://codereview.chromium.org/645133002
Cr-Commit-Position: refs/heads/master@{#305626}
Added an optional parameter |quote_placeholder| to GetCommandLineString
and GetArgumentsString. If true, placeholder command-line arguments such
as "%1" will also be quoted. These need quoting in case the substituted
argument has a space in it. It was previously not possible to build a
CommandLine that would contain a quoted "%1" when converted to a string.
Only affects Windows.
BUG=416785
Review URL: https://codereview.chromium.org/595803002
Cr-Commit-Position: refs/heads/master@{#297617}
Previously, this test would crash if the output wasn't quoted properly
(since it assumes that cmd_string.length() >= program_string.length() +
2). Instead, directly compare the string with the expected output. This
also guards against the possibility of mis-constructing the expected
string.
Review URL: https://codereview.chromium.org/589393002
Cr-Commit-Position: refs/heads/master@{#296350}
This is im preparation for removing the 'using" in file_path.h
Review URL: https://codereview.chromium.org/12286020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@183021 0039d316-1c4b-4281-b951-d872f2087c98
Related to this, parse a single dash on the command line as argument, instead of a switch with no value and name
BUG=111316
TEST=out/Debug/content_shell --dump-render-tree path/to/test.html works
Review URL: https://chromiumcodereview.appspot.com/11184050
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@162947 0039d316-1c4b-4281-b951-d872f2087c98
If there are multiple callers to Init, only one should call Reset. The boolean return value tells the caller whether they are the one responsible for the destruction. As long as the lifetimes of clients are strictly nested (i.e., a client X who uses CommandLine after client Y has initialized it always ceases its use before client Y destroys it) this secures access to this singleton object.
One client in particular is updated to follow this model. I will submit follow-up CLs for remaining clients (at least, those who currently do call Reset).
This is motivated by a crash in the chrome_frame_net_tests. This test executable nests a TestSuite within the lifetime of a ContentMainRunner (i.e., the engine that is typically used to run Chrome). The content layer initializes CommandLine and Resets it, but the TestSuite also resets it, leading to a DCHECK. This is currently the last remaining issue keeping the chrome_frame_net_tests off the waterfall, and I am very eager to get them back there to reduce the likelihood of further issues being introduced.
BUG=114369
TEST=A test has been modified to reflect this change.
Review URL: http://codereview.chromium.org/9477001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@123763 0039d316-1c4b-4281-b951-d872f2087c98
avoid searching the entire length of each switch for the -- prefix, as we know it can only exist at the start.
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/7866036
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@100918 0039d316-1c4b-4281-b951-d872f2087c98
CommandLine::Init()
In the multi-DLL build, we can end up initializing the object
twice at startup (once in chrome.exe and once in chrome.dll).
It should be harmless.
BUG=76996
TEST=base_unittests
Review URL: http://codereview.chromium.org/7273053
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@92380 0039d316-1c4b-4281-b951-d872f2087c98
Significant refactoring with some notable behavior changes:
1. Switches are appended preceding existing arguments (after other swtiches).
2. (Windows) command_line_string() is generated and properly quoted/escaped.
3. Appended switches will retain their (optional) included prefixes (--,-,/).
Notable internal changes (shouldn't affect behavior):
1. (Windows) Generate the cl string, instead of storing&updating the original.
2. Explicitly retain switch prefixes (--,-,/) (was automatic in init*/ctor).
Update (obvious) code expecting switches to be appended antecedent to args.
Add Nico's test from: codereview.chromium.org/6728016/.
An intermediary CL landed between patch set 3 and 4, see:
http://codereview.chromium.org/6596020
BUG=73195,67764
TEST=Commandline usage.
Review URL: http://codereview.chromium.org/6526040
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@85360 0039d316-1c4b-4281-b951-d872f2087c98
BUG=none
TEST=Run the ProgramQuotes test. Should be no visible changes.
Review URL: http://codereview.chromium.org/4949004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67583 0039d316-1c4b-4281-b951-d872f2087c98
For some reason the Win bot failed to compile the sandbox unit test.
Trybots and my machines don't have these build problems, so I'm going to try again, unchanged.
Original description:
Changing the installer switches from wchar_t[] to char[].
Because of this I'm also refactoring some code that before
was using wstring to build command lines by hand instead of
using the CommandLine class. Now we use CommandLine.
To get this to work correctly, I also needed to fix CommandLine::AppendArguments so I added a little test for it.
TEST=There should be no changes in functionality. Run all installer tests.
BUG=61609
TBR=robertshield
Review URL: http://codereview.chromium.org/4989001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66096 0039d316-1c4b-4281-b951-d872f2087c98
Because of this I'm also refactoring some code that before
was using wstring to build command lines by hand instead of
using the CommandLine class. Now we use CommandLine.
To get this to work correctly, I also needed to fix CommandLine::AppendArguments so I added a little test for it.
TEST=There should be no changes in functionality. Run all installer tests.
BUG=61609
Review URL: http://codereview.chromium.org/4928002TBR=tommi@chromium.org
Review URL: http://codereview.chromium.org/4988001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66089 0039d316-1c4b-4281-b951-d872f2087c98
Because of this I'm also refactoring some code that before
was using wstring to build command lines by hand instead of
using the CommandLine class. Now we use CommandLine.
To get this to work correctly, I also needed to fix CommandLine::AppendArguments so I added a little test for it.
TEST=There should be no changes in functionality. Run all installer tests.
BUG=61609
Review URL: http://codereview.chromium.org/4928002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66088 0039d316-1c4b-4281-b951-d872f2087c98
This was already removed on non-Windows, so this change modifies
the remaining Windows-specific usage. In a few places I converted
use of wstring paths into FilePath, but in general for Windows-specific
code I don't think it's too important to use FilePath everywhere,
because it is equivalent on Windows and the current code already works.
BUG=23581
Review URL: http://codereview.chromium.org/3817001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@62637 0039d316-1c4b-4281-b951-d872f2087c98
This makes uses of StringPrintf and friends use the base namespace and include
stringprintf.h explicitly. This also removes a bunch of unnecessary string_util
includes (which exposed a few other errors like people forgetting to include
<vector>.
TEST=it compiles
BUG=none
Review URL: http://codereview.chromium.org/3119022
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56446 0039d316-1c4b-4281-b951-d872f2087c98
Our command line code is not very good with respect to getting
quoting right. Because of this, callers will sometimes themselves
attempt to quote arguments, though some of them get it wrong(!) by
just surrounding with quotes.
The first step is to add a quoting function that we think is correct
and update the unit test to test it.
(Note that most of this is Windows-specific, because on POSIX
we can pass arguments to commands as a vector -- trying to do
quoting on POSIX is usually wrong.)
Review URL: http://codereview.chromium.org/3007038
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55591 0039d316-1c4b-4281-b951-d872f2087c98
For this patch, I skipped over any instance where it wasn't a nearly trivial
change.
Review URL: http://codereview.chromium.org/3069014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54285 0039d316-1c4b-4281-b951-d872f2087c98
