Let’s create our first simple shell script

#!/bin/sh
# This is a comment!
echo Hello World        # This is a comment, too!

• The first line tells Unix that the file is to be executed by /bin/sh. This is the standard location of the Bourne shell on just about every Unix system. If you’re using GNU/Linux, /bin/sh is normally a symbolic link to bash (or, more recently, dash).
• The second line begins with a special symbol: #. This marks the line as a comment, and it is ignored completely by the shell.
• The only exception is when the very first line of the file starts with #! (shebang) - as ours does. This is a special directive which Unix treats specially. It means that even if you are using csh, ksh, or anything else as your interactive shell, that what follows should be interpreted by the Bourne shell.
• Similarly, a Perl script may start with the line #!/usr/bin/perl to tell your interactive shell that the program which follows should be executed by perl. For Bourne shell programming, we shall stick to #!/bin/sh.
• The third line runs a command: echo, with two parameters, or arguments - the first is "Hello"; the second is "World".
• Note that echo will automatically put a single space between its parameters.
• To make it executable, run chmod +rx <filename>

Variables

Let’s look back at our first Hello World example. This could be done using variables. Note that there must be no spaces around the “=” sign: VAR=value works; VAR = value doesn’t work. In the first case, the shell sees the “=” symbol and treats the command as a variable assignment. In the second case, the shell assumes that VAR must be the name of a command and tries to execute it.

An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes:

• Resource handles to the database, Memcached, and other backing services
• Credentials to external services such as Amazon S3 or Twitter
• Per-deploy values such as the canonical hostname for the deploy

Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which requires strict separation of config from code. Config varies substantially across deploys, code does not.

Type hinting is not mandatory, but it can make your code easier to understand and debug by

1. Improved readability
2. Better IDE support: IDEs and linters can use type hints to check your code for potential errors before runtime.

While type hints can be simple classes like float or str, they can also be more complex. The typing module provides a vocabulary of more advanced type hints.