Pyinstaller打包的Mac终端脚本可执行文件无法在其他机器运行求助

Alright, let's break down why your script runs perfectly locally but fails on your colleague's Mac—this is a common pitfall, so we'll walk through fixes step by step:

1. Fix the PyInstaller Command (Possible Typo) #

First up: --oneapp isn't a valid PyInstaller flag. You probably meant either:

• --onefile: Packages everything into a single standalone executable
• --onedir: Creates a folder with the executable and all its dependencies

If you used the wrong flag, re-pack your script with the correct one first:

pyinstaller --onefile my_script.py

2. Fix "Opens in Text Editor" Issue #

This happens when Mac doesn't recognize the file as a Unix executable, or it lacks proper permissions. Here's how to fix it:

• Have your colleague open Terminal, navigate to the executable's directory, and run this to add execute permissions:

  chmod +x ./your_executable_name
  

• When they run the file, remind them to use ./ before the name (e.g., ./your_executable_name instead of just your_executable_name). Without this prefix, Mac might default to opening it as a text file.

3. Fix "No Output in Terminal" Issue #

If running the executable in Terminal does nothing, these are the most likely culprits:

a. Architecture Mismatch (Intel vs. Apple Silicon) #

If you're on an Apple Silicon Mac (M1/M2) but your colleague uses an Intel Mac (or vice versa), the executable might be built for the wrong chip. Package it as a universal binary to support both architectures:

pyinstaller --onefile --target-arch universal2 my_script.py

b. Hidden Missing Dependencies #

Even with --onefile, PyInstaller sometimes misses hidden dependencies. Have your colleague run the executable with verbose output to catch errors:

./your_executable_name --verbose

Alternatively, check the auto-generated log file—PyInstaller stores logs in ~/Library/Logs/[YourAppName]/ on Mac. Look for lines about missing modules or file path failures.

c. User Input Handling #

Since your script requires user input, make sure your colleague runs it directly from an existing Terminal window (not by double-clicking the executable). Double-clicking might open a temporary terminal session that has issues with input prompts. Also, verify that your script uses input() or sys.stdin correctly—avoid any hardcoded file paths that only exist on your machine.

d. Gatekeeper Blocking #

Mac's Gatekeeper often blocks unsigned executables. If your colleague sees a "cannot be opened because the developer cannot be verified" message, they can:

1. Go to System Settings > Privacy & Security
2. Scroll to the "Security" section and click "Open Anyway" for your executable
   If you have an Apple Developer account, you can sign the executable after packaging to avoid this:

codesign -s "Your Developer ID" ./your_executable_name

4. Test Locally First #

Before sending the executable to your colleague, test it on another Mac (or a virtual machine) to replicate the issue. This helps you rule out whether it's a packaging problem or a quirk of your colleague's setup.

内容的提问来源于stack exchange，提问作者Vetle Ottem Frantzvaag