Charlie's Vulpine Shell

Vulpine as a group is an independent United Kingdom and Europe based software collaboration founded by Charlie, and later with Taylor under the BaronScott Consortium - a party of two.

Vulpine Linux is portable, micro-installable, persistent and transparent system thats defined as "terminal-first". Designed for standalone computing, micro-services, virtual environments and usable in micro, edge and embedded systems in which CVSH was developed purposefully for!

Overview

CVSH is a statically-compiled shell written in C, and stands for Charlies Vulpine Shell a purpose-built ultra-minimalist shell with some generic features you'd come to anticipate and expect with any other shell.

Features

• Command history in ~/.cvsh_history
• Configuration file at ~/.config/cvsh/cvsh.conf

HOST_COLOUR = IBlue
PATH_COLOUR = IWhite

alias test = echo "Alias works!"
alias ls = ls --color=auto
alias ll = ls -l
alias la = ls -a

Where you can define colours and supply an alias.

Usage

After running ./build.sh switch your terminal to using /usr/bin/cvsh by-default and restart the terminal.

{command}                      Just type your command... it's a shell.

How to Contribute

We kindly ask that you focus on one-branch per feature or fix, and do that single branch feature-or-fix well. This way we can ensure proper-steady and audit-able contributions rather than monolithic merge requests that risk going against the philosophy we aspire for.

1. Fork and Clone

Note

Sections of this kind will be written as if you're contributing towards Vulpine Linux, rather than just the current repository, that is because this repository builds into Vulpine Linux but it should still be followed all the same.

We want to start by saying thank you for considering a contribution that aligns with Vulpine Linux's philosophy, whilst we encourage people to follow the wiki, we know you often want a fast answer. This is a low-level, from-scratch system - so contributions should reflect an understanding of how the system is built and why it is built in this way.

Understand that all contributions should be:

• Human-first, where code must be human-written and understood
• Signed at the point of commit
• Have clear explanations in your pull-request, as changes must be well-documented
• Tested before pull-request'd, verify changes work before submitting!

Before making changes, fork the repository and clone it locally, an example of this would be:

git clone https://codeberg.org/YOUR-USERNAME/{REPO}.git && cd {REPO}/

Then create a new branch.

If its a feature (such as adding, updating or changing an existing software) git checkout -b feature/your-feature-name

An example would be: git checkout -b feature/csh-config

If your goal is to work on an issue you should use git checkout -b fix/issue-reference-name

An example would be git checkout -b fix/expand-alias-overflow

Your changes must be made in a dedicated branch (e.g. feature/your-feature-name)

2. Test Your Changes

Once you've made changes, on your branch, please build and test:

./build.sh

Follow the flowchart as a general guide:

flowchart LR
    A[Build-and-run] --> B{Is your implementation working properly?}
    B -->|Yes| C[Great, take a screenshot and write documentation]
    B -->|No| D[Debug and try again]
    C --> E[Push to fork, pull request, supply docs, submit]
    D --> B

Ensure:

• It does ./build.sh cleanly
• Your feature works as intended
• You haven't inadvertently broken something else
• It can be built reliably time-again using ./build.sh

Avoid hard coding anything that risks being re-written by ./build.sh.

3. Pull Request Expectations

• You've made the feature in git checkout -b feature/your-feature-name or similarly if its an issue or fix as issue/* or fix/* on your own fork, not on the main repository.

• You must detail in at least one paragraph (short if you prefer) what your submission is resolving; describe what you changed and why, and how your code functions cleanly. You can keep it simple, but it must be understandable.

If we do not believe you wrote it, or understand it for yourself - it will be rejected.

• Include any relevant logs or screenshots if applicable for documentation purposes.

• Where possible include a reference link or documentation, so that others can learn from you and the project.

"Using auto-ai to make submissions, pushing clearly AI-generated code, repeated low-quality or unreviewed submissions may result in restricted contribution access. We are a human-first endeavour, we understand AI can be found in the IDE through to documentation in real-life and we cannot stop this but the more we minimise it here, in our project, the happier we all are." ~Charlie

You can then push your branch to your fork and open a Pull Request against the main repository ensuring your PR description follows the expectations outlined above, remembering to sign your commit we will reject any that are not signed.

Bare in mind when providing a -m for messaging to keep it short-and-simple for example git commit -m "patch for fixing {issue}", no one wants clunky and excessive messages, we will reject ridiculous or over-wordy messages.

Review Process

All contributions are:

• Reviewed manually
• Tested for stability and compatibility
• Evaluated for alignment with project philosophy

Submissions that cannot be clearly explained or maintained will be rejected. This is true for unsigned commits or those submitted on/to the main repository - it must go through your fork, and Pull Requested. We cannot overstate enough that Vulpine Linux is built step-by-step with intent so contributions should reflect that same mindset and set the bar for other developers to come after. We appreciate strongly well written and proper commits - it matters massively for reference and professionalism both on your part and ours.

Design Philosophy

CVSH is intentionally minimal and we aim to follow the Vulpine Linux Philosophy:

• Keep it transparent so others can understand exactly what it does by reading the code
• Stateless and low-complex meaning zero hidden logic
• Every operation should be traceable and audit-able
• Dependency-light means writing in a secure and minimal way

We refuse to add convenience features that obscure how the system works. CVSH should be simply-a-shell.

Support

For support, you can reach out on discord, or InTheMansion irc channels #lobby, or #vulpinelinux.

We strongly suggest reading our wiki before submitting any issues, or checking Discord first, because not everyone has Codeberg and issues might already be known before you open one, it is always worth checking in with the community first.

License

CVSH © 2026 by BaronScott Consortium is licensed under Creative Commons Attribution-ShareAlike 4.0 International.

This license applies to CVSH as part of the Vulpine Linux ecosystem. All tools and dependencies used retain their original licenses.