Choose source and runtime-data directories
Follow First run for a complete minimal run. These guides describe the verified Console 0.8.0 archive. Install ASPL 0.7.0 separately. Console checks a launch --aspl override, the saved executable and inherited PATH in that order. An invalid explicit or saved choice fails without fallback. Relative tool choices and relative or empty PATH entries use the original physical launch directory, independently of later cd. See tool selection and launch options.
Save source in an external editor or download an original example. Console requires a readable regular source target and permits symlinks. It does not read/cache source or filter suffixes; the selected ASPL tool decides which suffixes it supports. These supplied files ask for one line and greet it. Both vocabularies work in either documentation locale:
fn start_main() -> i64 {
print("Your name?\n");
let name: string = read_line();
print("Hello, " + name + "\n");
return 0;
}
Download original source hello-en.asplدالة ابدأ_الرئيسية() -> ص64 {
اطبع("ما اسمك؟\س").
دع اسم: نص = اقرأ_سطر().
اطبع("مرحباً، " + اسم + "\س").
أرجع 0.
}
Download original source hello-ar.asplConsole captures its usable current directory for every run, including an absolute source. Relative runtime data and TLS paths use that captured directory. Imports follow the canonical source location under the selected tool. Source location does not set the working directory, and the child cannot change Console navigation. For a program stored separately from its data, first use cd to reach the data directory, then run the absolute source path:
cd -- /home/samira/demo-data
run -- /home/samira/sources/demo.aspl
Replace these sample paths with existing paths for your program. The greeting examples above need no data files. For them, save a source in the Console current directory and submit one of these alternative commands:
run -- hello-en.aspl
تشغيل -- hello-ar.aspl
Each starts one run. A source supplied when launching Console only prefills a quoted absolute run -- draft; Enter validates and starts it. Missing/unreadable source, unusable directory or tool fails without starting a program. Correct the reported problem before submitting again. Console passes literal arguments equivalent to --diagnostic-language=ar|en --color=never run -- ABSOLUTE_SOURCE, inherits the environment and uses separate stdin/stdout/stderr pipes. It invokes no shell and accepts no extra compiler/program options. The diagnostic language stays fixed for that run. See run.
Read the run phases
The prompt label identifies the run and its phase. One active run owns it; another run is never queued.
| Phase | What you can do |
|---|---|
| Starting | Preparation and launch are pending. The prompt is read-only. Stop can request cancellation; EOF does nothing. |
| Running | Edit and submit program input while stdin is open. Output does not prove the program is waiting for input. |
| Sending | One submitted line is pending. The prompt is read-only; another Enter queues nothing. |
| Stopping | A Stop request is pending. Read/copy output while the prompt stays read-only. |
| Finalizing | Console finishes captured output and records the observed outcome. The prompt stays read-only. |
EOF can leave a run active with its prompt read-only. The command prompt returns only after confirmed launch cancellation or observed child exit and finalization. A five-second Still sending or Still stopping message describes pending work, not a completion deadline.
Check who owns input
Only a command-ready prompt parses Console commands. During a run, even ls, exit, settings and run are literal input for that program. Console cannot tell whether the child is waiting for read_line(). Look at its output and prompt ownership before sending text. For a greeting example, wait for its name question and enter:
Samira
F1 and Ctrl+, still open the keyboard reference and Settings during a run. Temporary text controls consume their local editing and cancellation keys first. Dismiss them before using main-view Stop or EOF. Program input never enters command history.
Finish composition before submitting
Committed draft text and unfinished input-method composition are separate. Enter confirms active composition first; a later Enter submits the committed line. For an incomplete Local Compose sequence, Enter retains and cancels the unfinished sequence; another Enter is needed to submit the unchanged committed draft.
Focus loss retains unfinished composition under its original owner and restores only the committed draft on return. On EOF, Stop or completion, nonempty committed unsubmitted text is retained once as an unsent program draft. Visible unfinished composition is retained separately. Neither enters the next command/run or command history.
If an input-route fault pauses editing, committed text and visible composition remain separate, and editing, paste and submission stop. Selection/copy and Settings stay available. Repair the stated problem, then explicitly Retry the input route in Settings. Retry starts fresh composition for the same intended route while keeping the committed draft. It does not replay keys, restore unfinished composition or send retained text. Missing helpers or loader dependencies need installation repair.
Route prerequisites and the full repair sequence are in Input methods. Settings explains applying a route choice and the separate save status.
Send a line and interpret delivery
Enter submits committed UTF-8 text with one added LF. An empty draft sends a blank line. Spaces, Unicode and NUL stay literal. The payload limit is 65,536 bytes, excluding the added LF. CR/LF in a draft or excess bytes are refused atomically, preserving committed text and selection. Paste never trims a trailing LF, splits lines or submits.
Only one line can be pending. It gets one submitted record, and the prompt stays read-only until writes drain into the OS pipe. After five seconds, Still sending means delivery remains pending. Pipe delivery does not prove the program read or acted on the line.
If writing fails or the run ends before delivery completes, that submitted record says delivery unconfirmed, even if some bytes reached the pipe. It is never replayed or relabelled as wholly unsent. A stdin failure can leave the child running with output readable and Stop available. Inspect the observed outcome and any effects before explicitly trying another run; resending could repeat work the program already received.
Close stdin with EOF
Ctrl+D closes program stdin after any pending submitted line drains. It does not send the current draft or a blank line. A nonempty unsubmitted draft and visible composition are retained separately. EOF does not Stop the program or close the window. The program decides how to handle closed stdin; Console keeps the prompt read-only until the run ends. EOF during Starting does nothing.
Use EOF when your program needs the end of its input stream. Use Stop when you want to request termination. If a line remains pending, EOF waits for it rather than bypassing delivery.
Request Stop or close the window
Ctrl+C requests Stop during Starting, Running, Sending or Stopping. It retains unsent work and requests SIGTERM, then SIGKILL after 1,000 ms if needed. Signals target the process group when available, with direct-child fallback. Repeating Stop does not restart escalation. After five seconds, Still stopping reports that the request remains pending.
Stop cannot retract delivered input or undo file/network effects. Descendants that escape the process group may survive. The signal deadline is not an exit deadline; confirmed launch cancellation or observed child exit is required before ownership is released. Keep reading the output and eventual outcome rather than assuming immediate termination or automatic retry.
Closing an active run offers Cancel or Stop and close. Cancel dismisses the close request and keeps the run. Stop and close waits for completion and the observed outcome. Closing during Stopping or Finalizing also waits for that outcome. See exit for the command-ready close action.
Read the observed outcome and recover
Each accepted run request records its source and current directory, then one observed terminal outcome, including status 0. An exit number alone does not establish success or a trap. Preflight, spawn, signal and supervision failures remain distinct. A Stop request is reported with the observed result without claiming an unproved cause.
stdout and stderr stay separately labelled; their ordering is not a chronological merge. Console finishes a bounded captured output prefix after direct-child exit without waiting for descendant-held pipe EOF. A counting, shortened-prefix or read failure reports incomplete capture as a Console process failure. Final output precedes the terminal record and command restoration.
The greeting examples should print Hello, Samira or مرحباً، Samira and report status 0. Check the output and outcome together. Completion restores an empty command prompt with fresh editing state, without moving focus away from output or temporary controls. Retained unsent drafts, unfinished composition and delivery-unconfirmed records stay with their old run. Review them and correct any reported source, directory, tool or input problem before an explicit new attempt.
For prolonged sending or stopping, follow pending-run recovery before considering another attempt.
Previous: First run. For file preparation and recovery, read Files and paths. For language lessons, use ASPL in English.