Хотя одна идея есть - создать ложную утилиту Y которая настучит зачем её вызывали, а как это сделать по другому?

>за это время в системном мониторе не разглядишь параметры командной строки с которыми она запущена.
А в ps aux тоже?

strace не помогает разве?

Пиши логи

Дампить /proc/*/cmdline

оберни в башсрикпт

log=logfile
program=/path/to/app
echo $@ >>$log

$program $@

Хотя одна идея есть - создать ложную утилиту Y которая настучит зачем её вызывали, а как это сделать по другому?

Так будет проще всего. Можно попробовать извратиться с systemtap, но навряд ли это будет оправдано.

ps aux - показал шишь, со strace консольная программа так запустилась что в ней не нажмёшь на кнопки - в консоли всё мелькает, пишется текст.

log=logfile
program=/home/user/zzz/./X
echo $@ >>$log

$program $@

А так?

Ctrl+Z – остановить текущую команду, продолжть с fg на переднем плане или bg в фоне

Напиши в консоли (applications->accessories->terminal, это если гном) «ps aux» и нажми ентер в момент выполнения программы Y. Потом покопайся в выводе ps'a и найди нужную программу(она будет ближе к концу). Либо оберни все в скрипт, как уже написали выше.

Застопь (SIGSTOP) процесс, а потом разглядывай ps или прямо /proc, сколько душе угодно.

>SIGSTOP

Или ^Z

>Или ^Z

Если оно форкнется, ^Z будет бесполезен.

Ctrl+Z это ненадёжно потому как действует не на всех. Также как и клик по крестику в углу окошка закрывает только те программы в которые встроена нужная реакция на это событие - в окнах на SDL это прописывается вручную. Пока «компилировал и отлаживал» хавку, снизошло озарение. Если редактор скомпилит чужой (лазарусный) код неработоспособным, но при этом будет отлавливать синтаксические и линковочные ошибки, то для кодоковыряния этого должно хватить. Для запуска программы, её можно пересобрать скриптом, это не долго.

>со strace консольная программа так запустилась что в ней не нажмёшь на кнопки - в консоли всё мелькает, пишется текст.

Надо запускать strace с выводом в файл, либо в одной консоли (терминале) запускаете свою программу, в другой смотрите её PID и запускаете

«strace -e process -o /tmp/strace.log -f -F -p ПИД-программы»

потом переключаетесь обратно на свою программу, делаете действия и в /tmp/strace.log будет перечислены все нужные вызовы (execve).

Тогда уж

strace -o /tmp/strace.log -f -F -p пид_программы

Если нужны только «узнать-то параметры», то зачем валить в лог все syscall'ы? Поэтому и "-e process".

редактор не вызывает компилятор а компилирует сам.

Что то бредово. Даже если учесть, что во времена перфокарт термин «редактор» обозначал «редактор связей» == «линковщик», то всё равно, бредово.

>Если нужны только «узнать-то параметры», то зачем валить в лог все syscall'ы? Поэтому и "-e process".

Ясно, я немного не понял и ломал голову над тем, какой параметр вписывать вместо слова process. Потому как одновременно запускать программу и заранее знать её пид, как-то не неправильно.

Что то бредово. Даже если учесть, что во времена перфокарт термин «редактор» обозначал «редактор связей» == «линковщик», то всё равно, бредово.

Всё нормально, это паскаль, здесь информация которая в си вынесена в сборочные скрипты и заголовки, по возможности встроена в исходники. Модули, разделяемые библиотеки и исходник программы сами знают во что им компилироваться без посторонних подсказок. Как говорится, на паскале можно написать всё, только это потребует огромных затрат. Нет ничего удивительного что для отладки кто-то встроил изменённую копию компилятора в редактор. По размеру исполняемый файл редактора больше компилятора, значит всё сходится - в большую матрёшку без проблем помещается меньшая. Религиозными запретами на goto авторы не злоупотребляли, стало быть могли написать и то что трудно представить, всё логично. Если не веришь, смотри сам http://freepascal.org/download.var Редактор называется fp, в 64 битной версии есть дополнительный баг, предположительно из-за кривизны сишных библиотек с которыми линкуется.