Взагалі це залежить від ОС. Цілком можлива ситуація, коли програма повертає код, а ОС його не сприймає, і він відкидається.
Ну і розкажіть іще, як ви перевіряєте код виходу.

ОС:  Linux Mint 19.1 Tessa 64-біт, ядро Linux 4.15.0-54-generic x86_64

program test;
var exitcode:longint;
BEGIN
 Write('Enter exit code: '); Readln(exitcode);
 Halt(exitcode);
END.

Перевіряю код виходу bash-скриптом:

#!/bin/bash
./test
echo $?

До 255 все співпадає. Якщо ввести число більше 255 -- результат завжди 255.
Не можу повірити, щоб у linux коди виходу були настільки ж "кастровані" як в MS-DOS ...

Код виходу не обов'язково може використовуватися при виникненні помилки. Згадайте MS-DOS (тоді часто писали програми, антивіруси, наприклад, які в залежності від результатів виконання повертали різний код, що можна було використати для подальшого запуску інших програм).
Особисто я планував використовувати коди виходу для подальшого використання в bash-скриптах. Чому більше 255 ? В залежності від результатів виконання програми (а може бути отримано декілька результатів одночасно) встановлювався окремий біт в кодові виходу (з "питомою вагою" 1,2,4,8,16 ... і т.д., відповідно при декількох результатах в сумі виходило число значно більше 255 якщо бітів більше 8 ). Далі в скриптах ці біти відсіювалися по масці (наприклад, "$exitcode & 32"), і якщо біт був встановлений -- запускався необхідний сторонній процес.
Судячи з усього код виходу не вдасться використати, тому в мене виникла інша думка -- передавати числовий результат виконання програми через змінну середовища. От тільки як її створити з програми pascal -- я не знаю (отримати можна, є функція - GetEnv).
Можливо Ви підкажете ? Або порекомендуєте інший спосіб передати результат виконання в іншу програму ?
Не зрозуміло, тільки, на біса в Free Pascal передбачено тип для коду завершення аж цілий longint ?

ReAl випередив. Можна друкувати JSON з полями які хочемо, і тоді отримувати доступ наприклад через jq:

RES=$(echo '{"a": 1, "b": 300}') # тут в дужках виклик вашої програми
A=$(echo $RES | jq '.a') # так можна окремі поля отримати
B=$(echo $RES | jq '.b')

echo $A, $B

Тимчасово виплутався із ситуації слідуючим чином:
з програми створюю файл, назвемо його exitcodefile, куди записую код завершення програми, а в bash-скрипту читаю його вміст в змінну, яку потім аналізую як звичайно. Наприклад:

#!/bin/bash
read EXITCODE < exitcodefile
echo $EXITCODE

Все запрацювало так як хотілося, але можливо хтось підскаже кращий спосіб передачі результату виконання в інший процес.

Хоча... той підпорядкований скрипт теж може щось друкувати і куди воно полетить… Все одно тоді у файл писати.
Це треба шматок навколо рівнем вище, а тоді думати.

Так. А імена файлів не обов'язково мають використовуватися для іменування, в них можна невеликі дані зберігати... АЛЕ НАЩО? Як олімпіадну задачу чи при значній нестачі ресурсів це ще можна зрозуміти; але для реальної роботи?

Так, ранні версії DOS дуже погано працювали зі змінними та пайпами (та й надалі не дуже), а дискети були ДУЖЕ повільні, тому й доводилося використовувати такі збочення.

OUTPUT="$(./test 123)"
echo ${OUTPUT}

де сирець test виглядає приблизно як

begin
  writeln(ParamStr(1));
end.

Бо це bash ріже код помилки. Ви можете, ще раз, запитувати його через системний виклик waitid. Ну і навіть якби це була вада Linux, то все одно FPC багатоплатформовий.

Можете пояснити - якщо програма генерує сторінку, то що саме ви хочете передавати ще на виході? Яку інформацію?
stderr - не повірите - теж призначений для виведення інформації про помилки. У вас якась манія використовувати канали для інформації про помилки не за призначенням.

hadeix
Окрім стандартних пайпів типу stdout та stderr можна ще й свої власні створювати. Правда я щось не в курсі, як там баш з ними дружить.
Але взагалі, CGI - то дуже тормозний АПІ, і краще використовувати щось інше.