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-contentdiv.highlightpre {
+padding-left: 0.5rem;
+code.language-sh:before {
+content: "$";
+margin-left: 0.5rem;
+ }
+code.language-shspan {
+display: inline!important;
+margin-left: 0.25rem;
+ }
+}
+
+// Render the powershell > prefix indicator to enable easier copy of cli commands
+.td-contentdiv.highlightpre {
+padding-left: 0.5rem;
+code.language-powershell:before {
+content: ">";
+margin-left: 0.5rem;
+ }
+code.language-powershellspan {
+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
 
 WhileGson 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" >}}