/ 
Developer-Dashboard-2.17
/ Developer::Dashboard::Platform

NAME

Developer::Dashboard::Platform - platform and shell helpers for Developer Dashboard

SYNOPSIS

use Developer::Dashboard::Platform qw(
  native_shell_name
  shell_command_argv
  command_argv_for_path
);

my $shell = native_shell_name();
my @cmd = shell_command_argv('git status');

DESCRIPTION

This module centralizes the small amount of operating-system and shell awareness needed by Developer Dashboard so prompt integration, command execution, and extension loading can work across Unix-style systems and Windows Strawberry Perl installs.

FUNCTIONS

is_windows, native_shell_name, normalize_shell_name, shell_command_argv, command_in_path, is_runnable_file, resolve_runnable_file, command_argv_for_path, shell_quote_for

Platform and shell helpers used by the CLI and runtime.

PURPOSE

This module owns platform-specific command execution details. It resolves which file is runnable on the current operating system, decides how script paths should be turned into argv arrays, and smooths over Unix versus Windows command launch differences for the CLI and helper layers.

WHY IT EXISTS

It exists because command launch portability is a system concern. The dashboard has many staged helpers, hook scripts, skill commands, and Windows-oriented runners, and they all need one place that understands how to invoke a file correctly on the current host.

WHEN TO USE

Use this file when changing executable resolution, script-extension handling, PowerShell versus pwsh selection, or any bug where a helper runs on one platform but not another.

HOW TO USE

Call resolve_runnable_file, is_runnable_file, or command_argv_for_path before launching a file. Higher-level code should pass the resulting argv into system, exec, or open3 instead of guessing the platform rules itself.

WHAT USES IT

It is used by bin/dashboard, skill dispatch, hook execution, private helper staging, and platform-specific tests that cover Unix and Windows command launch semantics.

EXAMPLES

Example 1:

perl -Ilib -MDeveloper::Dashboard::Platform -e 1

Do a direct compile-and-load check against the module from a source checkout.

Example 2:

prove -lv t/07-core-units.t t/21-refactor-coverage.t

Run the focused regression tests that most directly exercise this module's behavior.

Example 3:

HARNESS_PERL_SWITCHES=-MDevel::Cover prove -lr t

Recheck the module under the repository coverage gate rather than relying on a load-only probe.

Example 4:

prove -lr t

Put any module-level change back through the entire repository suite before release.