This guide explains the purpose of the IT 140 Course Automation Scripts package, the common script lifecycle, and the platform folders used to prepare and maintain the course integrated development environment (IDE).
Important
This README is informative and navigational. Follow the Module One Setup Tasks for the exact commands and workflow for your course environment. Run only the scripts that match your selected platform.
- Course: IT 140 - Introduction to Scripting
- Activity Name: Main Course Repository | Course Automation Scripts
- Activity Purpose: Prepare, install, configure, verify, and update the IT 140 course IDE in supported environments.
- Artifact Version: 1.0.4
- Artifact Date-Time Group: 2026-09-07-14-30
- Development Status: Pilot — Active Development
Warning
This repository is a work in progress. Some modules and activities may not be fully implemented yet. Please check the status of each activity in the table below for the latest updates.
- IT 140 Main Course Repository | Course Automation Scripts
- Course: IT 140 - Introduction to Scripting
- Module Name: Main Course Repository
- Activity Name: Course Automation Scripts
- Activity Description: This folder contains the platform automation scripts used to prepare, install, configure, verify, and update the IT 140 course IDE.
- Program Name: IT 140 Course Automation Scripts
- Artifact ID:
IT140-SCRIPTS-README - Artifact Version:
0.1.0 - Version Date-Time Group:
2026-08-01-14-59 - Status: Draft for faculty review
- SRS Baseline:
IT140-SRS-SCRIPTS, version0.5.0, version date-time group2026-08-01-10-43 - SDD Baseline:
IT140-SDD-SCRIPTS, version0.5.0, version date-time group2026-08-01-10-43 - Manifest Baseline Reviewed: Automation release
0.5.1, release date2026-07-30, statusdraft
The IT 140 Course Automation Scripts package helps students and faculty create a consistent, supportable programming environment. The course IDE includes the applications, command-line tools, Python runtime, extensions, settings, folders, and shortcuts needed for IT 140 coursework.
Different operating systems require different commands and installation methods. The scripts in each platform folder handle those differences while working toward the same required course outcomes. Students do not need to understand every platform-specific command to use the package, but they must select the folder that matches their course environment.
The package supports designated hosted and local environments that have been implemented, tested, documented, and approved for course use. A platform may be technically capable of running the software without yet being a course-supported environment.
Each fully supported platform uses the same five-stage lifecycle:
Prepare → Install → Configure → Verify → Update
| Stage | Script | Student-facing purpose |
|---|---|---|
| Prepare | prepare_it140.<ext> |
Obtains or refreshes the course automation package and makes the remaining scripts available. On first use, students copy and run the provided preparation commands because the script package is not yet installed. |
| Install | install_it140.<ext> |
Installs or repairs the system-level software required for the course IDE. It may request permission to make approved changes to the computer. |
| Configure | configure_it140.<ext> |
Configures the current user's course folders, tools, IDE settings, extensions, account integrations, and course shortcuts. |
| Verify | verify_it140.<ext> |
Checks the system and user configuration without changing it. The report identifies passed checks, warnings, failures, and the recommended next step. |
| Update | update_it140.<ext> |
Maintains approved course IDE software and course-managed assets after the environment has been prepared. It does not replace Prepare or perform an operating-system release upgrade. |
The exact workflow depends on the environment's starting state. A local installation normally follows Prepare → Install → Configure → Verify. A student CVD begins from a course-managed image, so its initial workflow normally follows Prepare → Update → Configure → Verify. After setup, Update is used for periodic maintenance when directed by the course.
Although the commands differ by platform, the scripts follow common rules:
- Protect coursework: The scripts are designed to preserve student programs, assignment repositories, version-control history, optional tools, and unrelated settings.
- Support safe reruns: Prepare, Install, Configure, and Update are designed to be rerun when an approved course-managed item is missing or damaged.
- Keep Verify read-only: Verify reports the current condition without installing, repairing, updating, or removing software.
- Explain results: Each run identifies its purpose, reports important actions, and ends with a plain-language summary and recommended next step.
- Create support records: Each lifecycle run saves a timestamped log or transcript under
~/it140/logs/or the equivalent folder for the current platform. - Provide course continuity: If a local course IDE cannot be prepared successfully, students can continue their IT 140 coursework in the Codio Virtual Desktop while the local issue is resolved.
The Update summary separates the outcome of Update from the action needed before the next lifecycle step. Read the first three fields in order:
- Result tells whether Update completed.
- Action required tells whether you must do something before continuing, such as restart the CVD or computer.
- Next step tells you exactly what to do after the required action, if any.
A restart is a normal successful lifecycle transition when Update completed all required operations. A successful Update that requires a restart therefore reports Result: PASS and Exit code: 0. The restart requirement is reported separately as Action required and, on platforms that track it, in the support details. Do not rerun Update only because a successful summary requires a restart.
Update result meanings are standardized as follows:
| Result | Meaning | Exit-code behavior | Student action |
|---|---|---|---|
PASS |
Update completed its required operations. Warnings may be listed separately. | 0 |
Follow Action required, then Next step. |
PARTIAL |
Update began making managed changes but did not finish all required operations. | 7 |
Follow the retry/support instructions in the summary. |
CANCELED |
Update was canceled before managed changes were made. | 6 |
Run Update again when ready. |
FAIL |
Update did not complete successfully. | Nonzero code appropriate to the failure | Follow the retry/support instructions in the summary. |
Exit code 7 is reserved for an actual incomplete Update after managed state changed. It is not used merely because a restart is required.
The summary places student actions before a SUPPORT DETAILS section. Support details retain diagnostic information such as warning and failure counts, script and manifest versions, managed-change state, restart state when applicable, log path, and exit code. Students normally do not need to interpret those fields unless the summary directs them to troubleshoot or provide the information to course support.
Retry and support notices are shown only for actual failed or partial outcomes. A successful restart-required result directs the student to restart and continue; it does not direct the student to rerun Update.
| Folder | Environment | Script type | Intended use |
|---|---|---|---|
cvd/ |
Codio Virtual Desktop | Shell scripts (.sh) |
Hosted reference environment provided through the course |
win/ |
Microsoft Windows | PowerShell scripts (.ps1) |
Supported local Windows computers |
mac/ |
macOS on Apple silicon | Z shell scripts (.zsh) |
Supported local Mac computers with Apple silicon processors |
nix/ubg/ |
Ubuntu Desktop LTS with GNOME | Shell scripts (.sh) |
Supported local Ubuntu Desktop computers |
Caution
Platform scripts are not interchangeable. For example, do not run a Linux shell script on Windows or a Windows PowerShell script on macOS. Use the course setup instructions to select the correct environment and script folder.
The Codio Virtual Desktop is the IT 140 reference environment. It is a hosted Linux desktop that students open through the course rather than install directly on a personal computer. Course screenshots, demonstrations, troubleshooting reproduction, and primary acceptance testing use this environment.
The reference CVD uses Ubuntu 24.04 LTS, the APT package manager, the Xfce desktop environment, and an x86_64 processor architecture. Because the course master image already contains the shared system layer, students normally use the CVD scripts to obtain the current automation package, apply the approved initial updates, configure their own account, and verify the result.
CVD is also the course-continuity option when a local Windows, macOS, or Ubuntu installation is unavailable or being repaired.
The Windows folder contains PowerShell scripts for a supported local Windows installation. These scripts use Windows-native tools and approved software sources to prepare and maintain the same course IDE capabilities provided by the reference environment.
The main win/ lifecycle is intended for a supported Windows computer on which Windows is installed directly. The scripts manage only approved course components and keep system installation separate from the current user's configuration and account settings.
The macOS folder contains Z shell scripts for supported Mac computers with Apple silicon processors. Apple silicon includes processors such as the Apple M1, M2, M3, and later members of the same processor family.
The macOS lifecycle installs or repairs the approved system tools, configures the current user's course environment, verifies the result without making changes, and performs approved maintenance. Intel-based Macs are not included unless current course documentation explicitly identifies an approved Intel deployment profile.
The nix/ folder organizes course automation for Linux and other Unix-like operating-system families. A Linux distribution, often called a distro, combines the Linux operating-system core with a particular set of installation tools, software repositories, defaults, and desktop options.
Scripts written for one distribution are not automatically safe or compatible with another. Package managers, package names, file locations, permissions, and desktop integrations can differ even when the same applications are available.
Ubuntu Desktop LTS is the local Linux environment currently described by the course automation design. LTS means Long-Term Support, a release intended to receive maintenance and security updates for an extended period.
Ubuntu is a Debian-derivative Linux distribution. It uses the Advanced Package Tool (APT) package manager to obtain, install, repair, and update software from approved repositories. Ubuntu Desktop uses the GNOME desktop environment, which provides its windows, menus, settings, file manager, and other graphical desktop features.
The ubg/ abbreviation means Ubuntu GNOME. Its shell scripts adapt the common course IDE lifecycle to Ubuntu's APT-based software management, Linux file permissions, user environment, and GNOME desktop integrations.
{{SME TODO: Add that students and faculty can request support for other Linux distributions by opening a GitHub Issue requesting addition. They need to provide precise distribution name, version, and any relevant configuration details.}}
Two hidden folders support the platform scripts but are not separate student platforms:
| Folder | Purpose |
|---|---|
.manifest/ |
Contains the controlled JavaScript Object Notation (JSON) manifest and schema that identify approved products, versions, sources, settings, platforms, and managed assets. Platform scripts read this shared information so they do not maintain conflicting software lists. |
.dev/ |
Contains development-only requirements, design, flowchart, pseudoscript, and testing artifacts used by faculty, maintainers, testers, administrators, and technical support. Operational scripts must not depend on this folder being present in a student installation. |
Students should not edit the controlled manifest, schema, engineering artifacts, or platform scripts unless a course activity specifically instructs them to do so.
Every lifecycle script saves a timestamped plain-text log or transcript under the course log folder:
- Windows:
%USERPROFILE%\it140\logs\ - macOS, Linux, and CVD:
~/it140/logs/
When a script reports a warning, partial result, or failure, keep the final summary and the exact log path. These records help instructors, AI support tools, and university technical support identify the script version, platform, completed actions, and point of failure without requiring the student to remember every message shown in the terminal.
Follow Action required and Next step printed near the top of the summary. When requesting help, provide the final summary and the applicable log file through the support method identified in the course.