With the advent of Debian6 fpc 2.4.0-2 has become the only available version. Before that, it may have been 1.0 ?
A simple program of mine compiled in 2008 with the old fpc , when started with xterm -e program still runs fine today.
Now. the new compiler warns about SHELL function being deprecated and link.res containing output sections but finishes.
Though the produced binary runs as expexted when run in an xterm, using the method of xterm -e program does not [ this is the method of starting the program through the X11 twm-menu, which should come up with a new xterm-window] : I only see a short flicker of an xterm-window then disapearing; there's no error message.
Would anyone have an idea what's wrong?

max wrote

With the advent of Debian6 fpc 2.4.0-2 has become the only available version. Before that, it may have been 1.0 ? A simple program of mine compiled in 2008 with the old fpc , when started with xterm -e program still runs fine today.

What are you trying to say: that before 2.4 you were using 1.0?

Now. the new compiler warns about SHELL function being deprecated and link.res containing output sections but finishes.

Not sure about the first, I believe the second is the usual behaviour and can be ignored.

[Slightly later] I think I can see similar behaviour if running on a local system, running over ssh (which is what I first tried) changes things.

Try running xterm from a (local) shell, and look at the output. If it's

No absolute path found for shell: XXXXXXXXXXXXX

then invoke the program with an absolute path (i.e. not relying on the PATH shell variable), or if you're in the current directory make sure you put ./ in front of it. I don't know why this should depend on the version of FPC used.

Hi Max,

I haven't used Shell(), and I am sure others can help you there. However, I can think of at least two alternatives:
1. Use pexec() directly
2. Use TProcess or TUTF8Process.

Thank you,
Noah Silva

2012/2/28 max

Thank you for your tips and suggestions.
It seems that FPSYSTEM from rtl-Sysutils is the 1:1 replacement for the old SHELL function but that made no difference to my problem. I dug out the previsious fpc version 1.9.4 from archive.debian.org which fortunately could be installed [for how long?] and hey presto: the good old xterm -e <program> runs again.

Can you put a sleep behind it to see the error message? xterm -e "./project1 ; sleep 10"

I cannot imagine how the version of the compiler can have any influence on that. Either the compiled program runs on your system or it doesn't your program maybe simply crash because you are relying on the existence of some shell variables that are not always guaranteed to exist and you have not implemented a graceful fallback mechanism? The subject of your post implies that *any* program will not run in an xterm but maybe its only *your* program?

2012/3/4 Bernd :

Can you put a sleep behind it to see the error message? xterm -e "./project1 ; sleep 10"

And also do the following:

env > env_interactive.txt
xterm -e "env > env_non_interactive.txt"

and then compare the two files. If important environment variables are missing in the non-interactive shell then you should file a bug against the twm project, most likely they have somehow messed up some of their login scripts.

Done what you suggested:
program runs again via xterm -e "program ; sleep 0 " with fpc 2.4.0; however no error message; same with 'sleep 10' !
So Thank You very much for that, Bernd !
Without the appended '; sleep ' just the flicker. env: only difference is SHLVL , namely =4 for interactive vs. =5 non-interctive which is irrelevant to my prog.

Your suggestion that only MY programs won't run when started with xterm -e ... is true indeed:
they all [ I only have a handfull though] run in an xterm but none will when started through xterm -e.
Except: when they are compiled with fpc <=1.9.4 OR I append your ';sleep ' after the program name.

2012/3/4 max :

Done what you suggested: program runs again via xterm -e "program ; sleep 0 " with fpc 2.4.0; however no error message; same with 'sleep 10' ! So Thank You very much for that, Bernd !

This is strange. Actually the suggestion to put a sleep behind it was never meant to fix the problem, it was only meant to keep the xterm open a few more seconds to read any error message that *might* occur when your program refuses to run.

What kind of programs are you writing? Did you also try some extremely simple programs like for example:

begin
  writeln('hello world');
  readln;
end;

2012/3/5 Bernd :

it was only meant to keep the xterm open a few more seconds to read any error message that *might* occur when your program refuses to run.

you can also try the following (more elegant):

xterm -hold -e yourprogram

without the sleep. This would hold the xterm window open, no matter what error happens while trying to execute "yourprogram". Because normally the xterm will close immediately when the command executed by -e finished. Maybe your program exits normally and is just too fast to see the output?

You seem to know your way around, Bernd, don't you! Well, I've tried xterm -hold -e /my/program :
the xterm-window pops up and stays with nothing in it at all: no error and no program output [which should be there]: seems to me that the program isn't being run at all! That is if it is compiled with fpc 2.4.0 Compiled with fpc 1.9.4 there indeed is the usual program putput ! My prog. uses the crt,unix,keyboard units from rtl, does some disk i/o and some window x/y cursor positioning.
It's supposed to run on a console so it needs the xterm in X11 . With your suggested 'Hello World' prog there is no difference between fpc 1.9 and 2.4 and this works.

But do not bother any longer, Bernd: you've shown me a way around [ even if you've never intended this ] and I'm happy with that.

My general wish for the compiler programmer would be that old versions would still be available and installable in the future as new versions sometimes show strange behaviours on old prorgams [ this has happened before when the internal representations of real numbers were altered leaving my old data files unreadable]

They generally remain available. However, versions prior to 2.2.2 had to be removed because they contained code that may have been copied (or at least heavily based) on code from the Delphi or Kylix RTL.

[ this has happened before when the internal representations of real numbers were altered leaving my old data files unreadable]

The internal representation of real numbers has never been changed in FPC. FPC's "real" type is different from the emulated 6 byte "real" type in Turbo Pascal, but it always has been different.

Jonas

Hmm... so it might be that there was some change in the Crt or Keyboard unit that changed the behavior.

Releases older then (AFAIK) 2.2.2 were removed, because of possible copyright infringement. This might apply to 1.9.4 as well.

Regards,
Sven

Jonas Maebe-2 wrote

The internal representation of real numbers has never been changed in FPC. .

I may have expressed myself incorrectly, but there was the case when records of real numbers written to disk by a program compiled with fpc 1.0.4 , when read back by the same program compiled with fpc 1.9.4 were displayed completely wrong.
I had a conversation about this back in 2006 with Michael van Canneyt when he thought that the 'alignment' in a record might have changed and advised of using only packed records in the future.
I was only able to recover this by using the 2 versions of the fpc.