Welcome to XCODX Online Compiler
Quick Start:
Ctrl+Enter Run code
Ctrl+S Save / Download
Ctrl+L Clear output
Select a language and start coding.
Bash is the default command interpreter on most Linux systems and the language that quietly runs the infrastructure world — CI/CD pipelines, Docker entrypoints, cron jobs, deploy scripts, and the login shell on countless servers. Written by Brian Fox for the GNU Project in 1989 as a free replacement for the Bourne shell, it turns loops, pipes, and command substitution into a few terse lines that would take a page in most languages. Fluency with it is close to mandatory for DevOps, SRE, and backend work, and shell questions surface constantly in infrastructure interviews. This page runs your script with real GNU Bash on an actual Linux sandbox wired to a live terminal: the read builtin blocks for keyboard input, coreutils like grep, sed, awk, and sort are on the PATH, and output streams exactly as a local shell would show it. The Bash version in use is shown in the badge and in $BASH_VERSION.
#!/usr/bin/env bash
set -euo pipefail
read -rp "Enter a sentence: " sentence
# Word count via a coreutils pipeline
words=$(echo "$sentence" | wc -w)
echo "That sentence has $words word(s)."
# Unique words, lower-cased and alphabetised
echo "Unique words:"
echo "$sentence" | tr ' ' '\n' | tr 'A-Z' 'a-z' | sort -u | sed 's/^/ - /'
echo "Shell: $BASH_VERSION on $(uname -s)"
Bash shines at gluing existing programs together: a few pipes through grep, awk, and sort will slice a log or reshape a CSV faster than writing equivalent code elsewhere, which is why it is the first reach for deploy steps, cron jobs, and CI glue. Use this page to test a fragment before it lands in a pipeline — where an unquoted variable or a wrong exit code can fail silently at 3 a.m. — to rehearse the parameter-expansion and piping questions common in DevOps and SRE interviews, or to work through a Linux course from any browser. It is a poor choice once logic gets genuinely complex: past a certain amount of nested conditionals, arrays, and string parsing, quoting rules turn brittle and a real language like Python or Go is safer. For orchestrating commands and automating the terminal, though, nothing is more direct.
Yes — the script runs in a genuine terminal session, so read (and read -p / read -rp) prints its prompt and blocks until you type a line and press Enter. Scripts that ask several questions in a row, or loop with read inside a while, behave exactly as they would running bash script.sh in a local terminal. Ctrl+D signals end-of-input when you are reading a stream.
Real GNU Bash executing on a real Linux sandbox — not a JavaScript reimplementation. Pipes, redirection, command substitution, arrays, functions, [[ ]] tests, and parameter expansion all work natively, and standard coreutils (grep, sed, awk, sort, cut, tr, wc, date) are on the PATH to pipe between. Features behave per the Bash manual because it is the actual shell.
No — the sandbox has no network access and no root privileges, so apt-get, curl, wget, and pip have nothing to reach and nowhere to install to. You get Bash plus the standard coreutils that ship with the image; anything outside that base set is unavailable. Write scripts that rely only on the shell and common Unix tools, and do package-dependent work on a local machine.
No. Each run starts in a clean, isolated, temporary filesystem, so any file you create — with touch, a > redirect, or tee — exists only for that run and is wiped afterward. That is fine for scratch work: create the file, use it within the same script, and do not rely on it surviving. Keep anything you want to reuse inside the script itself.
The usual GNU coreutils and text tools: grep, sed, awk, sort, uniq, cut, tr, wc, head, tail, date, and seq, which cover the overwhelming majority of shell scripting. Heavier or third-party utilities (jq, ripgrep, cloud SDKs) may not be present and cannot be installed, since there is no package manager or network. If a script depends on one of those, stub it out or test that part locally.
It is Bash, so Bash-specific features — arrays, [[ ]], (( )) arithmetic, and process substitution — all work, unlike a strict POSIX sh. A #!/usr/bin/env bash shebang is a good habit and documents intent, but the script is run by Bash here whether or not you include one. You can confirm the exact version with echo "$BASH_VERSION".
main.shshellread#!/bin/bash
echo "Hello from Bash!"
echo "Welcome to XCODX Online Compiler!"
NAME="Developer"
echo "Hello, $NAME!"