Repair a few more drake subdir paths in docs

automotive/maliput/dragway/README.md

@@ -14,7 +14,7 @@ specifiable.
 The executable `dragway_to_urdf` allows one create a URDF representation of a
 dragway. To run `dragway_to_urdf`, execute:
 
-    bazel run //drake/automotive/maliput/dragway:dragway_to_urdf -- \
+    bazel run //automotive/maliput/dragway:dragway_to_urdf -- \
           --dirpath=[dirpath] \
           --file_name_root=[file name root] \
           --lane_width=[lane width] \
@@ -24,7 +24,7 @@ dragway. To run `dragway_to_urdf`, execute:
 
 For an explanation on what the above-mentioned parameters mean, execute:
 
-    bazel run //drake/automotive/maliput/dragway:dragway_to_urdf -- --help
+    bazel run //automotive/maliput/dragway:dragway_to_urdf -- --help
 
 One the above command is executed, the following files should exist:
 

automotive/maliput/dragway/dragway_to_urdf.cc

@@ -64,7 +64,7 @@ int exec(int argc, char* argv[]) {
 
   // The following is necessary for users to know where to find the resulting
   // files when this program is executed in a sandbox. This occurs, for example
-  // when using `bazel run //drake/automotive/maliput/dragway:dragway_to_urdf`.
+  // when using `bazel run //automotive/maliput/dragway:dragway_to_urdf`.
   spruce::path my_path;
   my_path.setAsCurrent();
 

bindings/pydrake/common_py.cc

@@ -21,7 +21,7 @@ void trigger_an_assertion_failure() {
 }  // namespace
 
 PYBIND11_MODULE(_common_py, m) {
-  m.doc() = "Bindings for //drake/common:common";
+  m.doc() = "Bindings for //common:common";
 
   // Turn DRAKE_ASSERT and DRAKE_DEMAND exceptions into native SystemExit.
   // Admittedly, it's unusual for a python library like pydrake to raise

bindings/pydrake/test/odr_test.py

@@ -15,7 +15,7 @@
 import unittest
 
 import pydrake.symbolic as sym
-# This module also uses `//drake/common:symbolic`, but in a separate *.so.
+# This module also uses `//common:symbolic`, but in a separate *.so.
 # If we violate ODR, then this might link in a new definition.
 from pydrake.test import odr_test_module
 

doc/bazel.rst

@@ -89,7 +89,7 @@ Cheat sheet for operating on specific portions of the project::
   bazel test --config=asan common:polynomial_test      # Run one test under AddressSanitizer.
   bazel test --config=kcov common:polynomial_test      # Run one test under kcov (see instructions below).
   bazel build -c dbg common:polynomial_test && \
-    gdb ../bazel-bin/drake/common/polynomial_test      # Run one test under gdb.
+    gdb ../bazel-bin/common/polynomial_test            # Run one test under gdb.
 
   bazel test --config lint //...                       # Only run style checks; don't build or test anything else.
 
@@ -110,8 +110,8 @@ file, so we have implemented a workaround in Drake, ``--config=apple_debug``.
 This config turns off sandboxing, which allows a ``genrule`` to access the
 ``.o`` files and process them into a ``.dSYM``.  Use as follows::
 
-  bazel build --config=apple_debug drake/path/to/my:binary_or_test_dsym
-  lldb ./bazel-bin/drake/path/to/my/binary_or_test
+  bazel build --config=apple_debug path/to/my:binary_or_test_dsym
+  lldb ./bazel-bin/path/to/my/binary_or_test
 
 For more information, see https://github.com/bazelbuild/bazel/issues/2537.
 

doc/faq.rst

@@ -67,7 +67,7 @@ Why do OpenGL-based VTK targets run with ``bazel test`` sometimes fail on Linux?
 
 **Symptom**: While the binary works with ``bazel run``, when you run a test using ``bazel test``, such as::
 
-    $ bazel test //drake/systems/sensors:rgbd_camera_test
+    $ bazel test //systems/sensors:rgbd_camera_test
 
 you encounter a slew of errors from VTK / OpenGL::
 
@@ -97,7 +97,7 @@ As an example, in ``drake/systems/sensors/BUILD``::
 
 If this does not work, then try running the test in Bazel without sandboxing::
 
-    $ bazel test --spawn_strategy=standalone //drake/systems/sensors:rgbd_camera_test
+    $ bazel test --spawn_strategy=standalone //systems/sensors:rgbd_camera_test
 
 Please note that you can possibly add ``--spawn_strategy=standalone`` to your ``~/.bazelrc``, but be aware that this means your development machine
 may have a different environment than other development machines when running the test.

examples/double_pendulum/README.md

@@ -31,7 +31,7 @@ line arguments.
 To build this demo, from Drake's repository root path just run:
 
 ```
-bazel build drake/examples/double_pendulum:double_pendulum_demo
+bazel build examples/double_pendulum:double_pendulum_demo
 ```
 
 ## How do I run it?
@@ -45,5 +45,5 @@ To run this demo, from Drake's repository root first run:
 This will open up the visualization tool. Then run the demo with:
 
 ```
-bazel run drake/examples/double_pendulum:double_pendulum_demo -- [-simulation_time +inf] [-realtime_rate 1.0]
+bazel run examples/double_pendulum:double_pendulum_demo -- [-simulation_time +inf] [-realtime_rate 1.0]
 ```

examples/humanoid_controller/README.md

@@ -29,15 +29,15 @@ To run the demo: (assuming in drake's root directory)
 
 2. Start the controller before the simulator:
 
-    `$ ./bazel-bin/drake/examples/humanoid_controller/valkyrie_balancing_demo`
+    `$ ./bazel-bin/examples/humanoid_controller/valkyrie_balancing_demo`
 
 3. Start the simulator:
 
-    `$ ./bazel-bin/drake/examples/valkyrie/valkyrie_simulation`
+    `$ ./bazel-bin/examples/valkyrie/valkyrie_simulation`
 
 4. Execute a dummy manipulation plan:
 
-    `$ ./bazel-bin/drake/examples/humanoid_controller/send_manipulation_plan_demo -r_shy_offset -1`
+    `$ ./bazel-bin/examples/humanoid_controller/send_manipulation_plan_demo -r_shy_offset -1`
 
 Note that you can repeatedly send new plans, the controller will start executing
 the new plan as soon as it receives it.

examples/kuka_iiwa_arm/dev/box_rotation/README.md

@@ -14,12 +14,12 @@ bazel build //tools:drake_visualizer
 
 Ensure that you have built the iiwa controller with
 ```
-bazel build //drake/examples/kuka_iiwa_arm:iiwa_controller
+bazel build //examples/kuka_iiwa_arm:iiwa_controller
 ```
 
 Ensure that you have built the box rotation demo with
 ```
-bazel build //drake/examples/kuka_iiwa_arm/dev/box_rotation/...
+bazel build //examples/kuka_iiwa_arm/dev/box_rotation/...
 ```
 
 All instructions assume that you are launching from the `drake`

examples/particles/README.md

@@ -13,13 +13,13 @@ This is a demo that creates a very simple system of a 1-DOF particle, moving at
 To build this demo, from Drake's repository root path just run:
 
 ```
-bazel build drake/examples/particles/uniformly_accelerated_particle_demo
+bazel build examples/particles/uniformly_accelerated_particle_demo
 ```
 
 ### How do I run it?
 
 To run this demo, from Drake's repository root just run:
 
 ```
-bazel run drake/examples/particles:uniformly_accelerated_particle_demo -- [-initial_position 0.0] [-initial_velocity 0.0] [-acceleration 1.0] [-simulation_time +inf] [-realtime_rate 1.0]
+bazel run examples/particles:uniformly_accelerated_particle_demo -- [-initial_position 0.0] [-initial_velocity 0.0] [-acceleration 1.0] [-simulation_time +inf] [-realtime_rate 1.0]
 ```

examples/pr2/README.md

@@ -19,8 +19,8 @@ $ ./bazel-bin/tools/drake_visualizer
 
 2. Open another terminal and navigate to the root of the Drake distribution.
 Then, build and launch the pr2_passive_simulation, with the following commands:
-$ bazel build //drake/examples/pr2:pr2_passive_simulation 
-$ ./bazel-bin/drake/examples/pr2/pr2_passive_simulation 
+$ bazel build //examples/pr2:pr2_passive_simulation 
+$ ./bazel-bin/examples/pr2/pr2_passive_simulation 
 The seconds (relative to the simulation) that the simulation will run for can 
 be specified with the argument --simulation_sec=<seconds to simulate>. If this
 argument is not specified, then the simulation will run forever.

solvers/create_cost.h

@@ -40,7 +40,7 @@ Binding<Cost> ParseCost(const symbolic::Expression& e);
 namespace detail {
 
 // From Drake git sha 24452c1:
-// //drake/solvers/mathematical_program.h:739
+// drake/solvers/mathematical_program.h:739
 // libstdc++ 4.9 evaluates
 // `std::is_convertible<std::unique_ptr<Unrelated>,
 // std::shared_ptr<Constraint>>::value`