R on Zhenguo Zhang's Blog

[R] Understanding position_dodge() and position_dodge2() in ggplot2

Sun, 30 Aug 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/08/30/r-understanding-position-dodge-and-position-dodge2-in-ggplot2/ -

In ggplot2, when displaying grouped data along categorical axes (such as grouped bar charts, boxplots, or error bars), horizontal dodging is used to prevent elements from overlapping at each categorical position. ggplot2 provides two primary dodging position functions: position_dodge() and position_dodge2().

In this post, we will explore:

How the width parameter in position_dodge() interacts with the parent geom’s width.
The core differences between position_dodge2() and position_dodge(), including why changing width in position_dodge2() often has no visual effect.
How preserve = "single" behaves when elements of a group variable are missing at a given x-axis level.

Definition of Terms

To keep our explanations clear and consistent throughout this post, we define two key concepts:

x-axis level: The discrete value or category on the x-axis. In our examples using mtcars, the x-axis level is cyl (with levels 4, 6, and 8).
group variable: The variable that divides items into subgroups at each x-axis level, typically mapped to an aesthetic like fill or color. In our examples, the group variable is gear (with levels 3, 4, and 5).
dodged elements: The individual visual marks (e.g. bars) corresponding to each level of the group variable at a specific x-axis level.

library(ggplot2)
library(patchwork)

1. The `width` Parameter in `position_dodge()`

What does `width` control?

In position_dodge(width = ...), width specifies the total dodging span (interval) on the x-axis into which all dodged elements for a given x-axis level are arranged side-by-side.

By default, if you do not explicitly supply width to position_dodge(), it inherits its value from the parent geom (e.g., geom_bar() defaults to width = 0.9).

Interaction between `geom_bar(width)` and `position_dodge(width)`

geom_bar(width = ...): Sets the total physical width allocated to the bars at each x-axis level. The individual bar width is derived by dividing this value by the number of elements at that x-axis level.
position_dodge(width = ...): Sets the total span on the x-axis across which the center positions of the dodged elements are calculated and spaced.

Both parameters use x-axis coordinate units (where the distance between adjacent discrete x-axis levels is 1.0).

Let’s examine how varying both parameters affects the layout using the mtcars dataset (plotting mean mpg across x-axis level cyl, with group variable gear mapped to fill):

# Base plot configuration
base_p <- ggplot(mtcars, aes(x = factor(cyl), y = mpg, fill = factor(gear))) +
  labs(x = "Cylinders (x-axis level)", y = "Mean MPG", fill = "Gear (group variable)") +
  theme_minimal(base_size = 11)

# Case 1: Default matching widths (0.9 / 0.9)
# Bars touch neatly within each x-axis level
p1 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    width = 0.9, 
    position = position_dodge(width = 0.9)
  ) +
  ggtitle("1. Matching widths (0.9 / 0.9)", subtitle = "Bars touch neatly within each x-axis level")

# Case 2: geom_bar width (0.5) < dodge width (0.9)
# Dodging span is 0.9, but bars are narrower -> gaps appear between bars
p2 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    width = 0.5, 
    position = position_dodge(width = 0.9)
  ) +
  ggtitle("2. geom_bar(0.5) < dodge(0.9)", subtitle = "Gaps created between dodged elements")

# Case 3: geom_bar width (0.9) > dodge width (0.5)
# Dodging span is narrower than bar widths -> bars overlap
p3 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    width = 0.9, 
    position = position_dodge(width = 0.5)
  ) +
  ggtitle("3. geom_bar(0.9) > dodge(0.5)", subtitle = "Dodged elements overlap")

# Case 4: Both changed to 0.6
# Group as a whole is narrower, bars touch, larger separation between x-axis levels
p4 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    width = 0.6, 
    position = position_dodge(width = 0.6)
  ) +
  ggtitle("4. Both set to 0.6", subtitle = "Compact cluster, wider space between x-axis levels")

(p1 | p2) / (p3 | p4)

As demonstrated: - Increasing width in geom_bar() increases the individual width of dodged elements at that x-axis level. - Increasing width in position_dodge() increases the total dodging span across which elements are spread. - When both values are equal, the dodged elements within each x-axis level touch each other without overlapping or leaving gaps.

2. Differences Between `position_dodge2()` and `position_dodge()`

While position_dodge() was originally designed for simple geoms with fixed-width positions (like geom_bar and geom_col), position_dodge2() was introduced to handle geoms with variable widths or explicit intervals (xmin to xmax), such as geom_boxplot(), geom_rect(), and geom_linerange().

Key Differences:

Boundary-Based Packing vs. Fixed Slot Offsets:
- position_dodge() divides the total dodge width at an x-axis level into fixed slots and places each level of the group variable into its designated slot.
- position_dodge2() packs elements (for different levels of the group variable) sequentially side-by-side using the bounding boxes of the geoms.
The width Parameter Has No Visual Effect in position_dodge2() with Bars:
- Because position_dodge2() arranges bars based on their pre-computed bounding intervals rather than calculating center slot offsets from a dodge span, changing width in position_dodge2() produces no change in the plot output when bar widths are already defined by the parent geom.
- Bar widths must be controlled directly via geom_bar(width = ...).
Built-in padding and reverse Support:
- padding: Adds proportional space between dodged elements at the same x-axis level without requiring manual mismatch of geom and dodge widths.
- reverse = TRUE: Reverses the left-to-right plotting order of the group variable without needing to alter factor levels.

Demo: `width` Has No Effect in `position_dodge2()`

Below, we compare position_dodge2(width = 0.3) against position_dodge2(width = 0.9). Notice that the two plots are completely identical:

# Changing width in position_dodge2 produces identical output
p_d2_w03 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    position = position_dodge2(width = 0.3)
  ) +
  ggtitle("position_dodge2(width = 0.3)", subtitle = "Width parameter has no visual effect")

p_d2_w09 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    position = position_dodge2(width = 0.9)
  ) +
  ggtitle("position_dodge2(width = 0.9)", subtitle = "Identical layout to width = 0.3")

p_d2_w03 | p_d2_w09

Creating Spacing with `padding` and Reversing Order with `reverse`

Instead of altering width, position_dodge2() provides the padding and reverse parameters:

# Using padding and reverse in position_dodge2
p_dodge2_demo <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    position = position_dodge2(padding = 0.2, reverse = TRUE)
  ) +
  labs(
    title = "position_dodge2(padding = 0.2, reverse = TRUE)",
    subtitle = "Built-in bar padding and reversed order of group variable"
  )

p_dodge2_demo

3. Handling Missing Elements with `preserve = "single"`

A significant functional difference between position_dodge() and position_dodge2() occurs when certain levels of the group variable are absent at a specific x-axis level.

Let’s inspect the count of observations across cyl (x-axis level) and gear (group variable) in mtcars:

table(mtcars$cyl, mtcars$gear)

##    
##      3  4  5
##   4  1  8  2
##   6  2  4  1
##   8 12  0  2

At the x-axis level cyl = 8, the group variable gear contains observations for gears 3 (12 cars) and 5 (2 cars), but gear = 4 is completely missing (0 cars).

When we set preserve = "single" to ensure that all individual bar widths remain uniform across all x-axis levels:

position_dodge(preserve = "single"): Retains fixed slot assignments. Because gear = 4 is missing at cyl = 8, it leaves a blank gap in the middle where gear = 4 would normally reside.
position_dodge2(preserve = "single"): Preserves individual bar width while re-centering the remaining dodged elements, packing them side-by-side without leaving an empty gap.

# position_dodge with preserve = "single"
p_dodge_single <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    position = position_dodge(preserve = "single")
  ) +
  labs(
    title = "position_dodge(preserve = 'single')",
    subtitle = "Leaves an empty gap for missing gear = 4 at cyl = 8"
  )

# position_dodge2 with preserve = "single"
p_dodge2_single <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    position = position_dodge2(preserve = "single")
  ) +
  labs(
    title = "position_dodge2(preserve = 'single')",
    subtitle = "Re-centers remaining elements (no gap at cyl = 8)"
  )

# Side-by-side comparison
p_dodge_single | p_dodge2_single

Note that if one sets preserve = “total”, then you would not see any difference, because the bars are re-stretched to ensure the bars from each categorical level occupy all the width assigned to that level.

Summary

Feature	`position_dodge()`	`position_dodge2()`
Primary Use Cases	Simple 1D fixed-width geoms (`geom_bar`, `geom_col`)	Interval & variable-width geoms (`geom_boxplot`, `geom_rect`, `geom_linerange`) and bars
Role of `width` Parameter	Sets total dodging span across each x-axis level	Has no visual effect on bars with predefined geom width
Missing Elements (`preserve="single"`)	Leaves empty slot / gap at the missing level	Re-centers remaining dodged elements together
Padding Between Elements	Manual (`geom_bar(width) < position_dodge(width)`)	Built-in via `padding = ...` argument
Reverse Plotting Order	Requires re-leveling the group variable	Built-in via `reverse = TRUE` argument

- https://fortune9.netlify.app/2026/08/30/r-understanding-position-dodge-and-position-dodge2-in-ggplot2/ -

[R] Environment Variables in R Shiny-Server Container: Problem and Solutions

Sat, 15 Aug 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/08/15/r-environment-variables-in-r-shiny-server-container/ -

When dockerizing an R Shiny application hosted via Shiny Server (built from shiny server docker image https://hub.docker.com/r/rocker/shiny), a common issue developers face is that environment variables set via ENV instructions in the Dockerfile (or passed at runtime via docker run -e) are completely missing inside the R Shiny app.

For example, if you set the following environment variable in your Dockerfile:

`1`	`ENV SHOULD_IN_SHINY="From dockerfile"`

When your app launches and runs Sys.getenv("SHOULD_IN_SHINY"), it returns an empty string "" instead of "From dockerfile". This is not a problem with Docker itself, but rather a consequence of how Shiny Server spawns R worker processes.

In this post, we will look into the root cause behind this behavior in Shiny Server and demonstrate the two recommended solutions to correctly expose environment variables to your R Shiny workers.

The Root Cause: How Shiny Server Spawns R Processes

The reason environment variables do not carry over to your R session lies in how Shiny Server executes R worker processes inside the container.

Shiny Server runs as a system service (typically as root or shiny). When launching an app instance, it re-executes R as the shiny unprivileged user using su. Specifically, the execution call combines two mutually exclusive flags:

`1`	`su shiny --login --preserve-environment -c "... R ..."`

Let’s break down what these flags request from su:

--login (-l): Starts a login shell. This intentionally resets the environment to a minimal whitelist (HOME, PATH, USER, TERM, etc.) and sources system startup profiles (/etc/profile, ~/.profile).
--preserve-environment (-p): Explicitly asks su to keep the current environment inherited from the caller (which includes Docker’s ENV variables).

Because Linux’s su utility cannot honor both conflicting behaviors, it chooses --login and prints a warning:

`1`	`su: ignoring --preserve-environment, it's mutually exclusive with --login`

Note: This warning is emitted by Shiny Server’s underlying process execution call, not by the R app itself. Attempting to suppress or patch it requires modifying and rebuilding Shiny Server C++ code, which is rarely practical.

Because the login shell wins, all custom environment variables passed to the container via ENV or docker run are wiped before R ever starts.

Solutions

Since patching Shiny Server is unnecessary, we can utilize the natural extension points provided by the login shell or R itself.

Solution 1: Use `~/.profile` (Recommended for User-Level Shell Vars)

Since --login causes the shell to source ~/.profile for the shiny user, we can write our environment variables to /home/shiny/.profile during the Docker build phase.

In your Dockerfile:

1
2

# Append environment variable to the shiny user's profile
RUN echo 'export SHOULD_IN_SHINY="From dockerfile"' >> /home/shiny/.profile

When Shiny Server executes su shiny --login ..., the login shell will read /home/shiny/.profile and load SHOULD_IN_SHINY into the environment right before starting the R process.

Solution 2: Use `~/.Renviron` (Recommended for R-Specific Configs)

Alternatively, R automatically inspects and loads ~/.Renviron on startup, right after the shell environment is initialized.

~/.Renviron is purpose-built for R:

Scoped strictly to R processes.
Does not use shell export keywords or $ variable expansions.
Uses simple KEY=value key-value pairs.

In your Dockerfile, set up /home/shiny/.Renviron:

1
2
3

# Set up .Renviron for the shiny user
RUN echo 'SHOULD_IN_SHINY="From dockerfile"' >> /home/shiny/.Renviron \
    && chown shiny:shiny /home/shiny/.Renviron

In your Shiny app (app.R or server.R), you can access it reliably:

1
2

should_in_shiny <- Sys.getenv("SHOULD_IN_SHINY")
# Returns: "From dockerfile"

Summary

The Problem: Shiny Server calls su shiny --login --preserve-environment, causing su to discard inherited environment variables (such as Docker ENV) in favor of a clean login shell.
Solution 1 (~/.profile): Append export KEY="value" to /home/shiny/.profile in your Dockerfile.
Solution 2 (~/.Renviron): Append KEY="value" to /home/shiny/.Renviron in your Dockerfile.

Both approaches integrate seamlessly with Docker builds and ensure your Shiny application receives all required configuration variables cleanly.

- https://fortune9.netlify.app/2026/08/15/r-environment-variables-in-r-shiny-server-container/ -

[R] How to Position the Legend Inside a Plot in ggplot2

Sat, 30 May 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/05/30/r-position-legend-inside-plot/ -

By default, ggplot2 places the legend outside the plot area (usually on the right). However, sometimes you may want to move the legend inside the plot to save space or improve the layout. This post explores how to achieve this using theme() parameters.

Example 1: Basic Usage of `legend.position`

The simplest way to move a legend inside the plot is by providing a numeric vector of length two to the legend.position argument in theme(). These coordinates represent the relative position within the plot panel, ranging from 0 to 1. Check the section on “Key Positioning Controls” at the end for a detailed explanation of the coordinate system.

library(ggplot2)

ggplot(mtcars, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  theme_bw() +
  theme(legend.position = c(0.8, 0.8))

Example 2: Fine-Tuning with Justification and Background

When you place a legend inside, you often need to adjust which part of the legend box aligns with your coordinates and handle the background if it obscures data.

legend.justification: Controls the anchor point of the legend box. For example, c("right", "top") means the top-right corner of the legend box will be placed at the specified coordinates.
legend.background: Use element_blank() to make the background transparent.

ggplot(mtcars, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  theme_bw() +
  theme(
    legend.position = c(1, 1),
    legend.justification = c("right", "top"),
    legend.background = element_blank()
  )

Example 3: Positioning in Faceted Plots

Moving the legend inside a faceted plot works similarly: the whole figure is considered as one plot for the coordinate system. You can use the coordinates to place it within one of the empty spaces or over a specific panel. In the following example, the legend is placed in the bottom center of the plot, and a background is added to improve readability:

ggplot(mtcars, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  facet_wrap(~am) +
  theme_bw() +
  theme(
    legend.position = c(0.5, 0.2),
    legend.background = element_rect(fill = "white", color = "grey80")
  )

Example 4: The “Empty Space” Trick for Faceted Plots

If you have a panel which doesn’t have any data, and then it is the perfect spot to place legend. To show this, the facet variable carb has only 3 values, and we will make a 2x2 facet grid. We will also remove the background and border of the legend. The following example shows this:

# Use 3 categories to leave the 4th spot in a 2x2 grid empty
mtcars_subset <- mtcars[mtcars$carb %in% c(1, 2, 4), ]

ggplot(mtcars_subset, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  facet_wrap(~carb, nrow = 2, ncol = 2) +
  theme_bw() +
  theme(
    # Coordinates c(0.75, 0.25) target the center of the empty bottom-right area
    legend.position = c(0.75, 0.25),
    legend.background = element_blank(),
    legend.justification = "center"
  )

Key Positioning Controls

To master legend positioning, keep these three controls in mind:

Coordinate System: The coordinates c(X, Y) represent a relative scale from 0 to 1 across the plot panel.
- c(0, 0): Bottom-left corner
- c(1, 1): Top-right corner
- c(0.5, 0.5): Center of the plot
Anchor Point (legend.justification): Use this to control which part of the legend box aligns with your coordinates. For example, c("right", "top") ensures the top-right corner of the legend box sits exactly at your target coordinate.
Background Removal: If your legend blocks data points, clear the legend box background using legend.background = element_blank(). Alternatively, use element_rect() to give it a semi-transparent or styled background.

Happy Programming!

- https://fortune9.netlify.app/2026/05/30/r-position-legend-inside-plot/ -

[R] How to use ggpattern to add patterns to ggplot2 plots

Fri, 22 May 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/05/22/r-how-to-use-ggpattern/ -

Adding patterns to plots is a great way to improve accessibility (making plots colorblind-friendly) and to add an extra dimension of information. The ggpattern package provides a rich set of tools to achieve this in ggplot2.

Basic Example with mtcars

Let’s start with a barplot using the mtcars dataset. We will map cyl to the x-axis, mpg to the y-axis, use gear for the fill color, and am for the pattern.

# Prepare data
df <- mtcars %>%
  mutate(
    cyl = factor(cyl),
    gear = factor(gear),
    am = factor(am, labels = c("Automatic", "Manual"))
  )

# Create barplot
ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    color = "black",
    pattern_fill = "black",
    pattern_spacing = 0.02,
    pattern_key_scale_factor = 1.5
  ) +
  scale_pattern_manual(values = c("stripe", "crosshatch")) +
  labs(
    title = "MPG by Cylinders, Gear, and Transmission",
    subtitle = "Patterns representing transmission type",
    x = "Cylinders",
    y = "Miles Per Gallon (MPG)",
    fill = "Gears",
    pattern = "Transmission"
  ) +
  theme_minimal()

Exploring Key Parameters

The ggpattern package allows for fine-grained control over how patterns are rendered. Here are some of the most important parameters:

1. pattern_key_scale_factor

This parameter scales the pattern density specifically in the legend. Without it, patterns in the legend can often be hard to see. Reduce the value will make it easier fit into the legend keys.

p_base <- ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    color = "black",
    pattern_spacing = 0.02
  ) +
  theme_minimal() +
  labs(title = "Default vs Scaled Legend")

# Default legend
p1 <- p_base + labs(subtitle = "Default (key_scale_factor = 1)")

# Scaled legend
p2 <- p_base + 
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    color = "black",
    pattern_spacing = 0.02,
    pattern_key_scale_factor = 0.5
  ) +
  labs(subtitle = "Scaled (key_scale_factor = 0.5)")

p1

p2

2. pattern_spacing and pattern_density

pattern_spacing controls the distance between pattern elements (lower = denser), while pattern_density controls the coverage (higher = denser).

# Spacing effect
ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    pattern_spacing = 0.2, # Wider spacing
    pattern_key_scale_factor = 1.5
  ) +
  labs(title = "Effect of pattern_spacing = 0.5 (Sparser)") +
  theme_minimal()

# Density effect
ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    pattern_density = 0.8, # Higher density
    pattern_key_scale_factor = 1.5
  ) +
  labs(title = "Effect of pattern_density = 0.8 (Denser)") +
  theme_minimal()

3. pattern_fill

pattern_fill sets the color of the pattern elements themselves.

ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    pattern_fill = "white", # White pattern lines
    pattern_density = 0.5, # make it bigger so that the color is easier to see
    pattern_spacing = 0.02,
    pattern_key_scale_factor = 1.5
  ) +
  labs(title = "Effect of pattern_fill = 'white'") +
  theme_minimal()

4. pattern_shape

For geometric patterns like regular_polygon, pattern_shape controls the number of sides.

ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern_shape=gear),
    pattern = "regular_polygon",
    stat = "identity",
    position = "dodge",
    pattern_size = 0.5, # stroke line width
    pattern_density = 0.5, # increase the shape size
    pattern_spacing = 0.03,
    pattern_key_scale_factor = 1.5
  ) +
  scale_pattern_shape_manual(values = c("3"="circle", "4"="convex6", "5"="square")) + # manually set shapes
  labs(title = "Effect of mapping pattern_shape to gear") +
  theme_minimal()

Troubleshooting

If you encounter issues installing or loading ggpattern on Linux, you may need to install the following system dependencies:

sudo apt-get install libudunits2-dev
sudo apt install libproj22
sudo apt-get install libgdal-dev

- https://fortune9.netlify.app/2026/05/22/r-how-to-use-ggpattern/ -

[R] How to change legend key size in ggplot2

Mon, 27 Apr 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/04/27/r-how-to-change-legend-key-size-in-ggplot2/ -

In ggplot2, the legend keys (the symbols next to the labels) usually inherit their size and appearance from the layers in the plot. For example, if you have a scatter plot with very small points, the legend keys will also be very small, making them hard to see.

To fix this without changing the size of the points in the actual plot, you can use the override.aes argument within guide_legend().

The Problem: Tiny Legend Keys

When plotting many data points, we often decrease the size to avoid overplotting. However, this makes the legend keys tiny:

library(ggplot2)

p <- ggplot(iris, aes(Sepal.Length, Sepal.Width, color = Species)) +
  geom_point(size = 0.5) + 
  theme_minimal() +
  labs(title = "Tiny Legend Keys")

p

The Solution: Using `override.aes`

By using guides(), we can “override” the aesthetics of the legend. This allows us to keep the small points in the plot while making the legend keys large and clear.

If your legend is for the color aesthetic:

p_fixed <- p + 
  guides(color = guide_legend(override.aes = list(size = 5))) +
  labs(title = "Fixed Legend Keys (Size 5)")

p_fixed

If you were using fill (e.g., in a bar plot or boxplot), you would simply change color to fill:

guides(fill = guide_legend(override.aes = list(size = 5)))

Adjusting Legend Text and Title Size

Note that override.aes only affects the symbols inside the legend. To change the size of the labels or the legend title, you should use the theme() function:

p_fixed + 
  theme(
    legend.text = element_text(size = 12),   # Legend labels
    legend.title = element_text(size = 14, face = "bold") # Legend title
  )

Summary

Use guides(color = guide_legend(override.aes = list(size = ...))) to change the symbol size.
Use theme(legend.text = element_text(size = ...)) to change the text size.

- https://fortune9.netlify.app/2026/04/27/r-how-to-change-legend-key-size-in-ggplot2/ -

Single vs Double Quotes in Command Line and R

Sun, 26 Apr 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/04/26/single-vs-double-quotes-in-command-line-and-r/ -

When feeding a program with command line arguments, single quotes and double quotes make a significant difference.

The Shell Rule

Single quotes (') do not allow escaping any characters; the contents are treated literally. Double quotes ("), however, allow for character escaping and variable expansion.

You can test this using the printf command, which prints each argument it receives on a new line:

# Using single quotes: the backslash is literal
printf "%s\n" '\+hello'
# Output: \+hello

# Using double quotes: the shell escapes the double backslash
printf "%s\n" "\\+hello"
# Output: \+hello

As you can see, both commands result in the same string \+hello being passed to the program. The former is read exactly as written, while in the latter, the shell interprets the double backslash as a single literal backslash before passing it along.

The R Console Rule

In R, when you work directly in the R console, you must deal with the language’s own string literal syntax.

Most programming languages, including R, use the backslash (\) as an escape character. So when you type it, it will be explained as an escape character immediately. If you type "\." in R console, it will be interpreted in the console first before being passed to R itself; the interpreter will likely tell you there is no such escape sequence as \., and it won’t actually put a backslash in the resulting string.

To place a literal backslash in a string in R, you have to use a double backslash (\\). This tells R that you don’t want the second backslash to be an escape character when typing in the console, but rather that you want a single literal backslash character in the string to be passed to R.

For instance, when defining a regular expression:

`1`	`myregexp = "^planet\\.name$"`

This creates a string containing the text ^planet\.name$ (note the single backslash). This string is then passed to a regex function, which interprets the \. sequence as “a literal dot” rather than the regex wildcard for “any character.”

This rule also applies to the scenario where you type the escaping characters in R scripts.

For more depth on this, check out this Reddit discussion on double slashes in regex.

Command Line Arguments for R Scripts

Crucially, if you are running an R script and feeding it parameters from the command line (e.g., via Rscript), the above the shell rule apply instead of the internal R console rules for those initial arguments.

To see this in action, create a file named test_args.R:

# test_args.R
args <- commandArgs(trailingOnly = TRUE)
if (length(args) > 0) {
    cat("Argument received by R:", args[1], "\n")
}

Now run it from your terminal:

# Test with single quotes
Rscript test_args.R '\+hello'
# Output: Argument received by R: \+hello

# Test with double quotes
Rscript test_args.R "\\+hello"
# Output: Argument received by R: \+hello

If you want to input a regular expression to an R script via the command line for use in a function like sub(), you should use these shell quoting rules. The string \+hello received by R will correctly match the literal string +hello in your R code.

- https://fortune9.netlify.app/2026/04/26/single-vs-double-quotes-in-command-line-and-r/ -

[R] How to modify the theme used by blogdown?

Sat, 18 Apr 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/04/18/r-how-to-modify-the-theme-used-by-blogdown/ -

My website is built using blogdown and published on Netlify via CI/CD. Recently, I updated my Hugo version from 0.92 to 0.154.2. Unfortunately, this update broke the deployment pipeline due to an incompatibility in one of the files within the diary theme.

When your Hugo theme is no longer compatible with a newer Hugo version or if you simply want to customize its behavior, there are two primary ways to handle it.

Solution 1: Overriding Theme Files Locally

The simplest way to modify a theme without changing the theme’s source code is to take advantage of Hugo’s lookup order. Hugo prioritizes files in your root project folder over those in the themes/ directory.

Step-by-step instructions:

Identify the file in the theme that needs modification (e.g., themes/diary/layouts/_default/single.html).
Create a corresponding directory structure under your root layouts/ folder if it doesn’t exist.

Copy the file from the theme folder to your root folder:

1
2

mkdir -p layouts/_default
cp themes/diary/layouts/_default/single.html layouts/_default/single.html

Modify layouts/_default/single.html as needed. Hugo will now use your local version instead of the one in the theme.

Solution 2: Forking the Theme Repository

If you have many changes or want to manage the theme’s source code directly, forking the theme is a better long-term solution. Since blogdown (and Hugo) typically manages themes as Git submodules, you’ll need to update the submodule to point to your fork.

Step-by-step instructions:

Fork the repository: Go to the original theme repo hugo-theme-diary and fork it to your own GitHub account.
Clone your blog repo (if not already local): https://github.com/fortune9/blogdown-everyday.git.

Update the submodule URL: Update your submodule to point to your forked URL:

`1`	`git submodule set-url themes/diary https://github.com/YOUR_USERNAME/hugo-theme-diary.git`

Sync and Update:

1
2

git submodule sync
git submodule update --init --recursive

Apply your changes: Go into the themes/diary directory, make your fixes, commit, and push them to your fork.

Commit the submodule change in your blog repo: Back in the root of your blog repo, commit the change to the submodule pointer:

1
2
3

git add themes/diary
git commit -m "Switch diary theme to personal fork and apply Hugo compatibility fixes"
git push

By following either of these methods, you can ensure your blog remains compatible with the latest Hugo versions while maintaining your custom styles and fixes.

- https://fortune9.netlify.app/2026/04/18/r-how-to-modify-the-theme-used-by-blogdown/ -

[R] Setting Up an Interactive R Shiny Plotting App

Wed, 08 Oct 2025 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2025/10/08/r-setting-up-an-interactive-r-shiny-plotting-app/ -

I have an ieda of creating a shiny app to create all kinds of plots interactively, so that users can choose their color, symbols, etc, which is very useful for data exploration and make a publication-quality figure.

Today, I make it and published it at https://fortune9.shinyapps.io/interactive_plot/. The source code is at github https://github.com/fortune9/interactive_plot.

This guide focuses on the infrastructure setup for creating and deploying an interactive plotting application using R Shiny. For detailed features and functionality, please refer to the README.md in the GitHub repository.

Overview

The application allows users to create customizable plots (scatter, bar, box) from both uploaded data and built-in R datasets, with extensive customization options and export capabilities. All source code is available at https://github.com/fortune9/interactive_plot.

Project Setup

Create the project structure:

interactive_plot/
├── app.R
├── ui.R
├── server.R
├── www/
└── data/

Install required packages:

`1`	`install.packages(c("shiny", "ggplot2", "tidyverse"))`

Create the main app file (app.R):

library(shiny)
library(ggplot2)
library(tidyverse)

source("ui.R")
source("server.R")

shinyApp(ui = ui, server = server)

Deployment

1. Prepare for Deployment

Install the rsconnect package:

`1`	`install.packages("rsconnect")`

Create a shinyapps.io account at https://www.shinyapps.io
Get your account tokens from:
- Dashboard → Account → Tokens
Set up authentication in R:

rsconnect::setAccountInfo(
  name='your-account-name',
  token='your-token',
  secret='your-secret'
)

2. Deploy Using GitHub Actions

Add GitHub Secrets:
- SHINYAPPS_USER
- SHINYAPPS_TOKEN
- SHINYAPPS_SECRET
Create GitHub Actions workflow (.github/workflows/deploy.yml):

name: Deploy to shinyapps.io
on:
  push:
    branches:
      - main
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: r-lib/actions/setup-r@v2
      - name: Deploy to shinyapps.io
        run: |
          Rscript -e 'install.packages(c("shiny", "rsconnect"))'
          Rscript -e 'rsconnect::deployApp()'          
        env:
          SHINYAPPS_USER: ${{ secrets.SHINYAPPS_USER }}
          SHINYAPPS_TOKEN: ${{ secrets.SHINYAPPS_TOKEN }}
          SHINYAPPS_SECRET: ${{ secrets.SHINYAPPS_SECRET }}

Development Tips

Local Testing
- Run the app locally using shiny::runApp()
- Test with different browsers and screen sizes
- Verify all features before deployment
Deployment Checks
- Ensure all required packages are listed in the deployment workflow
- Test deployment locally using rsconnect before pushing to GitHub
- Monitor GitHub Actions logs for deployment issues
Maintenance
- Keep your shinyapps.io tokens secure
- Update package versions regularly
- Monitor app usage on shinyapps.io dashboard

Conclusion

This guide covers the essential setup and deployment steps for your Shiny app. For implementation details and features, refer to the source code and documentation in the GitHub repository at https://github.com/fortune9/interactive_plot.

For questions or improvements, please open an issue in the GitHub repository.

Do you know? Actually most of the code was written using Github Copilot, to which I feed the file development plan.md to start. Very cool 😄!

- https://fortune9.netlify.app/2025/10/08/r-setting-up-an-interactive-r-shiny-plotting-app/ -

[R] Use new_scale_xxx() function to add the same scale type in different ggplot layers

Sat, 10 May 2025 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2025/05/10/r-use-new-scale-xxx-function-to-add-the-same-scale-type-in-different-ggplot-layers/ -

In one ggplot figure, normally you can only use one scale for each aesthetic mapping. For example, if you use scale_color_manual() to set the color scale for a layer, you cannot use another scale_color_manual() for another layer, or set the color scale more then once in the function aes(). However, you can use the new_scale_color() function from the ggnewscale package to add a new scale for the same aesthetic mapping in different layers.

In this post, I will showcase how to use the new_scale_color() function to add two different color scales in a ggplot figure. The first scale will be for a discrete variable (e.g., number of cylinders), and the second scale will be for a continuous variable (e.g., density level).

Load packages first.

library(ggplot2)
library(ggnewscale)

Use the mtcars dataset for the example

data(mtcars)

Create a plot with two color scales: 1. Points colored by ‘cyl’ (discrete) 2. Density contours colored by density level (continuous)

First, let’s make a scatter plot of mpg vs wt with points colored by the number of cylinders (cyl). We will use the geom_point() function for this layer.

plt <- ggplot(mtcars, aes(x = wt, y = mpg)) +
  # First layer: Scatter plot colored by cylinders (discrete variable)
  geom_point(aes(color = factor(cyl)), size = 3) +  
  scale_color_discrete(name = "Cylinders")

plt

Set new scale for the next layer

# Reset the color scale for the next layer
plt <- plt + new_scale_color()

Add a second layer: Density contours colored by density level (continuous variable)

plt <- plt +
  geom_density_2d(aes(color = after_stat(level))) +  
  scale_color_viridis_c(name = "Density Level", option = "magma") +
  
  # Add labels and theme
  labs(title = "Dual Color Scales with new_scale_color()",
       x = "Weight (1000 lbs)",
       y = "Miles per Gallon") +
  theme_minimal()

plt

Here I demonstrated how to use the new_scale_color() function from the ggnewscale package, one can also use new_scale_fill() for fill aesthetics. For other aesthetics, such as size, shape, etc., you can call new_scale("size"), new_scale("shape"), etc. to add new scales.

To learn more, check the webpage https://eliocamp.github.io/ggnewscale/

Happy programming 😃

- https://fortune9.netlify.app/2025/05/10/r-use-new-scale-xxx-function-to-add-the-same-scale-type-in-different-ggplot-layers/ -

[R] How to create errorbars with overlaid points using ggplot

Sat, 26 Apr 2025 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2025/04/26/r-how-to-create-an-error-barplot-with-overlaid-points-using-ggplot/ -

library(ggplot2)
library(dplyr)

Sometimes you may want to create a plot with the following features:

a point to indicate the mean of a group
error bars to indicate the standard deviation of the group
and each group may have subgroups, which are represented by different colors.

In this post, I will show you how to create such a plot using the ggplot2 package in R.

We will use the builtin mtcars dataset as an example. And we need to compute the following variables for later use:

The mean mpg for each group of cyl (number of cylinders) and gear`` (number of gears), herecylis the main group andgear` is the subgroup.

# Load the mtcars dataset
data(mtcars)
# Compute the mean and standard deviation of mpg for each group
mtcars_summary <- mtcars %>%
  group_by(cyl, gear) %>%
  summarise(mean_mpg = mean(mpg), sd_mpg = sd(mpg)) %>%
  ungroup()
# replace the NA values in sd_mpg with 1
mtcars_summary$sd_mpg[is.na(mtcars_summary$sd_mpg)] <- 1
# convert group variables into factors
mtcars_summary$cyl <- factor(mtcars_summary$cyl)
mtcars_summary$gear <- factor(mtcars_summary$gear)

Create the plot - first try

Now we can create the plot using ggplot2. We will use the geom_point() function to create the points, and the geom_errorbar() function to create the error bars. We will also use the aes() function to specify the aesthetics of the plot.

# Create the plot
plt <- ggplot(mtcars_summary, aes(x = cyl, y = mean_mpg, color = gear)) +
  geom_point(size = 3) + # add points
  geom_errorbar(aes(ymin = mean_mpg - sd_mpg, ymax = mean_mpg + sd_mpg), width = 0.2) + # add error bars
  labs(x = "Number of Cylinders", y = "Mean MPG", color = "Number of Gears") + # add labels
  theme_minimal() + # use a minimal theme
  theme(legend.position = "top") # move the legend to the top
plt

Well, it is working, but the problem is that the error bars and points are all aligned at the same position of x-axis. This is not what we want. We want the subgroups to be separated by a small distance.

Create the plot - second try

To separate the subgroups, we can use the position_dodge() function. This function will move the points and error bars to the left and right, so that they are not overlapping.

pd <- position_dodge(width = 0.5)
# Create the plot with position_dodge
plt <- ggplot(mtcars_summary, aes(x = cyl, y = mean_mpg, color = gear)) +
  geom_point(size = 3, position = pd) + # add points with position_dodge
  geom_errorbar(aes(ymin = mean_mpg - sd_mpg, ymax = mean_mpg + sd_mpg), width = 0.2, position = pd) + # add error bars with position_dodge
  labs(x = "Number of Cylinders", y = "Mean MPG", color = "Number of Gears") + # add labels
  theme_minimal() + # use a minimal theme
  theme(legend.position = "top") # move the legend to the top
plt

Cool. Isn’t it?

The only difference is that we added the position = pd argument to the geom_point() and geom_errorbar() functions. This tells ggplot2 to use the position_dodge() function to separate the subgroups.

Conclusion

In this post, we learned how to create a plot with error bars and overlaid points using the ggplot2 package in R. We also learned how to separate the subgroups using the position_dodge() function.

If you want to learn more about the function position_dodge(), you can check an excellent post here.

Happy programming! 😃

- https://fortune9.netlify.app/2025/04/26/r-how-to-create-an-error-barplot-with-overlaid-points-using-ggplot/ -

R on Zhenguo Zhang's Blog

[R] Understanding position_dodge() and position_dodge2() in ggplot2

Definition of Terms

1. The width Parameter in position_dodge()

What does width control?

Interaction between geom_bar(width) and position_dodge(width)

2. Differences Between position_dodge2() and position_dodge()

Key Differences:

Demo: width Has No Effect in position_dodge2()

Creating Spacing with padding and Reversing Order with reverse

3. Handling Missing Elements with preserve = "single"

Summary

[R] Environment Variables in R Shiny-Server Container: Problem and Solutions

The Root Cause: How Shiny Server Spawns R Processes

Solutions

Solution 1: Use ~/.profile (Recommended for User-Level Shell Vars)

Solution 2: Use ~/.Renviron (Recommended for R-Specific Configs)

Summary

[R] How to Position the Legend Inside a Plot in ggplot2

Example 1: Basic Usage of legend.position

Example 2: Fine-Tuning with Justification and Background

Example 3: Positioning in Faceted Plots

Example 4: The “Empty Space” Trick for Faceted Plots

Key Positioning Controls

[R] How to use ggpattern to add patterns to ggplot2 plots

Basic Example with mtcars

Exploring Key Parameters

1. pattern_key_scale_factor

2. pattern_spacing and pattern_density

3. pattern_fill

4. pattern_shape

Troubleshooting

[R] How to change legend key size in ggplot2

The Problem: Tiny Legend Keys

The Solution: Using override.aes

Adjusting Legend Text and Title Size

Summary

Single vs Double Quotes in Command Line and R

The Shell Rule

The R Console Rule

Command Line Arguments for R Scripts

[R] How to modify the theme used by blogdown?

Solution 1: Overriding Theme Files Locally

Step-by-step instructions:

Solution 2: Forking the Theme Repository

Step-by-step instructions:

[R] Setting Up an Interactive R Shiny Plotting App

Overview

Project Setup

Deployment

1. Prepare for Deployment

2. Deploy Using GitHub Actions

Development Tips

Conclusion

[R] Use new_scale_xxx() function to add the same scale type in different ggplot layers

[R] How to create errorbars with overlaid points using ggplot

Create the plot - first try

Create the plot - second try

Conclusion

1. The `width` Parameter in `position_dodge()`

What does `width` control?

Interaction between `geom_bar(width)` and `position_dodge(width)`

2. Differences Between `position_dodge2()` and `position_dodge()`

Demo: `width` Has No Effect in `position_dodge2()`

Creating Spacing with `padding` and Reversing Order with `reverse`

3. Handling Missing Elements with `preserve = "single"`

Solution 1: Use `~/.profile` (Recommended for User-Level Shell Vars)

Solution 2: Use `~/.Renviron` (Recommended for R-Specific Configs)

Example 1: Basic Usage of `legend.position`

The Solution: Using `override.aes`