Introduction

If a script or training job runs long enough that you stop watching it, an audible alert at completion can be more useful than another log line. The implementation is usually simple: run the task, then trigger a system beep, play a sound file, or speak a message when the work ends. The best method depends on the operating system and whether you want a built-in alert or a custom sound.

The Simplest Pattern

The general structure is:

1. do the work
2. when it finishes, trigger a sound

A Python example with a plain terminal bell:

1import time
2
3print("Starting work...")
4time.sleep(5)
5print("Done")
6print("\a")

The \a character asks the terminal to ring the bell. This is lightweight, but it depends on terminal and system settings. Some terminals ignore it.

Windows Example With winsound

On Windows, winsound is a simple built-in option.

1import time
2import winsound
3
4print("Working...")
5time.sleep(5)
6winsound.Beep(1000, 700)

Or play a system sound:

import winsound
winsound.MessageBeep()

This is often the easiest reliable approach on Windows machines.

macOS and Linux Command-Line Alerts

If you are using shell scripts, the operating system may already provide tools you can call at the end.

macOS example:

python train.py && say "Training finished"

Linux example with a WAV file player:

python train.py && paplay /usr/share/sounds/freedesktop/stereo/complete.oga

Or a generic terminal bell:

python train.py; printf '\a'

This is often good enough when you want the notification outside the program rather than inside it.

Custom Sound File in Python

If you want a custom sound rather than a simple beep, you can call a system player or use a library appropriate to your platform.

A subprocess approach keeps the code simple and explicit:

1import subprocess
2import time
3
4print("Running...")
5time.sleep(5)
6subprocess.run(["afplay", "/System/Library/Sounds/Glass.aiff"], check=False)

That example is macOS-specific because it uses afplay, but the pattern generalizes to any platform-specific sound player.

Add It to Existing Workflows

The alert can live inside the script:

1def main():
2    # long-running work here
3    pass
4
5
6if __name__ == "__main__":
7    main()
8    print("\a")

Or outside the script in the shell:

python my_script.py && printf '\a'

External notification is nice when you do not want to edit the script itself.

Prefer Clear Signals for Long Jobs

For very long-running jobs, a sound alone may not be enough. In practice, many developers combine sound with:

• a desktop notification
• a terminal message
• a log entry
• an email or chat alert for remote jobs

The right level of notification depends on whether the code runs locally or on a remote machine you are not actively watching.

Common Pitfalls

A common mistake is relying on the terminal bell without checking whether the terminal or operating system has audible alerts disabled.

Another issue is using a platform-specific sound command such as afplay or winsound in code meant to run unchanged on multiple operating systems.

Developers also sometimes put the notification only in the success path and forget that failures may also deserve an alert.

Finally, for remote jobs running on a server, a local sound on the server is often useless. In those cases, use a remote notification channel instead.

Summary

• The basic pattern is simple: run the code, then trigger a sound at the end.
• '\a is the lightest option, but it is not always audible on every terminal.'
• Windows can use winsound, while macOS and Linux often rely on shell audio tools.
• Shell-level alerts are useful when you do not want to modify the program.
• For long or remote jobs, combine sound with a more explicit notification channel when needed.