I'm developing Pyxis (https://github.com/Stasshe/Pyxis-CodeCanvas),
a browser-based IDE designed primarily for iPad. *Since WebContainer doesn't work reliably on iPad*, I had to build everything from scratch, including a complete shell system.
*What I've implemented so far:*
Our StreamShell architecture supports:
- Pipeline processing with true streaming (`cmd1 | cmd2 | cmd3`)
- Full redirection support (`>`, `>>`, `<`, `2>&1`, custom fd like `3>file`)
- Control structures (`if/then/else`, `for/while` loops, `break/continue`)
- Variable expansion (`$VAR`, `$(command)`, `$((arithmetic))`)
- Logical operators (`&&`, `||`) with short-circuit evaluation
- Background execution (`cmd &`)
- Process abstraction with signal handling
- Node.js Stream API for backpressure handling
- Most common Unix commands (`ls`, `cat`, `grep`, `head`, `tail`, etc.)
- Script execution (`.sh` files with full control flow)
*Technical approach:*
- Process abstraction using Node.js PassThrough streams
- File descriptor management via Map structures
- AST-based command parsing
- Per-fd buffering strategy
- IndexedDB-based virtual file system
- *Pure JavaScript/TypeScript implementation - no WASM, no WebContainer*
- Runs entirely in the browser main thread with timeout protection
*Current limitations:*
- Some advanced bash features not yet implemented (shell functions, process substitution, heredocs)
- No `*` recursive globbing
- Simplified job control
- Browser environment constraints (no native modules, all async)
- Single-threaded execution (no Web Workers for commands)
*My questions:*
1. *Is this approach sufficient for a practical shell environment?* Are there critical POSIX features I'm missing that would make this unsuitable for real-world use on iPad?
2. *Are there fundamental design flaws in my implementation?* Particularly concerned about:
- The fd management strategy (Map-based with PassThrough streams)
- Stream-based pipeline processing and backpressure handling
- Memory efficiency with large data flows
- The parser's handling of edge cases and quote processing
- Timeout-based protection vs. proper cancellation
3. *What would you prioritize next?* Given the constraints of:
- Browser-only environment (no server, no WebContainer)
- iPad compatibility requirement
- Must work offline
- Limited to what IndexedDB + browser APIs can provide
4. *Alternative approaches?* Are there better architectural patterns for implementing a POSIX-like shell in a pure browser environment that I should consider?
*Why not WebContainer?* WebContainer is an excellent technology, but it has significant limitations on iPad/iOS Safari - SharedArrayBuffer restrictions, memory constraints, and reliability issues make it unsuitable for our use case. We need a solution that works consistently across all platforms, especially mobile.
I'd appreciate any feedback from those who have experience with shell implementation, browser sandboxing, or building development tools for constrained environments like iPad.
d3Xt3r•1h ago
Cool project! But the name is a bit misleading, I thought you were talking about Ptyxis[1], the new terminal for GNOME.
Stasshe•1h ago
*What I've implemented so far:*
Our StreamShell architecture supports: - Pipeline processing with true streaming (`cmd1 | cmd2 | cmd3`) - Full redirection support (`>`, `>>`, `<`, `2>&1`, custom fd like `3>file`) - Control structures (`if/then/else`, `for/while` loops, `break/continue`) - Variable expansion (`$VAR`, `$(command)`, `$((arithmetic))`) - Logical operators (`&&`, `||`) with short-circuit evaluation - Background execution (`cmd &`) - Process abstraction with signal handling - Node.js Stream API for backpressure handling - Most common Unix commands (`ls`, `cat`, `grep`, `head`, `tail`, etc.) - Script execution (`.sh` files with full control flow)
*Technical approach:* - Process abstraction using Node.js PassThrough streams - File descriptor management via Map structures - AST-based command parsing - Per-fd buffering strategy - IndexedDB-based virtual file system - *Pure JavaScript/TypeScript implementation - no WASM, no WebContainer* - Runs entirely in the browser main thread with timeout protection
*Current limitations:* - Some advanced bash features not yet implemented (shell functions, process substitution, heredocs) - No `*` recursive globbing - Simplified job control - Browser environment constraints (no native modules, all async) - Single-threaded execution (no Web Workers for commands)
*My questions:*
1. *Is this approach sufficient for a practical shell environment?* Are there critical POSIX features I'm missing that would make this unsuitable for real-world use on iPad?
2. *Are there fundamental design flaws in my implementation?* Particularly concerned about: - The fd management strategy (Map-based with PassThrough streams) - Stream-based pipeline processing and backpressure handling - Memory efficiency with large data flows - The parser's handling of edge cases and quote processing - Timeout-based protection vs. proper cancellation
3. *What would you prioritize next?* Given the constraints of: - Browser-only environment (no server, no WebContainer) - iPad compatibility requirement - Must work offline - Limited to what IndexedDB + browser APIs can provide
4. *Alternative approaches?* Are there better architectural patterns for implementing a POSIX-like shell in a pure browser environment that I should consider?
The full technical documentation is available here: [SHELL-SYSTEM.md](https://github.com/Stasshe/Pyxis-Client-Side-Code-Editor/blo...)
*Why not WebContainer?* WebContainer is an excellent technology, but it has significant limitations on iPad/iOS Safari - SharedArrayBuffer restrictions, memory constraints, and reliability issues make it unsuitable for our use case. We need a solution that works consistently across all platforms, especially mobile.
I'd appreciate any feedback from those who have experience with shell implementation, browser sandboxing, or building development tools for constrained environments like iPad.