WEBVTT 00:00:00.700 --> 00:00:05.265 This lesson connects HHY to ordinary command line tools. 00:00:05.415 --> 00:00:12.562 Our script runs a few harmless local commands, captures their outputs, and writes a structured report. 00:00:12.712 --> 00:00:19.176 The supplied example targets macOS and Linux with printf, cat, and sh available. 00:00:19.326 --> 00:00:24.041 Run it from the examples directory with the environment variable shown. 00:00:24.191 --> 00:00:31.464 We intentionally include a command that exits with code seven, so success and failure handling are both 00:00:31.464 --> 00:00:31.892 visible. 00:00:34.040 --> 00:00:37.901 Args contains the arguments passed after the script filename. 00:00:38.051 --> 00:00:42.446 We require exactly one label before reading its first element. 00:00:42.596 --> 00:00:48.335 An invalid invocation prints usage to standard error and exits with code three. 00:00:48.485 --> 00:00:55.674 Checking inputs early gives callers a predictable contract and prevents an unrelated index failure later. 00:00:55.824 --> 00:01:03.515 The label here is only descriptive text; we do not splice it into a shell command or use it as an 00:01:03.515 --> 00:01:04.613 arbitrary output path. 00:01:06.760 --> 00:01:14.013 Require_env reads a required environment variable and raises an error when the setting is unavailable. 00:01:14.163 --> 00:01:18.814 Our teaching value is a harmless label, so printing it is appropriate. 00:01:18.964 --> 00:01:24.724 Real scripts should avoid printing secrets just to prove that configuration was loaded. 00:01:24.874 --> 00:01:29.439 The shell prefix shown earlier sets the variable for that one invocation. 00:01:29.589 --> 00:01:36.715 It does not require you to edit a global shell configuration file or permanently change your environment. 00:01:38.860 --> 00:01:43.681 Run receives a List containing the executable and its separate arguments. 00:01:43.831 --> 00:01:51.405 This makes argument boundaries explicit and avoids asking a shell to reinterpret ordinary input text. 00:01:51.555 --> 00:01:57.741 We set a two second timeout because external tools should have a bounded opportunity to finish. 00:01:57.891 --> 00:02:02.841 The returned CommandResult contains an exit code and captured output. 00:02:02.991 --> 00:02:10.331 A successfully launched process can still report an unsuccessful exit status, so inspect that field 00:02:10.331 --> 00:02:10.820 deliberately. 00:02:12.970 --> 00:02:18.239 Stdout_lines exposes the captured standard output as a line stream. 00:02:18.389 --> 00:02:24.661 We uppercase each line and print the result using the same flow tools used for files. 00:02:24.811 --> 00:02:32.011 The distinction matters: this stream is derived from captured CommandResult output, rather than being a 00:02:32.011 --> 00:02:35.371 promise of live terminal streaming during execution. 00:02:35.521 --> 00:02:42.257 Choose appropriate output limits for commands that may produce large responses, and do not assume 00:02:42.257 --> 00:02:44.951 captured output can grow without bounds. 00:02:47.100 --> 00:02:50.833 The stdin option supplies text to the child process. 00:02:50.983 --> 00:02:57.618 Cat echoes our input, making this a simple way to check that the input and output connection works. 00:02:57.768 --> 00:03:05.811 This is different from stdin_lines in an HHY script, which reads input supplied to HHY itself. 00:03:05.961 --> 00:03:11.187 The download includes a separate stdin script so you can try both directions. 00:03:11.337 --> 00:03:17.140 Keeping these two boundaries clear helps when connecting several command line tools together. 00:03:19.290 --> 00:03:25.114 For a controlled failure fixture, we explicitly invoke sh with a fixed command string. 00:03:25.264 --> 00:03:29.189 It writes a message to standard error and exits with seven. 00:03:29.339 --> 00:03:37.574 Run returns that result instead of automatically treating every nonzero status as a thrown HHY error. 00:03:37.724 --> 00:03:41.351 Interpret exit codes according to the tool's contract. 00:03:41.501 --> 00:03:49.087 This constant shell snippet is only a demonstration; avoid constructing shell source by concatenating 00:03:49.087 --> 00:03:52.338 untrusted labels or other external input. 00:03:54.490 --> 00:03:59.759 Project the fields you need into an ordinary Map before JSON encoding. 00:03:59.909 --> 00:04:06.629 Our report records the user's label, whether the first command succeeded, and the deliberate failure's 00:04:06.629 --> 00:04:07.525 exit code. 00:04:07.675 --> 00:04:13.862 It does not claim every command succeeded just because the HHY script reached its end. 00:04:14.012 --> 00:04:18.023 Open the generated report and check those three values. 00:04:18.173 --> 00:04:26.091 For a real automation job, decide whether any recorded failure should also make the overall script exit 00:04:26.091 --> 00:04:26.557 nonzero. 00:04:28.710 --> 00:04:34.897 First pipe two lines into stdin dot HHY and verify uppercase output. 00:04:35.047 --> 00:04:41.255 Then run command-report without a label and confirm the usage message and exit code three. 00:04:41.405 --> 00:04:47.634 Finally, rerun the documented successful invocation and inspect the JSON report. 00:04:47.784 --> 00:04:55.763 These checks exercise argument validation, environment configuration, process capture, and failure 00:04:55.763 --> 00:04:56.488 interpretation. 00:04:56.638 --> 00:05:03.855 You now have the building blocks for repeatable system tasks, with explicit inputs and outcomes rather 00:05:03.855 --> 00:05:06.110 than assumptions about command success.