feat: move the $ shell line indicator to scss (#1354)

Author: vordimous

assets/scss/_grpc.scss

@@ -154,6 +154,32 @@ body:not(.td-blog) .td-content:not(.list-page) {
   }
 }
 
+// Render the bash $ prefix indicator to enable easier copy of cli commands
+.td-content div.highlight pre {
+  padding-left: 0.5rem;
+  code.language-sh:before {
+    content: "$";
+    margin-left: 0.5rem;
+  }
+  code.language-sh span {
+    display: inline !important;
+    margin-left: 0.25rem;
+  }
+}
+
+// Render the powershell > prefix indicator to enable easier copy of cli commands
+.td-content div.highlight pre {
+  padding-left: 0.5rem;
+  code.language-powershell:before {
+    content: ">";
+    margin-left: 0.5rem;
+  }
+  code.language-powershell span {
+    display: inline !important;
+    margin-left: 0.25rem;
+  }
+}
+
 /*
 The following contains some styles in use on the top-level pages
 (About, Community...). Bootstrap provides many responsive utilities

content/en/blog/bazel-rules-protobuf.md

@@ -41,8 +41,8 @@ To best follow along,
 and clone the rules_protobuf repository:
 
 ```sh
-~$ git clone https://github.com/pubref/rules_protobuf
-~$ cd rules_protobuf
+git clone https://github.com/pubref/rules_protobuf
+cd rules_protobuf
 ~/rules_protobuf$
 ```
 
@@ -89,7 +89,7 @@ Let's look at the file tree, showing only those folder having a
 `BUILD` file:
 
 ```diff
-$ tree -P 'BUILD|WORKSPACE' -I 'third_party|bzl' examples/
+tree -P 'BUILD|WORKSPACE' -I 'third_party|bzl' examples/
 .
 ├── BUILD
 ├── WORKSPACE
@@ -130,7 +130,7 @@ within the examples folder, and say what kind of thing it is in
 addition to its path label"*:
 
 
-```sh
+```bash
 ~/rules_protobuf$ bazel query //examples/... --output label_kind | sort | column -t
 
 cc_binary                   rule  //examples/helloworld/cpp:client
@@ -174,7 +174,7 @@ named as an external repository (more on this later) and we can also
 address targets in that workspace in the same way.  Here's a partial
 list:
 
-```sh
+```bash
 ~/rules_protobuf$ bazel query @com_github_google_protobuf//... --output label_kind | sort | column -t
 
 cc_binary       rule  @com_github_google_protobuf//:protoc
@@ -201,7 +201,7 @@ build all the dependent libraries, build a pristine executable binary
 from source, and call it (pass command line arguments to binary rules
 after the double-dash):
 
-```sh
+```bash
 ~/rules_protobuf$ bazel run @com_github_google_protobuf//:protoc -- --help
 Usage: /private/var/tmp/_bazel_pcj/63330772b4917b139280caef8bb81867/execroot/rules_protobuf/bazel-out/local-fastbuild/bin/external/com_github_google_protobuf/protoc [OPTION] PROTO_FILES
 Parse PROTO_FILES and generate output based on the options given:
@@ -322,7 +322,7 @@ via a compromised network.
 For example, we can peek at the generated BUILD file for the
 `maven_jar` guava dependency via:
 
-```sh
+```bash
 ~/rules_protobuf$ cat $(bazel info execution_root)/external/com_google_guava_guava/jar/BUILD
 ```
 
@@ -361,7 +361,7 @@ root package of the external workspace com_github_madler_zlib.*" Bazel
 reports this reverse dependency set.  We request the output in
 graphviz format and pipe this to dot to generate the figure:
 
-```sh
+```bash
 ~/rules_protobuf$ bazel query "rdeps(deps(//examples/...), @com_github_madler_zlib//:zlib)" \
                   --output graph | dot -Tpng -O
 ```
@@ -461,7 +461,7 @@ simultaneously:
 ```
 
 ```sh
-$ bazel build :pluriproto
+bazel build :pluriproto
 # ************************************************************
 cd $(bazel info execution_root) && bazel-out/host/bin/external/com_github_google_protobuf/protoc \
 --plugin=protoc-gen-grpc-java=bazel-out/host/genfiles/third_party/protoc_gen_grpc_java/protoc_gen_grpc_java \
@@ -637,7 +637,7 @@ This demo application can be cloned at
 Here's the directory layout and relevant BUILD files we'll be using:
 
 ```sh
-~$ mkdir grpc_greetertimer && cd grpc_greetertimer
+mkdir grpc_greetertimer && cd grpc_greetertimer
 ~/grpc_greetertimer$ mkdir -p proto/ go/ java/org/pubref/grpc/greetertimer/
 ~/grpc_greetertimer$ touch WORKSPACE
 ~/grpc_greetertimer$ touch proto/BUILD
@@ -795,7 +795,7 @@ go_binary(
 )
 ```
 
-```sh
+```bash
 ~/grpc_greetertimer$ bazel build //go:client
 ```
 
@@ -864,7 +864,7 @@ executable jar.  If these jar files have not yet been downloaded from
 maven central, they will be fetch as soon as we need them:
 
 
-```sh
+```bash
 ~/grpc_greetertimer$ bazel build java/org/pubref/grpc/greetertimer:server
 ~/grpc_greetertimer$ bazel build java/org/pubref/grpc/greetertimer:server_deploy.jar
 ```
@@ -878,7 +878,7 @@ that can be run independently in a jvm.
 
 First, we'll start a greeter server (one at a time):
 
-```sh
+```bash
 ~/grpc_greetertimer$ cd ~/rules_protobuf
 ~/rules_protobuf$ bazel run examples/helloworld/go/server
 ~/rules_protobuf$ bazel run examples/helloworld/cpp/server
@@ -889,7 +889,7 @@ INFO: Server started, listening on 50051
 
 In a separate terminal, start the greetertimer server:
 
-```sh
+```bash
 ~/grpc_greetertimer$ bazel build //java/org/pubref/grpc/greetertimer:server_deploy.jar
 ~/grpc_greetertimer$ java -jar bazel-bin/java/org/pubref/grpc/greetertimer/server_deploy.jar
 ```

content/en/blog/coreos.md

@@ -57,7 +57,7 @@ service EchoService {
 This means the gateway, once generated by `protoc`, can now accept a HTTP request from `curl` like this:
 
 ```sh
-$ curl -X POST -k https://localhost:10000/v1/echo -d '{"value": "CoreOS is hiring!"}'
+curl -X POST -k https://localhost:10000/v1/echo -d '{"value": "CoreOS is hiring!"}'
 ```
 
 The whole system so far looks like this, with a single `service.proto` file generating both a gRPC server and a REST proxy:
@@ -77,15 +77,15 @@ if r.ProtoMajor == 2 && strings.Contains(r.Header.Get("Content-Type"), "applicat
 To try it out, all you need is a working Go 1.6 development environment and the following simple commands:
 
 ```sh
-$ go get -u github.com/philips/grpc-gateway-example
-$ grpc-gateway-example serve
+go get -u github.com/philips/grpc-gateway-example
+grpc-gateway-example serve
 ```
 
 With the server running you can try requests on both HTTP 1.1 and gRPC interfaces:
 
 ```sh
-$ grpc-gateway-example echo Take a REST from REST with gRPC
-$ curl -X POST -k https://localhost:10000/v1/echo -d '{"value": "CoreOS is hiring!"}'
+grpc-gateway-example echo Take a REST from REST with gRPC
+curl -X POST -k https://localhost:10000/v1/echo -d '{"value": "CoreOS is hiring!"}'
 ```
 
 One last bonus: because we have an Open API specification, you can browse the Open API UI running at `https://localhost:10000/swagger-ui/#!/EchoService/Echo` if you have the server above running on your laptop.

content/en/blog/grpc-dotnet-build.md

@@ -37,7 +37,7 @@ directory
 
 Let's start by creating a new library project.
 
-```sh
+```bash
 ~/work$ dotnet new classlib -o MyGreeter
 The template "Class library" was created successfully.
 
@@ -55,7 +55,7 @@ this exercise, we'll copy an example file [`examples/protos/helloworld.proto`
 ](https://github.com/grpc/grpc/blob/master/examples/protos/helloworld.proto)
 from the gRPC distribution.
 
-```sh
+```bash
 ~/work/MyGreeter$ rm Class1.cs
 ~/work/MyGreeter$ wget -q https://raw.githubusercontent.com/grpc/grpc/master/examples/protos/helloworld.proto
 ```
@@ -67,7 +67,7 @@ and use a *Save As...* command from your Web browser).
 
 Next, add required NuGet packages to the project:
 
-```sh
+```bash
 ~/work/MyGreeter$ dotnet add package Grpc
 info : PackageReference for package 'Grpc' version '1.17.0' added to file '/home/kkm/work/MyGreeter/MyGreeter.csproj'.
 ~/work/MyGreeter$ dotnet add package Grpc.Tools
@@ -131,7 +131,7 @@ idea to always do that the very first time you compile a project!
 Note that many output lines are omitted below, as the build output is quite
 verbose.
 
-```sh
+```bash
 ~/work/MyGreeter$ dotnet build -v:n
 
 Build started 11/9/18 5:33:44 PM.
@@ -173,7 +173,7 @@ accidentally placed under source control. Otherwise, they are accessible to the
 tools like the debugger. You can see other autogenerated sources in that
 directory, too:
 
-```sh
+```bash
 ~/work/MyGreeter$ find obj -name '*.cs'
 obj/Debug/netstandard2.0/MyGreeter.AssemblyInfo.cs
 obj/Debug/netstandard2.0/Helloworld.cs

content/en/blog/grpc-web-ga.md

@@ -78,7 +78,7 @@ service TodoService {
 CommonJS client-side code can be generated from this `.proto` definition with the following command:
 
 ```sh
-$ protoc echo.proto \
+protoc echo.proto \
   --js_out=import_style=commonjs:./output \
   --grpc-web_out=import_style=commonjs:./output
 ```

content/en/blog/grpc-with-json.md

@@ -172,17 +172,17 @@ final class KvService extends KvGson.KeyValueServiceImplBase {
 After implementing all the methods on the server, we now have a fully functioning gRPC Java, JSON encoding RPC system.  And to show you there is nothing up my sleeve:
 
 ```sh
-$ ./gradlew :dependencies | grep -i proto
-$ # no proto deps!
+./gradlew :dependencies | grep -i proto
+# no proto deps!
 ```
 
 ## Optimizing the Code
 
 While Gson is not as fast as Protobuf, there's no sense in not picking the low hanging fruit.  Running the code we see the performance is pretty slow:
 
 ```sh
-$ ./gradlew installDist
-$ time ./build/install/kvstore/bin/kvstore
+./gradlew installDist
+time ./build/install/kvstore/bin/kvstore
 
 INFO: Did 215.883 RPCs/s
 ```
@@ -213,8 +213,8 @@ That's not right!  Looking at a `RetrieveRequest`, we see that the key bytes are
 Using this in our marshallers, we can see a dramatic performance difference:
 
 ```sh
-$ ./gradlew installDist
-$ time ./build/install/kvstore/bin/kvstore
+./gradlew installDist
+time ./build/install/kvstore/bin/kvstore
 
 INFO: Did 2,202.2 RPCs/s
 ```

content/en/blog/optimizing-grpc-part-1.md

@@ -133,8 +133,8 @@ Since the code is safe and correct, let's see how it performs.  For my measureme
 Ubuntu system with a 12 core processor and 32 GB of memory.  Let's build and run the code:
 
 ```sh
-$ ./gradlew installDist
-$ time ./build/install/kvstore/bin/kvstore
+./gradlew installDist
+time ./build/install/kvstore/bin/kvstore
 Feb 26, 2018 1:10:07 PM io.grpc.examples.KvRunner runClient
 INFO: Starting
 Feb 26, 2018 1:11:07 PM io.grpc.examples.KvRunner runClient
@@ -345,8 +345,8 @@ Now the code runs successfully, and doesn't run out of memory.
 Building and running the code again looks a lot better:
 
 ```sh
-$ ./gradlew installDist
-$ time ./build/install/kvstore/bin/kvstore
+./gradlew installDist
+time ./build/install/kvstore/bin/kvstore
 Feb 26, 2018 2:40:47 PM io.grpc.examples.KvRunner runClient
 INFO: Starting
 Feb 26, 2018 2:41:47 PM io.grpc.examples.KvRunner runClient

content/en/blog/optimizing-grpc-part-2.md

@@ -170,8 +170,8 @@ per RPC, but a lot more are happening at the same time.  Let's see if our hypoth
 Before:
 
 ```sh
-$ ./gradlew installDist
-$ time ./build/install/kvstore/bin/kvstore
+./gradlew installDist
+time ./build/install/kvstore/bin/kvstore
 Apr 16, 2018 10:38:42 AM io.grpc.examples.KvRunner runClient
 INFO: Did 24.067 RPCs/s
 

content/en/docs/languages/cpp/basics.md

@@ -36,14 +36,14 @@ Get the example code and build gRPC:
  2. From the repo folder, change to the route guide example directory:
 
     ```sh
-    $ cd examples/cpp/route_guide
+    cd examples/cpp/route_guide
     ```
  3. Run `cmake`
 
     ```sh
-    $ mkdir -p cmake/build
-    $ cd cmake/build
-    $ cmake -DCMAKE_PREFIX_PATH=$MY_INSTALL_DIR ../..
+    mkdir -p cmake/build
+    cd cmake/build
+    cmake -DCMAKE_PREFIX_PATH=$MY_INSTALL_DIR ../..
     ```
 
 ### Defining the service
@@ -142,14 +142,14 @@ you want to run this yourself, make sure you've installed protoc and followed
 the gRPC code [installation instructions](https://github.com/grpc/grpc/blob/{{< param grpc_vers.core >}}/src/cpp/README.md#cmake) first):
 
 ```sh
-$ make route_guide.grpc.pb.o
+make route_guide.grpc.pb.o
 ```
 
 which actually runs:
 
 ```sh
-$ protoc -I ../../protos --grpc_out=. --plugin=protoc-gen-grpc=`which grpc_cpp_plugin` ../../protos/route_guide.proto
-$ protoc -I ../../protos --cpp_out=. ../../protos/route_guide.proto
+protoc -I ../../protos --grpc_out=. --plugin=protoc-gen-grpc=`which grpc_cpp_plugin` ../../protos/route_guide.proto
+protoc -I ../../protos --cpp_out=. ../../protos/route_guide.proto
 ```
 
 Running this command generates the following files in your current directory:
@@ -502,19 +502,19 @@ independently.
 Build the client and server:
 
 ```sh
-$ make
+make
 ```
 
 Run the server:
 
 ```sh
-$ ./route_guide_server --db_path=path/to/route_guide_db.json
+./route_guide_server --db_path=path/to/route_guide_db.json
 ```
 
 From a different terminal, run the client:
 
 ```sh
-$ ./route_guide_client --db_path=path/to/route_guide_db.json
+./route_guide_client --db_path=path/to/route_guide_db.json
 ```
 
 [build and locally install gRPC from source]: {{< relref "quickstart#install-grpc" >}}