Open the folder
Choose the folder that holds your script as the working folder; file tools such as read_file and grep work inside it. File tools work inside that folder, while Shell, web and SSH are not limited to it.
Workflows
Bash execute script, from open folder to exit code
03
Run a Bash script with arguments in WSL or over SSH
A Bash script can be started in three ways: bash script.sh arg1 arg2, ./script.sh after chmod +x, which works because of the shebang line, or through the exec builtin, which replaces the shell and never returns. The first form is the easiest to start with, because it needs no permission change. Shell runs the command in the environment you chose, which is WSL on your PC or a Linux system you own reached over SSH, and the card in the chat shows the real output and the exit code. You decide the arguments, so you can test the normal case and the failing case in one conversation. People often ask which form to choose: use bash script.sh while you test, because it works even when the file has no execute permission, and switch to ./script.sh once the script is final and starts with the shebang line. Whichever form you use, the exit status is the same number, from 0 to 255, and 0 always means that the script ended successfully.
Pick an approval mode
Use Ask first to see each change as a diff, or Plan only to read a plan first. Auto-run acts at once. Ask first pauses only before actions that change something.
Ask for a run
Describe the run in plain words, for example: run the script with the argument test. Name WSL or your server if you have both. Name the script and its arguments exactly.
Read the result
Open the card to see the output and the real exit code, then accept or reject any edit. A non-zero number is information. Run it again after every accepted edit. Compare it with the result you expected.
A small example script
Run greet.sh with the argument test, then without any argument.
- Shell
bash greet.sh testexit 0 - Shell
bash greet.shexit 2 - read_file
greet.shread - grep
Usage1 match
waiting for your OK before the next stepRejectAccept
greet.sh
#!/usr/bin/env bash
# greet.sh - print a greeting a few times
set -eu
if [ "$#" -lt 1 ]; then
echo "Usage: $0 NAME [COUNT]" >&2
exit 2
fi
name="$1"
count="${2:-1}"
for i in $(seq 1 "$count"); do
echo "Hello, $name ($i)"
done
exit 0greet.sh stops with a usage line and exit code 2 when the name is missing, takes an optional count with a default of 1, and only prints greetings in a loop. Read it once before you run it: there is no sudo, no download and nothing that moves or deletes a file, so it is harmless to test on any machine you own. Line by line: the shebang names the interpreter, set -eu stops on errors and unset variables, the test of $# counts the arguments, and the for loop only echoes.
Run a script in four small steps
Create the script file
Start with an empty working folder. Ask the agent to write the example above, and write_file creates greet.sh in that folder. Open the card and read the file line by line: the first line is the shebang that names the interpreter, set -eu stops the script on errors and unset variables, and the check of $# protects the rest from a missing name. Under Ask first the new file waits for your OK before it is written. Nothing has run yet. The usage branch of this script chooses 2 for wrong usage, which is a common convention. Accept the file only when you understand each line, and if you do not, ask the agent to explain it. A rejected edit leaves the folder unchanged.
Run it and read the exit code
People who search for “bash execute script” usually want one line: bash greet.sh test. Ask the agent to run it, and Shell starts the command in the environment of your chat, such as WSL, and sends back the real output and the real exit code. Expand the card for the full output. Then ask for the same run without the argument, and you should see the usage line and exit code 2. The exit code for cli applications is a number from 0 to 255 that the caller reads, and 0 means success,. Exit code 127 means a command was not found and 126 means a file cannot be executed, so these two numbers point to a typo, a missing program or a missing execute permission.
Read the arguments inside the script
read_file shows the script and grep finds where $1 and $2 are used, so you can check that each argument has a default or an error message. Here is how to parse optional arguments: the script loops with getopts, and with only one or two values the plain $1 and ${2:-1} are enough. Aliases with arguments do not behave like functions, because an alias only replaces the typed word with text, so use a function when values must go in the middle. Ask the agent to change one thing, for example the default of the count, and read the diff that edit_file shows. Then run the script again and compare the new exit code with the old one. Plan only can list the parameters the script understands without running anything.
Run the same script on a server you own
The same steps work when the working environment is a Linux system you own, reached over SSH. File tools keep working in the chat's working folder, while Shell commands run in the environment you chose, so check which one a card refers to. The exec builtin, which people look up as “bash exec script”, replaces the shell with another command and never returns, so nothing after it runs and the exit code is the one of the new command. Keep a copy before a script moves or deletes files, run it with echo first as a dry run, and use only machines you are allowed to administer. Read the final card before you close the chat. When you forward all values to another command, write "$@" in double quotes so that every value keeps its shape.
