Laravel目录结构最佳实践：自定义Shell脚本存放方式咨询

Great question! When working with Laravel, sticking to the framework's structure while organizing your custom shell scripts doesn't have to be tricky. Here are the most recommended approaches, aligned with Laravel's best practices:

1. Create a Root-Level scripts/ Directory #

This is the most straightforward and widely adopted approach. Laravel doesn’t restrict adding custom top-level directories for utility code, so a dedicated scripts/ folder keeps your shell scripts neatly separated from core application files.

• Why this works: It’s intuitive for other developers to find your scripts, keeps them out of framework-specific directories, and makes version control easy (just add the folder to your Git repo).
• Example structure:

  your-laravel-project/
  ├── app/
  ├── bootstrap/
  ├── config/
  ├── scripts/
  │   ├── backup-db.sh
  │   ├── process-uploads.sh
  │   └── sync-external-data.sh
  └── ...
  

• Calling from a controller: Use Laravel’s helper functions to reference the script path safely:

  $scriptPath = base_path('scripts/process-uploads.sh');
  // Sanitize user input to prevent command injection
  $sanitizedInput = escapeshellarg($userProvidedValue);
  $output = shell_exec("{$scriptPath} {$sanitizedInput}");
  
  // Log results for debugging
  Log::info('Script execution output:', ['output' => $output]);
  

• Important notes:
  • Ensure scripts have executable permissions: chmod +x scripts/*.sh
  • Never pass unfiltered user input directly to the script—always use escapeshellarg() or escapeshellcmd() to sanitize parameters.

2. Wrap Scripts in Artisan Commands #

If your scripts need to interact with Laravel’s services (like database connections, models, or logging), wrapping them in an Artisan command is a more Laravel-native approach.

• How to do it:
  1. Generate a new Artisan command: php artisan make:command RunBackupScript
  2. In the command’s handle() method, call your shell script (or even convert parts of the script to PHP using Laravel’s features):

     public function handle()
     {
         $scriptPath = base_path('scripts/backup-db.sh');
         $exitCode = 0;
         $output = [];
         
         exec($scriptPath, $output, $exitCode);
         
         if ($exitCode !== 0) {
             $errorMsg = implode("\n", $output);
             $this->error("Backup failed: {$errorMsg}");
             Log::error('Backup script error', ['details' => $errorMsg]);
             return 1;
         }
         
         $this->info('Backup completed successfully!');
         Log::info('Backup script executed without issues');
     }
     

  3. Call the command from your controller using the Artisan facade:

     Artisan::call('command:run-backup-script');
     $scriptOutput = Artisan::output();
     

• Why this works: You get access to all of Laravel’s tools (dependency injection, logging, configuration) and can run the script both via the controller and directly from the command line.

3. Use storage/app/scripts/ (For Generated/Non-Source Scripts) #

If your scripts are generated dynamically by the application (rather than being written manually), storing them in storage/app/scripts/ makes sense. This directory is meant for application-generated files, and it’s already configured in Laravel’s .gitignore (so you won’t commit temporary scripts to version control).

• Note: Avoid storing manually written scripts here—reserve this for runtime-generated files only.

General Security & Best Practices #

• Permissions: Ensure the web server user (e.g., www-data on Apache/Nginx) has execute permissions for your scripts, but avoid overly permissive settings like 777 (stick to 755 for scripts).
• Error Handling: Always capture and log script output/errors. Using 2>&1 in your shell command will redirect stderr to stdout, so you can catch all output:

  $output = shell_exec("{$scriptPath} 2>&1");
  

• Isolation: If possible, run scripts with limited privileges to minimize risk if something goes wrong.

内容的提问来源于stack exchange，提问作者user3201419