# 1. Exploring Windows Shell Environment Integration and Path Conversion

Imagine we wanted a context menu where we could launch WSL by right-clicking on the folder background, and have the working directory of WSL be the same directory as the folder that we are in. Furthermore, imagine we wanted to use ConEmu as our terminal emulator rather than the default one for Ubuntu.exe. We can do this with the following registry script:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\wslhere]
@="WSL Here"
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Directory\Background\shell\wslhere\command]
@="\"C:\\Program Files\\ConEmu\\ConEmu64.exe\" -cmd cmd /c cd /d \"%V\" && ubuntu.exe run \"bash -ic 'echo This is ConEmu; echo Shell: $SHELL; bash'\""

this might be one way we want to integrate different shell environments within windows but how did we get here and what else did we learn in the process?

Windows has many shells that allow using linux tools within windows. Knowing the differences between these tools, how to communicate between them and how to better integrate them withing the windows environment will help One get the most from these tools. This document is a short summary of what I learned in the exploration of these concepts with Claude AI and Copilot.

# 2. Table of Contents
1. Exploring Windows Shell Environment Integration and Path Conversion
2. Understanding Paths in Different Shells
- 2.1 Root Directory and C Drive in Cygwin
- 2.2 Root Directory and C Drive in Ubuntu
3. The Cygwin Package "c-here" (AKA bash here)
- 3.1 Calling ubuntu-here.sh in Cygwin
- 3.1.1 Changing Line Endings
- 3.2 Converting Paths Within WSL Using Cygwin
4. Using Windows Shortcuts
- 4.1 Variables in Target Field
- 4.2 Using the "Start in" Field as Workaround
- 4.2.1 Pros and Cons of the Shortcut Approach
5. Moving onto Registry Scripts
- 5.1 Another Example "cmd here"
- 5.2 First Registry Script Using Cygwin
- 5.2.1 Saving Registry Scripts and Housekeeping
- 5.3 Removing Cygwin Dependencies
9. Process Hierarchies and Terminal Considerations
- 6.1 Process Hierarchy Tradeoffs
- 6.2 Terminal Considerations
10. Method Considerations
- 7.1 Project Specific Use Cases
- 7.2 Local File Approaches
11. Future Work
- 8.1 Custom Environment for Specific Projects
- 8.2 Launching Other Graphical Applications
12. Conclusion

Here's a draft of the prerequisites section, which I would place right after the introduction but before Section 2:

# 3. Prerequisites and Required Software

## 3.1 Essential Software
- Windows 10 or later
- Windows Subsystem for Linux (WSL)
- Ubuntu distribution installed through WSL

## 3.2 Optional Software (For Specific Sections)

### 3.2.1 For Cygwin-based approaches (Sections 5 & 7.2):
- Cygwin installation
- Base installation
- chere package (for "Bash Here" functionality)
- dos2unix package (for line ending conversion)

### 3.2.2 For launching shells in the ConEMU emulator (Section 8)

- ConEmu terminal emulator
- Download from: https://conemu.github.io/

### 3.2.3 For Future Work (Section 11.2):
- WSLg
- Included in recent Windows builds
- Required only for Linux GUI applications

### 3.2.4 Recommended Text Editors
- Notepad++ or similar text editor with EOL conversion capability
- Useful for editing scripts and registry files
- Helps manage line endings in shell scripts

## 3.3 Installation Notes
- WSL can be installed through PowerShell:

  wsl --install

- Registry modifications require administrator privileges
- ConEmu installation location is assumed to be:

  C:\Program Files\ConEmu\ConEmu64.exe

Adjust paths in scripts if installed elsewhere

# 4. Understanding paths in different shells

The two most prominent linux shell environments on windows are WSL and cygwin. Knowing how paths are represented in these linux environments in comparison to cmd.exe and powershell will help one better integrate these tools.

## 4.1 Root director and C drive in cygwin

For instance, one might have cygwin installed at:

C:\cygwin64

This is the root directory of cygwin and is represent in the cygwin shell as

\

## 4.2 Root director and C drive in ubuntu
Simmilarly the root directory in WSL ubuntu might located be:

\\wsl.localhost\Ubuntu

and in this file system the path to the C drive is:

/mnt/c

Note that the above path to the home directory in WSL may be aprivated as follows:

\\$wsl\Ubuntu

# 5 The cygwin package, "```c-here```" (AKA bash here)
The first inspiration for the "```WSL here```" script, is the ```c-here``` script, that allows one to open a ```cygwin``` bash terminal by right clicking in the background of the folder.

Intially, Claude.AI suggested that one challenge of crearint a similar script for WSL would be path conversion.

## 5.1 Calling ubuntu-here.sh in cygwing

I knew that ```cygwin``` had tools to convert windows paths to linux paths (i.e. ```cygpath```), so with the help of Claude and Copilot (mostly for the -m option) we came up with the following script:

#!/bin/bash
# wsl-here.sh

# Log for debugging (optional)
echo "Script started at $(date)"

# Get the Windows path from context menu
win_path="$1"
echo "Received Windows path: $win_path"

# Convert to Cygwin path
cyg_path=$(cygpath -m "$win_path")
echo "Converted to Cygwin path: $cyg_path"

# Remove 'C:' from the beginning of the path
cyg_path_without_drive="${cyg_path#C:}"

# Convert to WSL path by adjusting the base
wsl_path="/mnt/c${cyg_path_without_drive//\\//}"

echo "Converted to WSL path: $wsl_path"

# Launch WSL with the converted path
wsl.exe -d Ubuntu --cd "$wsl_path" -- /bin/bash

The advantage of this approach is that you can leverage the existing cygwin tool (i.e. c-here), and once you have the cygwin shell simply type,

ubuntu-here.sh

once, we've launched a cygwin shell in the desired directory. For this to work this script needs to be withing your search path. Within the cygwin file system representation we might put the script at:

\usr\local\bin\ubuntu-here.sh

and withing the ```cygwin``` shell we can make it exutable as follows::

chmod +x \usr\local\bin\ubuntu-here.sh

Making it excutable isn't sufficient though, we aslo need to make sure the line endings of the script are unix style.

### 5.1.1 Changine Line Endings

The line endings can be changed in notepad++, under edit->"EOL Conversion" or alternatively, one can use the following command:

dos2unix \usr\local\bin\ubuntu-here.sh

which first must be installed. In debain/ubuntu:

sudo apt install dos2unix

In either case the line endings need to be changed to unix style.

## 5.2 Convertings paths within WSL using cygwin

Next, we wanted to be able to convert windows paths within WSL, so that we could have a WSL instance that didn't depend on cygwin as a parent process. We still used cygwin for path conversion because we know how to do this and also becasue it let's us experiment with interoperating between the two linux shell environments.

The script we came up with (i.e. wsl-path-test.sh) first converts the path to WSL format than changes to that directory.

#!/bin/bash
# wsl-path-convert.sh

convert_windows_path() {
    local win_path="$1"
    local cyg_path=$(/mnt/c/cygwin64/bin/cygpath.exe -m "$win_path")
    echo "Converted to Cygwin path: $cyg_path" >&2  # Send to stderr so it doesn't get captured
    # Remove 'C:' from the beginning of the path
    local cyg_path_without_drive="${cyg_path#C:}"
    # Convert to WSL path by adjusting the base
    echo "/mnt/c${cyg_path_without_drive//\\//}"
}

windows_path="$1"
echo "Input Windows path: $windows_path"

# Check if it starts with one or two backslashes followed by wsl
if [[ $windows_path =~ ^\\+wsl ]]; then
    # Extract the part after Ubuntu
    wsl_path=${windows_path#*Ubuntu}
    # Clean up backslashes
    wsl_path=${wsl_path//\\//}
    echo "Detected WSL path, converted to: $wsl_path"
else
    wsl_path=$(convert_windows_path "$windows_path")
fi

cd "$wsl_path"
echo "Current location: $PWD"

# 6 Using Windows Shortcuts

Priot to attempting to create a registry script, we though that we could test the concepts via windows shotcuts. The thought here was that we could use the target field as a way to launch WSL, without depending on either cmd.exe or WSL.

## 6.1 We found that variables in the target field weren't expanded litterally.

For instance if we set target to the following:

Target: wsl.exe -d Ubuntu -- /home/s243a/.local/bin/wsl-path-test.sh "%CD%"

The %CD% (for current directory) variable wasn't expanded before passing the result to wsl.exe. Instead it was passed as a literal.

Simmillarly, if we set:

Target: ubuntu.exe run "bash -ic '/home/s243a/.local/bin/wsl-path-test.sh \"%V\"; bash'"

the %V variable wasn't expanded to the current directory.

## 6.2 We used the ```start in:``` field as a workround.

Wd did find though that the ```%CD%``` did expand to the current cirectory if we placed it in the "```start in:```" field so this was our final solution for the shortcuts:

Target: ubuntu.exe run "bash -ic 'bash'"
Start in: %CD%

On simply has to copy this short cut to the disired directory, and then double click on it to launch the shell in that directory.

### 6.2.1 Pros and Cons of the shortcut approch.

The downside is that if one ony wants to do this a few times then they might have to delete the shortcut afterwards. However, it is possible that one might want such a shortcut as a way of launching an environment for a project and possibly starting up some services at the same time.

For instance in a Ruby on Rails project we might want to start a redis server via WSL

# 7. Moving onto Registry Scripts

After getting the above methods to work, I asked Claude if we were ready to try and implement a registry script like, c-here for WSL here. Claude gave me the typical paranoid microsoft response:

> I think we need to understand more first. Before modifying the registry, we should:
>
> 1. Better understand why variables expand differently in different contexts
> 2. Study how chere works exactly (since it's a proven model)
> 3. Research Windows registry structure for context menu entries
> 4. Have a clear plan for safely testing and reverting changes
> Since changes to the registry can affect system stability, we should be very confident about:
>
> * Exact registry keys and values needed
> * How Windows processes these entries
> * Safe testing methodology
> * How to back out changes if needed
> Would you like to research any of these areas first before attempting registry modifications?

## 7.1. Another example ```cmd here```

After contemplating the standard warnings about editing the registry, I remembered that the "```cmd here```" registry script was rather simple and by learning from it we could get more conffidence to try a "```WSL here```" script. I presented Claude with the following code:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Directory\shell\cmdprompt]
@="@shell32.dll,-8506" "NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Directory\shell\cmdprompt\command]
@="cmd.exe /s /k pushd \"%V\""

[HKEY_CLASSES_ROOT\Directory\Background\shell\cmdprompt] @="@shell32.dll,-8506" "NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Directory\Background\shell\cmdprompt\command]
@="cmd.exe /s /k pushd \"%V\""

[HKEY_CLASSES_ROOT\Drive\shell\cmdprompt]
@="@shell32.dll,-8506" "NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Drive\shell\cmdprompt\command] @="cmd.exe /s /k pushd \"%V\""

https://www.winhelponline.com/blog/cmd-here-windows-10-context-menu-add/

Here was Claude's resposne:

> Thanks for sharing this! This registry setup is interesting because it shows:
>
> How to add context menu items for:
>
> 1. Regular directories
> Directory background
> Drive locations
>
>
> 2. The command structure:
> ```
> cmd.exe /s /k pushd "%V"
> ```
> /s : Strips quotes from command
> /k : Execute command and remain open
> pushd : Changes directory and remembers previous
> %V : Path variable that works in context menu
>
> This helps us understand:
>
> 1. Registry structure needed for context menus
> 2. How Windows handles path variables in different contexts
> 3. Proper command syntax for remaining in the directory
>
> This could be useful reference material when we're ready to try creating a "WSL Here" context menu. The structure would be similar, but we'd need to:
>
> 1. Use appropriate WSL commands
> 2. Handle path conversion
> 3. Ensure proper process management
>
> Would you like to add this to our documentation as reference material for future registry work?

The example script I gave claude had several keys. I asked Claude to explain each one:

> 1. \Directory\shell\
>
> * Right-clicking on a folder
> * @="@shell32.dll,-8506" references the menu text from shell32.dll
> * ```command``` subkey defines what happens when clicked
>
>
> 2. ```\Directory\Background\shell\```
>
> * Right-clicking empty space in a folder
> * Same settings as Directory but different context
>
>
> 3. ```\Drive\shell\```
>
> * Right-clicking on a drive letter
> * Allows launching cmd at drive root
>
>
>
> Each section has the same structure:
>
> * Parent key with display text and options
> * command subkey with the actual command to run

I decided to focus on the key with the property, "Right-clicking empty space in a folder" because I knew that one worked on my system, and I wasn't sure both whether the other ones worked on my system, and if the script I previously ran modified those other keys.

## 7.2 The first registry scripted we tried used cygwin to convert paths

Based on my suggestions,

for example
> **Propmt:**
> Remember from above the following worked in cmd:
>
> ```ubuntu.exe run "bash -ic '/home/s243a/.local/bin/wsl-path-test.sh \""%CD%"\"; bash'"```
>
> So maybe change it to:
>
> ```ubuntu.exe run "bash -ic '/home/s243a/.local/bin/wsl-path-test.sh \""%V"\"; bash'"```

Claude came up with the following script (``wsl-here_v1.reg``):

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\wslhere]
@="WSL Here"
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Directory\Background\shell\wslhere\command]
@="ubuntu.exe run \"bash -ic 'source /home/s243a/.local/bin/wsl-path-test.sh \"\"%V\"\"; bash'\""

I asked Claude, why the script modified two keys. Here was Claude's answer:

> ...
>
> 1. First key (`\shell\cmdprompt`):
> - Defines the menu item itself
> - @ is the default value, sets display text
> - "NoWorkingDirectory" is a separate value (empty in this case)
>
> 2. Second key (`\shell\cmdprompt\command`):
> - Subkey that defines what happens when clicked
> - @ is the default value, contains the command to run
>
> So each context menu item needs:
> 1. A key for the menu entry and its properties
> 2. A command subkey for what to execute
>
> The double lines occur when a key has multiple values:
> - @ for default value
> - Additional named values (like "NoWorkingDirectory")
> ...

### 7.2.1 Saving Registry Scripts and other Housekeaping

Since the above script depends on cygwin, I recommend waiting befor trying to run the script utill we present the version, which does not depend on cygwin.

That said, if you insist on running the script. Save it with the .reg extension. The script must contain the header line, "Windows Registry Editor Version 5.00"

I asked claude whey version 5.00 was chosen and here is Claude's answer:

> Windows Registry Editor Version 5.00' is standard for Windows 10 - it's been the same since Windows 2000. This version number doesn't actually change with different Windows versions. Here's a brief history:
>
> * Version 4.00: Windows 95/98
> * Version 5.00: Windows 2000 and later (including Windows 10/11)
>
> So for any modern Windows system, including Windows 10, you'll use:

Claude also said that it is good practice to have a removal script (```remove-wsl-here.reg```):

Windows Registry Editor Version 5.00

[-HKEY_CLASSES_ROOT\Directory\Background\shell\wslhere]

this first approach worked but it was depend on the script, wsl-path-test.sh (full script above), which called cygwin go convert the paths.

I asked Claude where these files should be saved and here is the answer:

> While there's no official standard location for registry scripts, common practices include:
>
> 1. User-specific locations:
> ```
> %USERPROFILE%\Documents\WindowsCustomization\Registry
> %USERPROFILE%\Documents\RegistryScripts
> ```
>
> 2. System administration locations:
> ```
> C:\Windows\System32\GroupPolicy\Registry
> C:\ProgramData\RegistryScripts
> ```
>
> 3. Application-specific locations:
> ```
> C:\Program Files\YourApp\RegistryScripts
> ```
>
> For personal use, creating a folder in your Documents directory makes the most sense:
> ```
> %USERPROFILE%\Documents\RegistryScripts\
> ```
>
> This keeps your registry modifications organized and easy to find. You could store both the installation and removal scripts there.

## 7.3. Remving the Cygwin dependencies

because I hit my 5 hour message limit on Claude.AI I contined the conversation with copilot. We were able to remove the WSL dependency with the following script (wsl-here2_v2.reg)

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\wslhere]
@="WSL Here"
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Directory\Background\shell\wslhere\command]
@="cmd.exe /c cd /d \"%V\" && ubuntu.exe run \"bash -ic 'bash'\""

running this script will overwrite the keys that we wrote to in the first version of the script. This is the recommened scipt that I suggest One should try first.

# 8. Using ConEmu instead of of the Ubuntu.exe shell

I thought it would be cool. If we could open our WSL shell in the ConEMU terminal emulator rather than the Ubuntu.exe terminal emulator. This was achived with the following script (wsl-here2_v3.reg)

> Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\wslhere]
@="WSL Here"
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Directory\Background\shell\wslhere\command]
@="\"C:\\Program Files\\ConEmu\\ConEmu64.exe\" -cmd cmd /c cd /d \"%V\" && ubuntu.exe run \"bash -ic 'echo This is ConEmu; echo Shell: $SHELL; bash'\""

## 8.1 ConEMU options

ConEmu Parameters Explained:
- `-cmd`: Specifies the command to run
- `-new_console:t:"Name"`: Creates a new tab with specified name
- `-new_console:d:"path"`: Sets starting directory
- `^`: Line continuation in Windows commands
- `-run`: Executes the following command

Example with parameters:

"C:\Program Files\ConEmu\ConEmu64.exe" ^
    -new_console:t:"Development" ^
    -new_console:d:"%V" ^
    -cmd cmd /c "ubuntu.exe run bash -ic 'echo Welcome to dev environment; bash'"

# 9. Process Hierarchies and Termianl Considerations.
In the above examples there were several tradeoffs based on how we launched WSL. These tradeoffs include:

## 9.1 Process Hierarchies Tradeiffs
- Direct WSL launch: Clean process tree
- Through Cygwin: Additional process layer but better terminal
- Through ConEmu: Additional processes but superior terminal experience

## 9.2 Terminal Considers
These different approaches provided different terminal experiences:
Different approaches provide different terminal experiences:
- Default Ubuntu.exe terminal: Basic functionality
- ConEmu: Enhanced features, better configuration
- Cygwin's mintty:
- Better color support
- Improved copy/paste
- Better font rendering
- More configuration options

# 10. Method considerations (Local file approaches (e.g. shotcuts and .bat files vs Registry approaches (e.g. context menues))

One primary consideration, with the above methods is whether to use a context menu, or instead use a file like a .bat file or shortcut to achieve the same result. The context menu approach is more sophisticated but such menus should be somewhat univerasal to avoid cluttering up the registry.

For instance, if we have a script to initialize a project environment, with the appropriate shell and running processes (e.g. redis), it would have to be sophisticated enough to adapt to varying project needs. This could lead to quote a complicated script and as a consequence it might be better to handle such diverse use cases with either a .bat file or shortcut.

Some project specific use cases might include:

## 10.1 Project specific use cases
- Launch multiple services (Redis, Rails server)
- Set up development environment
- Open required editors/tools
- Initialize project-specific environment variables

## 10.2 Method Comparison table

| Aspect | Context Menu (Registry) | Shortcuts | Batch Files | Through Cygwin |
|--------------------- |------------------------|-------------------|-------------------|-------------------|
| Setup Complexity | One-time registry edit | Simple file copy | Simple scripting | Package installation |
| Launch Speed | Immediate | Quick | Quick | Extra process layer |
| Terminal Quality | Basic/ConEmu | Basic/ConEmu | Basic/ConEmu | Better (mintty) |
| Process Tree | Clean | Clean | Varies | Additional layer |
| Customization | Limited | Per shortcut | Highly flexible | Flexible |
| Maintenance | Registry edits needed | File management | Easy to modify | Package updates |
| Project Specific | No | Yes | Yes | No |
| Multiple Terminals | Single instance | Configurable | Configurable | Single instance |
| Path Handling | Native or custom | Native WSL | Scriptable | Built-in tools |

# 11. Future work

While in this document we focused on getting the WSL shell to run in various windows based terminal emulators, we could also create simmilar scripts to intialize other environments, and applications. These include:

- Customized development environments
- Language-specific shells (Python, Node.js)
- GUI application launching through WSLg
- Integration with different terminal emulators
- Custom context menus for different project types

we believe that in most cases one will want to set up the shell enviornet to launch a langage specific shell rather than directly launch this shell but this isn't always the case. For instance, if One had a bunch of custom MATLAB/OCTAVE custom scripts and data in a folder, they might want to directly launch the intepreter directly in that folder.

## 11.1 Custom Environment fo specific Pojects

When launching development environments, we're often working with tools that already have sophisticated environment management - Rails with Bundler and Gemfiles, Python with virtualenv or conda, Node.js with npm.

Shell scripts provide an easy to understand and easy way to configure these enviornemtns, which is alanglous to how many light weight and early versions of linux set up their shell environments with scripts like bash.rc.

In some cases we will want to leverage existing tools, and in these cases our scripts may work with existing tools. For instance, since a Ruby on Rails project handles the environment setup via the GEM file, it might be enough simply to launch the desired termianl, emulater, and perhaps run the needed services at the same time in a sperate tab. In which case we might have something like the following (**not tested**):

@="\"C:\\Program Files\\ConEmu\\ConEmu64.exe\" -cmd cmd /k \"cd /d \"%V\"\" -new_console:t:\"Windows\" ^
-new_console:d:\"%V\" -run ubuntu.exe run \"bash -ic 'redis-server --daemonize yes; bash'\" -new_console:t:\"Ubuntu\""

Alternatively, in the Ruby case if for some reason, we needed a greater degree of customization and automation, we could have scripts that utilize rbenv and rvm.

source ~/.rvm/scripts/rvm

Our shell integration work isn't trying to replace these tools, but rather to provide convenient ways to access them in their proper context.

## 11.2 Launching other Graphical Applications

Terminal emulators are not the only type of graphical applicatons we could luanch with these technigues. And the graphical applications we launch could be either Linux or Windows based. Any easy way to launch Linux based graphical applications is with WSLg. For instance, we might want to launch a Linux based file eplorer. The reason we might want to do this is so that the file system structure matches the linux structure, and our context menues match the linux context. Furthermore many linux file explorers can launch applications (e.g. terminal emulators), using the current folder as the context.

# 12. Conclusion

In this document we looked at various methods to Lunch linux enviornemtns and to some degree how to interoperate between them. The primary focus was about launching WSL, with the desired context (e.g. working directory) and terminal emulator (e.g. ConEMU), but the techniques descrived above extend well beyond this narrow application (see section "11. Future work"). With this above techqnies we hope that your windows experience will be much more streamlined.

# Appeneix A Troubleshooting

## A.1. Forgot my WSL password
If you've forgotten your WSL Ubuntu password:
1. Open PowerShell as administrator
2. Reset the password with:

wsl --user root
passwd yourusername

3. Enter new password when prompted
4. Exit root shell with `exit`

### A.1.1. Alternative approach change default user

I'll help expand section A.1 to include the alternative approach. Here's the revised version:

## A.2. Forgot my WSL password

### A.2.1. Using Root to Reset Password
If you've forgotten your WSL Ubuntu password:
1. Open PowerShell as administrator
2. Reset the password with:

wsl --user root
passwd yourusername

3. Enter new password when prompted
4. Exit root shell with `exit`

### A.2.2. Using Default User Method
Alternative approach using default user configuration:
1. First check current default user:

wsl -d Ubuntu -u root cat /etc/wsl.conf

2. Change default user to root:

wsl --shutdown
ubuntu config --default-user root

3. Start WSL and change password:

passwd yourusername

4. Change default user back:

wsl --shutdown
ubuntu config --default-user yourusername

### A.2.3 Notes on this section

This second method is useful when:
- You can't remember root password
- First method isn't working
- You need to perform other root-level tasks
- You want to avoid using `wsl --user root` command

Note: Always remember to change the default user back to your regular user account after resetting the password.

## A.3. Line Ending Issues
If scripts aren't working properly:
1. Check line endings in your editor
2. Use `dos2unix` on shell scripts
3. Look for ^M characters at line ends

## A.4. WSL Launch Failures
If WSL won't launch:
1. Try `wsl --shutdown` and restart
2. Check WSL status: `wsl --status`
3. Update WSL: `wsl --update`

## A.5. ConEmu Integration Issues
If ConEmu isn't launching properly:
1. Verify ConEmu installation path
2. Check quotes in registry commands
3. Try launching ConEmu directly first

# Appendix B. Update WSL to get WSLg. (Only needed for future work)

In the future work section, we suggested using the aborve approaches to launch WSLg application. If you installed WSL prior to WSLg, you'll need to update WSL to get WSLg. Here are the steps.

1. Open PowerShell as administrator
2. Update WSL to get WSLg:

wsl --update

Restart WSL:

wsl --shutdown

Start WSL again by opening your Ubuntu application or running any WSL command

For more on WSLg refer to our prior work:

https://bsky.app/profile/s243a.bsky.social/post/3lchbfjxgkc24
Split into three artifacts:
Part 1 (Setup & Launchers): [claude.site/artifacts/b7...](https://claude.site/artifacts/b770bb84-f22e-42b3-8e43-5858ee84de2d)
Part 2 (Integration Methods): [claude.site/artifacts/ba...](https://claude.site/artifacts/ba1b1b26-a9df-4126-9c6e-6e1e27c43ccb)
Part 3 (Organization & Troubleshooting): [claude.site/artifacts/68...](https://claude.site/artifacts/68dd75f4-2a68-4ef2-8a05-ce0121325142)

# Appendix C. ConEMU tasks

When using ConEMU, it is possible to use a built-in Task feature to simply resistry scripts. Copilot suggested the following (**Not tested**):

> Implementing the Task in Your Registry Script
Once you have created the task, you can reference it in your registry script to open ConEmu with the specific task:
>
> plaintext
> Windows Registry Editor Version 5.00

> ```
> [HKEY_CLASSES_ROOT\Directory\Background\shell\wslhere]
> @="WSL Here"
> "NoWorkingDirectory"=""
>
> [HKEY_CLASSES_ROOT\Directory\Background\shell\wslhere\command]
> @="C:\\Program Files\\ConEmu\\ConEmu64.exe -run {WSL Here}"
> ```
> Testing the Task
> Right-Click in File Explorer: Use the context menu in File Explorer to select "WSL Here."
>
> Verify: Ensure ConEmu opens a new tab or window running the WSL shell in the specified directory.
>
> Are Tasks Needed?
> Tasks are not strictly necessary for what you're trying to achieve, but they do provide a structured and reusable way to launch specific commands or environments in ConEmu. They can make your workflow more efficient and easier to manage, especially if you find yourself frequently opening the same types of shells or running similar command sequences.
>
> By using tasks, you can ensure that your commands are consistently executed in the desired environment, reducing the chance of errors and making your setup more robust.