Corporate · onsite · online training worldwide
contact@DevOpsSchool.com· +91 99057 40781·
> Automation & Scripting · DevOpsSchool Trainer

Bash Scripting Trainer

Private corporate batches, live online cohorts and 1-on-1 mentoring in production-grade shell automation — the layer every pipeline, image build and runbook rests on — taught by a practitioner who runs it in production.

20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank

DeliveryOnline · Onsite · Hybrid
FormatsCorporate · 1-on-1 · Cohort
AgendaCustomisable
Batch size8–30 engineers
Engineers we've trained work at
JPMorgan ChaseBank of AmericaWells FargoVerizonNokiaWorld BankGE HealthcareVMwareOracleQualcommMercedes-BenzAirbusDatadogSplunkDeloitteInfosysWiproCapgemini
# who teaches it

Your Bash Scripting trainer

Rajesh Kumar

Principal DevOps Engineer & Architect

20 years in productionPrincipal / architect roles10,000+ engineers trainedM.Tech BITS Pilani25+ certifications

Rajesh teaches Bash scripting around failure semantics rather than syntax — exit codes and pipefail, quoting and word splitting, the difference between the test builtin and the double-bracket conditional, traps for deterministic cleanup, and getopts for a script interface other people can use. Sessions run every example against a live shell, including the ones that go wrong: the unquoted path with a space, the pipeline that swallows an error, the subshell that loses a variable, and the script that only works because of an option someone set interactively.

Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.

One practitioner, not a bench

You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.

The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.

18,000+certified learners
500+corporate batches delivered
50+countries served
100+certification programmes
# faculty

Who delivers Bash Scripting engagements

Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.

How your Bash Scripting trainer is chosen

Engagements are matched on the tool, not the calendar. For Bash Scripting that means a trainer who has run it in production — production-grade shell automation — the layer every pipeline, image build and runbook rests on — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.

Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.

Rajesh Kumar

Principal DevOps Engineer & Architect

India20 yrsLead trainer

Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.

Gaurav Aggarwal

IndiaInstructorCoach

Harsh Mehta

IndiaInstructorCoach

Kapil Gupta

IndiaInstructorCoach

Kunal Jain

IndiaInstructorCoach

Nikhil Gupta

IndiaInstructorCoach

Pranab Kumar

IndiaInstructorCoach

Rohit Ghatol

IndiaInstructorCoach

Amit Agarwal

IndiaInstructorCoach

Anil Kumar

IndiaInstructorCoach

Balachandran Anbalagan

IndiaInstructorCoach

Durga Prasad

IndiaInstructorCoach

# how to engage

Four ways to work with this trainer

Private corporate batch

Teams of 8–30

Custom agenda, your timezone, onsite or online, NDA-friendly.

Request a quote

1-on-1 mentoring

Individual engineers

A private instructor and a curriculum built around your goal.

₹99,999

Live & Interactive cohort

Individuals who want peers

Scheduled batch, max 8 to 10 hours of live instruction.

₹34,999

Self-paced video

Self-starters

Full LMS access — 20+ courses and 50+ tools included.

₹833/mo
# private batches

Private Bash Scripting training for your team

A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.

Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.

Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.

Talk to us about a private Bash Scripting batch

What you provide vs what we bring

  • You: the room or the call, and the engineers
  • Us: trainer, agenda, labs, assessment, certificates
  • Labs: we guide your team through provisioning their own free-tier cloud environment — the skill goes with them
# the technology

What is Bash Scripting?

Bash scripting is the practice of writing programs for the Bourne Again Shell — the default interactive and scripting shell on almost every Linux distribution and the interpreter that runs inside container builds, CI job steps, systemd units, cron entries, cloud-init blocks and Kubernetes lifecycle hooks. A shell script is not a lesser kind of program; it is the program that runs before everything else is available, on a host where nothing else is installed yet.

The language is small and idiosyncratic. Everything is a string until you force it not to be, word splitting and globbing happen to unquoted expansions, exit codes rather than exceptions carry failure, and the conditional expression has two forms with meaningfully different behaviour. Learned properly, that model is fast and expressive: pipelines compose processes, parameter expansion does string surgery without spawning a subprocess, arrays and getopts give a script a real interface, and traps make cleanup deterministic.

Learned badly — which is the normal case — Bash scripting produces the failure class every operations team recognises. An unquoted variable containing a space destroys the wrong directory. A pipeline reports success because only the last command's exit status was checked. A script works on the author's machine and fails on the build agent because it assumed a shell option, a locale or a GNU flag. The difference between the two outcomes is a handful of habits: quoting, strict mode, checked exit codes, traps and a test for the script itself.

Why this skill matters now

Shell did not get replaced. It got embedded. Every Dockerfile RUN line, every CI job step, every entrypoint, every systemd ExecStart wrapper and every cloud-init block is shell, which means the average engineer now writes more Bash than they did a decade ago while treating it as less of a discipline.

That asymmetry is where incidents come from. Shell code sits at the most privileged point in the delivery chain — it runs as root, at build time, on every node — and it is routinely the least reviewed and least tested code in the repository. Teams that have adopted shellcheck, strict mode and a shell test harness see a measurable drop in broken builds and destructive operational mistakes; teams that have not are one unquoted variable away from an outage.

The skill in demand is not command trivia. It is writing shell that fails loudly, cleans up after itself, handles arguments properly, and behaves the same on a developer laptop, a build agent and a minimal container image.

Bash Scripting training
# outcomes

What your team can do afterwards

Write shell scripts that fail loudly and predictably — strict mode, checked exit codes, pipefail and traps that clean up on any exit path
Quote and expand correctly, and explain exactly what word splitting and globbing do to an unquoted variable
Choose between test, [ ] and [[ ]] knowingly, and use arithmetic evaluation instead of string comparison where it belongs
Give a script a real command-line interface with getopts, positional parameters, shift, defaults and usage output
Do string manipulation with parameter expansion — substring removal, search and replace, defaults — without spawning subprocesses
Use arrays, integer and read-only variables, and understand which variables survive an export into a child process
Control input and output deliberately: streams, redirection, here-documents, printf formatting and reading input safely
Run scripts correctly in production contexts — background, nohup, exec, cron, at and systemd — and debug them with set -x and shellcheck
# curriculum

11 modules. Live demos in a real lab, not slides.

01Why shell, what Bash is, and getting your scripts into version controlLive & Interactive5 hrs · 2 assignments · 1 capstone

Where shell scripting belongs and where it does not. What the shell actually is relative to the kernel and the utilities it calls, what to expect from the course, and the prerequisites — then Git, because a script that is not in version control is an outage waiting to happen.

Topics: Why shell scripting, and where Python or Go is the better answer · Linux internals as the shell sees them — processes, streams, exit codes · What to expect from this course and its prerequisites · Git fundamentals: introduction and setup · Basic operations in Git for script repositories · GitHub and remote collaboration on shell code

  • Assignments: (1) Set up a scripts repository with a sensible structure and a README; (2) Commit and push a first script with a meaningful history
  • Capstone: Establish the versioned script repository you will build on for the rest of the course
02A first look at shell scriptsLive & Interactive5 hrs · 2 assignments · 1 capstone

From a command you typed once to a file someone else can run. Creating a script, the shebang and what the kernel does with it, permissions, how the script is located and called, naming conventions, and the type builtin for working out what a name actually resolves to.

Topics: Creating a shell script · A note-taking script, built live · Calling the script — path, PATH and the execute bit · The shebang and what the kernel does with it · Naming your script and avoiding collisions · The type command: builtin, alias, function or binary?

  • Assignments: (1) Write and install a small utility script that runs from anywhere on PATH; (2) Determine, for ten names, whether each is a builtin, alias, function or binary
  • Capstone: Ship a first script with a shebang, correct permissions and a usage message
03Variables, input and debuggingLive & Interactive5 hrs · 2 assignments · 1 capstone

Variables as Bash defines them — untyped strings until told otherwise — and the habits that stop them causing damage. Assignment and expansion, quoting discipline, reading input from a user or a file, and the debugging tools you will use for the rest of the course.

Topics: Variables: assignment, expansion and scope · Using variables in a script · Good habits — quoting, braces, naming, uppercase for exported only · Reading input with read · Debugging your script: set -x, set -e, set -u and PS4 · shellcheck as a standing check

  • Assignments: (1) Fix a script that breaks on a filename containing a space; (2) Instrument a failing script with set -x and locate the failure
  • Capstone: Adopt a strict-mode header and shellcheck-clean baseline for every script you write
04If, then, else — conditions and return codesLive & Interactive5 hrs · 2 assignments · 1 capstone

Conditional logic in a language where truth is an exit status. The if statement and what it actually tests, return codes and $?, the conditional expression in both its forms, arithmetic tests, and the logical operators — including the precedence surprises that break real scripts.

Topics: The if statement and what it evaluates · Return codes, $? and exit status conventions · The conditional expression: test, [ ] and [[ ]] · String, file and existence tests · Arithmetic tests and (( )) · And, or, not — and operator precedence · The if statement revisited with strict mode

  • Assignments: (1) Rewrite a chain of [ ] tests using [[ ]] and explain each behavioural difference; (2) Write a pre-flight check that exits with distinct codes per failure class
  • Capstone: Build a pre-flight validation script that a deployment refuses to proceed without
05Control flow — loops, case and short-circuitsLive & Interactive5 hrs · 2 assignments · 1 capstone

Iteration and branching. While and until, the classic and C-style for statements, break and continue, the case statement for dispatch, and the && and || short-circuit forms — with a clear account of when they are readable and when they hide errors.

Topics: while and until · The classic for statement · The C-style for statement · break and continue · The case statement · && and || short-circuit evaluation · Looping over lines safely with while read

  • Assignments: (1) Loop over a file of hostnames safely, handling spaces and blank lines; (2) Convert a nested if chain into a case dispatch
  • Capstone: Write a retry-with-backoff loop that gives up cleanly and reports why
06Input and outputLive & Interactive5 hrs · 2 assignments · 1 capstone

Controlling what a script says and where it says it. echo versus printf and why printf wins, read revisited for structured input, the three standard streams, redirection in all its forms, here-documents and here-strings, and separating machine-readable output from human commentary.

Topics: Output: echo and printf, and formatting with printf · Input: read revisited — IFS, -r, -t and delimiters · Standard streams: stdin, stdout, stderr · Redirection, appending and file descriptor duplication · Here-documents and here-strings · Process substitution · Logging to stderr so stdout stays parseable

  • Assignments: (1) Rewrite a script so all diagnostics go to stderr and only data goes to stdout; (2) Use process substitution to compare the output of two commands without temp files
  • Capstone: Produce a script whose output can be piped into another tool without post-processing
07Variables in depth — arithmetic, arrays and scopeLive & Interactive5 hrs · 2 assignments · 1 capstone

The typed side of an untyped language. Integer variables and arithmetic expressions, read-only variables, exporting and what a child process actually inherits, and indexed and associative arrays — the structure most shell scripts should be using and are not.

Topics: Integer variables and declare · Arithmetic expressions and (( )) · Arithmetic expansion versus expr and let · Read-only variables and constants · Exporting variables and the environment a child sees · Indexed arrays · Associative arrays · Subshells and why a variable set in a pipeline disappears

  • Assignments: (1) Replace a set of numbered variables with an indexed array and iterate it correctly; (2) Explain and fix a counter that resets because it was incremented inside a pipeline
  • Capstone: Build a configuration lookup using an associative array instead of repeated greps
08Script parameters and a real command-line interfaceLive & Interactive5 hrs · 2 assignments · 1 capstone

Turning a script into a tool. Positional parameters, the special variables every script should handle, shift, and getopts for parsing options properly — including error handling, so an unknown flag produces usage output and a non-zero exit rather than silent misbehaviour.

Topics: Handling script parameters and positional arguments · Special variables: $0, $#, $@, $*, $?, $$, $! · "$@" versus "$*" and why the quoting matters · shift and consuming arguments · getopts for option parsing · getopts: handling errors and unknown options · Usage, help output and exit conventions

  • Assignments: (1) Add getopts-based flags, defaults and a usage block to an existing script; (2) Handle an unknown option and a missing required argument correctly
  • Capstone: Ship a script with a documented interface another team could adopt unchanged
09Strings and pattern matchingLive & Interactive5 hrs · 2 assignments · 1 capstone

Parameter expansion, which does most of what people spawn sed and cut for — faster and without a subprocess. Substring removal, search and replace, default and error values, pattern matching in the conditional expression, regular expression matching, and the end-of-options convention.

Topics: Fun with string parameters · Removing part of a string — prefix and suffix expansion · Search and replace within a variable · Setting a default value and failing on unset · Conditional expression patterns and globbing · Regular expressions in the conditional expression and BASH_REMATCH · End of options: -- and filenames that start with a dash

  • Assignments: (1) Replace five external command calls with parameter expansion and measure the difference; (2) Parse a semantic version string using only builtin expansion
  • Capstone: Write a filename and path handling library that survives spaces, dashes and unicode
10Shell functions and code you can reuseLive & Interactive5 hrs · 2 assignments · 1 capstone

Structuring a script that has outgrown a single flow. Defining and calling functions, arguments and local variables, return values versus output, sourcing a shared library, and the conventions that keep a growing shell codebase readable — plus the miscellaneous behaviours that surprise people.

Topics: Shell functions: definition, calling and arguments · local variables and why they are not the default · Returning status versus emitting output · Sourcing a shared function library · Recursion and its limits in shell · Miscellaneous remarks — aliases, builtins and command lookup order

  • Assignments: (1) Extract repeated logic from three scripts into a sourced function library; (2) Write a logging function with levels used consistently across a script
  • Capstone: Build a reusable shell library with functions for logging, validation and cleanup
11Running scripts in productionLive & Interactive5 hrs · 2 assignments · 1 capstone

Where the script actually executes, and what changes when it does. The several ways to invoke a script and how each affects the environment, background execution and nohup, exec, scheduling with at and cron, and the shell options that make behaviour deterministic across machines.

Topics: Many ways to run your script — sh, source, ., exec, subshell · Running your code in the background · nohup and detaching from the terminal · exec and replacing the process image · at and cron for scheduled execution · set and shopt — making behaviour explicit rather than inherited · traps and guaranteed cleanup on exit or signal · Locking so two copies never run at once

  • Assignments: (1) Add a trap-based cleanup and a lock file to a long-running script; (2) Schedule a job under cron and fix the PATH and environment differences that break it
  • Capstone: Deploy a scheduled, locked, trap-protected script that logs and alerts on failure

Need this mapped to your stack?

We rebuild the agenda around the tools you actually run.

Request a custom agenda
# hands-on

Labs and capstones your engineers actually build

LAB · SAFETY

Break it with a space

Take a working script, run it against filenames containing spaces, newlines and leading dashes, then fix every failure with quoting, arrays and end-of-options handling.

quotingword splittingarrays
LAB · FAILURE

The pipeline that lied

Debug a deployment script that reports success while a middle command in the pipeline failed, then rebuild it with strict mode, pipefail and explicit exit-code checks.

pipefailexit codesstrict mode
LAB · INTERFACE

From script to tool

Give an existing script a getopts interface with flags, defaults, a --dry-run mode, usage output and correct exit codes for every error class.

getoptscliusage
LAB · TEXT

Parameter expansion instead of subprocesses

Rewrite a text-mangling script that calls sed, cut and awk in a loop using only builtin expansion, and measure the runtime difference across ten thousand iterations.

expansionperformancestrings
LAB · CLEANUP

Traps, locks and signals

Build a long-running job that cleans up temporary files and releases its lock on normal exit, error, SIGTERM and SIGINT alike — then kill it in every way you can.

trapsignalslocking
CAPSTONE · PRODUCTION

A scheduled job you would trust

Ship a cron- or timer-driven script with logging, locking, traps, a tested interface, shellcheck-clean source and an alert path when it fails.

cronloggingshellcheck
# ecosystem

The tools Bash Scripting sits next to

Linux
Git
shellcheck
systemd
cron
Docker
Jenkins
GitLab CI
Ansible
awk
sed
Make

Who this is for

  • System administrators and operations engineers automating routine work
  • DevOps and platform engineers writing pipeline steps, entrypoints and image build logic
  • SREs turning manual runbooks into scripts that can be run under pressure
  • Developers who write Dockerfiles, Makefiles and CI jobs and want the shell inside them to be correct
  • Support engineers building diagnostic and evidence-collection tooling
  • QA and release engineers wrapping test and deployment tooling

Pre-requisites

  • Comfortable using a Linux or macOS terminal for everyday tasks
  • Familiarity with core commands — ls, cd, cp, grep, less, chmod
  • Understanding of files, directories and permissions
  • Some exposure to version control, ideally Git
  • A Linux host, VM or container you can experiment in and break
# pricing

Straightforward pricing

Every plan includes 1 year of full LMS access — not just this course, the entire DevOpsSchool LMS: 20+ courses, 50+ tools, videos, quizzes, assignments and projects.

Self-paced video

₹833/mo

Billed yearly at ₹9,996

Enroll now

1-on-1 mentorship

₹99,999

Full program, private instructor

Enroll 1-on-1

Corporate / private batch

8–30 engineers · custom agenda · onsite or online · PO and GST invoicing

Get a custom quote

Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.

Terms. Course material remains licensed to the attendee. Read the terms.

Your data. We don't share it with third parties. Privacy policy.

Every attendee gets a verifiable certificate

  • Issued per attendee on completion
  • Verifiable at devopsschool.com/certificates
  • Hard copy available on request
  • Corporate batches receive an attendance and assessment report
DevOpsSchool

Bash Scripting Training

Certificate of completion

# feedback

What engineers say

4.4 / 5 from 26 reviews on Trustpilot.

★★★★★
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
AARTI KUMARI · Trustpilot
★★★★★
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
Sonali Tiwari · Trustpilot
★★★★★
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
chandrasekaran j · Trustpilot
★★★★★
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Raimy Roy · Trustpilot
★★★★★
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Fire Titan · Trustpilot
★★★★★
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Ando Gg · Trustpilot
# comparison

Why a named practitioner beats a marketplace listing

What mattersYouTube + blogsGeneric online courseFreelance marketplaceDevOpsSchool
Named practitionerNoRarelyVaries per bookingYes — same trainer each time
Production experienceUnknownUnknownUnverified20 years, named employers
Custom agendaNoNoSometimesBuilt from your stack
Onsite deliveryNoNoSometimesYes
Lab environmentNoneSandbox that expiresVariesYour own cloud — skill goes with you
AssessmentNoneQuizRarelyAssignments + capstone per module
Per-attendee certificatesNoSometimesRarelyYes
Corporate invoicingNoLimitedVariesPO and GST
Post-training supportNoneForum, time-limitedNoneLifetime forum access
# questions

Frequently asked

Can the agenda be customised for our stack?
Yes — that is the normal case for a private batch. We start with a discovery call, look at the CI system, distributions and constraints you actually run, and rebuild the module list around them. Examples then use your scripts rather than a generic one.
Do you deliver onsite?
Yes. Private batches run onsite at your premises, live online, or hybrid. You provide the room and the engineers; we bring the trainer, agenda, labs, assessment and certificates.
What lab environment do we need?
Attendees provision their own environment — free-tier AWS, Azure or GCP, or local VMs — and we walk them through it. We deliberately do not hand out temporary sandboxes, because the environment they build is the one they keep.
What size are batches?
Private corporate batches run 8 to 30 engineers. Public Live & Interactive cohorts are capped at 10 so everyone gets time with the trainer.
Do attendees get a certificate?
Yes — every attendee receives a completion certificate, verifiable at devopsschool.com/certificates. Corporate batches also receive an attendance and assessment report.
What is your refund position?
If we cancel or postpone a cohort, you receive a full refund within 15 days. There is no general money-back guarantee, and GST and gateway fees are not refunded.
How long does a private Bash scripting batch take?
Typically two to three days. Foundations through control flow and I/O fit comfortably in two; adding arrays, getopts, parameter expansion, functions and production execution with real debugging labs takes three.
Is Bash still worth learning when we write everything in Python?
Yes, because you are still writing Bash whether you intend to or not. Dockerfile RUN lines, CI job steps, entrypoints, systemd ExecStart wrappers and cloud-init blocks are all shell, and they run at the most privileged point in your delivery chain. The course also covers where Python is genuinely the better choice.
Do you cover POSIX sh as well as Bash?
Yes, where it matters. We flag every Bash-specific construct — arrays, [[ ]], process substitution — so attendees know which scripts will run under dash or busybox ash in a minimal container image, and which will not.
Will this help with our existing scripts?
Directly. Private batches can use your own scripts as lab material: we run shellcheck across them, work through the findings, and rewrite the worst offenders live. Teams usually leave with a fixed shared library and a strict-mode template.
Do you cover testing shell scripts?
Yes. We cover shellcheck as a mandatory gate, set -x and PS4 for debugging, and structuring scripts as sourced functions so they can be exercised by a test harness such as bats rather than only by running them for real.

Still deciding?

Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.

Talk to an advisor
# ready when you are

Book a Bash Scripting trainer — or ask a question first.

  • No spam, no drip sequence
  • Syllabus in 60 seconds
  • A human reply within one business day

Prefer to call or email?

More ways to reach us on the contact page.

Talk to an advisorRequest a quote