The command line for Python in finance: moving beyond the IDE

Watch the video above, then read on for the detail and context that matters to your work in treasury and reporting.

Why finance teams use the command line

Your IDE is a comfortable place to write and test Python. But the moment your script leaves your laptop, it runs from the command line. Every scheduled liquidity report, every batch data load, every automated reconciliation that your team relies on: none of it runs through an editor with a play button. It runs as a process on a server, triggered by a scheduler, fed data through pipes and arguments, with output going to a log file you will read later.

This matters. If you work in treasury or reporting and you want your Python to actually do something, you need to understand command line for Python and how to run Python scripts in production. Your script might run perfectly in your IDE and fail silently in production because you did not test it the way it actually runs. The command line is where you find those bugs before your team does.

The commands you need

You do not need to become a shell expert. You need a small set of commands so familiar that you use them without thinking. These are the same commands that have worked for decades. They work on Windows, Linux, and Mac (with minor variation on Windows). Learn them once and you are done.

Here are the five core commands:

pwd shows you where you are right now. It stands for "print working directory". Run it and you see the full path from the root of your computer to your current folder. This is your anchor point.

ls lists what is in the current folder. Files, folders, their sizes, permissions. On Windows, the equivalent is dir. Use this to see what you are working with before you do anything to it.

cd changes directory. cd Sales/Reports moves you into the Reports folder inside Sales. cd .. moves you up one level. cd / takes you to the root. cd with no argument takes you home. Use this constantly.

mkdir creates a new folder. mkdir liquidity_data creates a folder called liquidity_data right where you are.

cp copies a file. cp old_report.py new_report.py duplicates the file. rm deletes it. Be careful with rm: it does not ask for confirmation. There is no undo. mv renames or moves a file: mv report_jan.xlsx report_feb.xlsx.

You can also use cat to look at a file quickly without opening it in an editor. cat settings.txt prints the whole file to the terminal. For a long file, head shows the first 10 lines and tail shows the last 10. These are genuinely useful for checking what is in a data file before you load it into pandas.

Navigating your file system

This is where people get stuck. File paths on the command line work the same way they do in an explorer window, but you have to think about them.

Your team probably has a shared drive like this:

Treasury/
  └── Reports/
      ├── Daily/
      │   └── liquidity/
      ├── Monthly/
      │   └── analytics/
      └── Archive/

If you are in the Daily folder and you want to go to Monthly, you do cd ../Monthly. The .. means "up one level, out of Daily, back into Reports". Then Monthly takes you into the Monthly folder.

If you want to jump all the way from Daily to Archive, you can either go cd ../Archive or you can use an absolute path: cd /Treasury/Reports/Archive. An absolute path starts with a slash (or a drive letter on Windows like C://). It does not matter where you are right now; it takes you to the same place every time.

Use absolute paths in your scripts. Use relative paths when you are navigating by hand. A script that uses cd ../data works fine on your machine and breaks on someone else's because the relative structure is not the same. A script that uses /Treasury/Reports/data/2024 works anywhere in that repository.

Let me show you both in practice. Say you are in the Daily folder and you want to list what is in Archive:

pwd
# /Treasury/Reports/Daily
ls ../Archive

That is a relative path. Now with absolute:

ls /Treasury/Reports/Archive

Both work right now. But only the absolute path will work reliably when your script runs on a scheduled task without a "current directory" context.

Running Python from the terminal

This is where the command line becomes your development tool, not just your filing system.

Open a terminal. Navigate to the folder where your script lives. Run it with:

python my_script.py

That is it. Python runs, your code executes, any output goes to the terminal, and any errors appear right there where you can read them. No dialog boxes, no "run" buttons, no IDE abstraction between you and what actually happened.

This matters more than it sounds. When you run a script through an IDE, the IDE is often cleaning up the environment for you. It sets paths, it buffers output, it catches certain errors. When you run from the command line, you see the actual Python process talking to your actual system. If your script needs a file that is not there, Python tells you immediately. If you forgot to install a package, the import fails right away. If the output is going somewhere you did not expect, you see it.

Create a small test script to see the difference:

import os
import sys

print("Current working directory:", os.getcwd())
print("Python path:", sys.executable)
print("Script location:", os.path.abspath(__file__))

Run this from the IDE. Notice what it prints. Now open a terminal, navigate to the folder, and run:

python test_script.py

The output is the same, but you are seeing it raw, without the IDE layer. You are also seeing it exactly as a scheduled task or a deployment process would see it. This is important. Your script has no guarantee about what the current working directory is unless your code sets it explicitly.

Working with scripts and arguments

Real work means real data. Your script needs to know what file to process, what date to report for, whether to run in test or production mode. In treasury, this is how you pass context to scripts that run on schedules and feed regulatory reporting workflows. This is where command line arguments come in.

Most Python scripting in treasury happens like this: a schedule kicks off a script and passes it some context. The script reads that context and acts on it. You build this with the sys module:

import sys

if len(sys.argv) < 2:
    print("Usage: python process_liquidity.py <date>")
    sys.exit(1)

report_date = sys.argv[1]
print(f"Processing liquidity report for {report_date}")

# Your actual work here

Run it from the terminal like this:

python process_liquidity.py 2024-01-15

The script receives 2024-01-15 as an argument. sys.argv[0] is always the script name. sys.argv[1] is the first argument you passed. sys.argv[2] would be the second, and so on.

This is how your batch processes work in real life. A scheduler (Windows Task Scheduler, cron on Linux, or something else) runs a command like the one above. Your script reads the arguments, finds the right files, does the work, and exits cleanly. If it fails, the scheduler catches the exit code and logs it.

You can also read data from stdin (standard input). This is less common in finance but it is powerful for pipelines. A command like this:

cat liquidity_positions.csv | python process_positions.py

Reads the CSV file and pipes it to your Python script. Your script reads from stdin:

import sys

for line in sys.stdin:
    print(f"Processing: {line.strip()}")

You probably will not use stdin much in treasury work, but it is good to know it exists. It is how Unix tools chain together to do complex work with simple pieces.

When the command line finds bugs your IDE missed

Take a concrete example. You write a script that reads a file:

import pandas as pd

data = pd.read_csv("positions.csv")
print(data.head())

This runs fine in your IDE. You have positions.csv in the same folder as your script. Now you put the script on a shared server and try to run it from a different folder:

cd /Treasury/Reports
python /Treasury/Code/my_script.py

It crashes. The script looks for positions.csv in the current directory, which is Reports, not Code. Your IDE was automatically running from the folder where the script lives. The actual environment is different.

Fix it with an absolute path:

import pandas as pd
import os

script_dir = os.path.dirname(os.path.abspath(__file__))
data = pd.read_csv(os.path.join(script_dir, "positions.csv"))
print(data.head())

Now the script finds the file no matter where you run it from. This is the kind of bug that only shows up when you leave the IDE. The command line forces you to think about it.

Another common issue: your IDE has a virtual environment active, so imports work. Your script runs fine. Then the scheduler runs it with the system Python, which does not have your packages installed. It fails on import. You never see this in your IDE because you are already set up.

Test by running from a terminal with your actual Python:

python my_script.py

If it works from the command line, it will work on the server. If it does not, you know to fix the environment or the imports before you deploy.

Next: the command line is where it gets real

The command line is not exciting. It is not a feature. It is a foundation. Every serious Python work you do in treasury, reporting, or any other finance function will run from the command line eventually. Getting comfortable with it now, while you are learning, saves you time and prevents your first production failure from being the moment you realised you did not understand file paths. When you move into running daily reconciliations or feeding data to your ICAAP systems, this is the skill that keeps things running.

The practical steps: open a terminal today. Navigate to a few folders using cd. List contents with ls. Create a folder with mkdir. Copy a file with cp. Write a small script that takes an argument and run it with python script.py arg1 arg2. These are not advanced skills. They are basic. But they are non negotiable.

Your next step is to read about reading a liquidity position with pandas, where you will put these command line skills to work on real financial data. You might also revisit the Python for finance basics if you want to ground yourself in why you are learning this in the first place.

The command line is not optional. It is where you work.