8c17396285
This commit improves the management of script execution process by enhancing the way terminal commands are handled, paving the way for easier future modifications and providing clearer feedback to users when scripts are cancelled. Previously, the UI displayed a generic error message which could lead to confusion if the user intentionally cancelled the script execution. Now, a specific error dialog will appear, improving the user experience by accurately reflecting the action taken by the user. This change affects code execution on Linux where closing GNOME terminal returns exit code `137` which is then treated by script cancellation by privacy.sexy to show the accurate error dialog. It does not affect macOS and Windows as curret commands result in success (`0`) exit code on cancellation. Additionally, this update encapsulates OS-specific logic into dedicated classes, promoting better separation of concerns and increasing the modularity of the codebase. This makes it simpler to maintain and extend the application. Key changes: - Display a specific error message for script cancellations. - Refactor command execution into dedicated classes. - Improve file permission setting flexibility and avoid setting file permissions on Windows as it's not required to execute files. - Introduce more granular error types for script execution. - Increase logging for shell commands to aid in debugging. - Expand test coverage to ensure reliability. - Fix error dialogs not showing the error messages due to incorrect propagation of errors. Other supported changes: - Update `SECURITY.md` with details on script readback and verification. - Fix a typo in `IpcRegistration.spec.ts`. - Document antivirus scans in `desktop-vs-web-features.md`.
47 lines
2.0 KiB
TypeScript
47 lines
2.0 KiB
TypeScript
import { PosixShellArgumentEscaper } from './ShellArgument/PosixShellArgumentEscaper';
|
|
import type { CommandDefinition } from '../CommandDefinition';
|
|
import type { ShellArgumentEscaper } from './ShellArgument/ShellArgumentEscaper';
|
|
|
|
export class MacOsVisibleTerminalCommand implements CommandDefinition {
|
|
constructor(
|
|
private readonly escaper: ShellArgumentEscaper = new PosixShellArgumentEscaper(),
|
|
) { }
|
|
|
|
public buildShellCommand(filePath: string): string {
|
|
return `open -a Terminal.app ${this.escaper.escapePathArgument(filePath)}`;
|
|
/*
|
|
📝 Options:
|
|
`child_process.execFile()`
|
|
"path", `cmd.exe /c "path"`
|
|
❌ Script execution in the background without a visible terminal.
|
|
This occurs only when the user runs the application as administrator, as seen
|
|
in Windows Pro VMs on Azure.
|
|
`PowerShell Start -Verb RunAs "path"`
|
|
✅ Visible terminal window
|
|
✅ GUI sudo prompt (through `RunAs` option)
|
|
`PowerShell Start "path"`
|
|
`explorer.exe "path"`
|
|
`electron.shell.openPath`
|
|
`start cmd.exe /c "$path"`
|
|
✅ Visible terminal window
|
|
✅ GUI sudo prompt (through `RunAs` option)
|
|
👍 Among all options `start` command is the most explicit one, being the most resilient
|
|
against the potential changes in Windows or Electron framework (e.g. https://github.com/electron/electron/issues/36765).
|
|
`%COMSPEC%` environment variable should be checked before defaulting to `cmd.exe.
|
|
Related docs: https://web.archive.org/web/20240106002357/https://nodejs.org/api/child_process.html#spawning-bat-and-cmd-files-on-windows
|
|
*/
|
|
}
|
|
|
|
public isExecutionTerminatedExternally(): boolean {
|
|
return false;
|
|
}
|
|
|
|
public isExecutablePermissionsRequiredOnFile(): boolean {
|
|
/*
|
|
On macOS, a script file without executable permissions cannot be run directly by its path
|
|
without specifying a shell explicitly.
|
|
*/
|
|
return true;
|
|
}
|
|
}
|