Hello all,

I have a problem. A client/server program I am writing (in C) uses sockets for internal communication. Normally this works fine, there is however one case that causes a serious problem.

On one system I need to run the client part of my program from a perl script. When I do so the socket my client opens to the server gets captured by the perl script and the data dumped to stdout. With the obvious result that my program stops working.

• It is not an option to run my program without the perl script, unfortunately.
• It is a serious time delay and cost involved in getting the perl script changed; that is if it can even be done.

Ideally I would like to be able to prevent my socket from being redirected to stdout. While I'm not new to programming, I am new to Linux programming and would appreciate any input regarding this. Can it be done (easily)? Either by some construct in my code, environment variables, options set on the socket, whatever.. I would hate to have to create a bash fork that refuses to redirect sockets.

If you feel that you need more information before you can give a relevant answer, please just ask.

Best regards,
Mans

> On one system I need to run the client part of my program from a perl script. When I do so the socket my client opens to the server gets captured by the perl script and the data dumped to stdout. With the obvious result that my program stops working.

Could you please explain this? You have a binary program that connects (connect(2) to a remote server via TCP -- but if you start your program from a Perl-script (with function system?), somehow its connections to the server gets kidnapped?! A bit hard to believe.

Sure! I do have a binary program which first opens a socket (socket(2); PF_INET, SOCK_STREAM) and then connects (connect(2); 127.0.0.1, dynamic ports) to the server. The server in this instance is not remote, it is local on the same machine. I must admit I have not tried having it on a remote machine.

What function the perl script uses to start the binary is currently unknown, it's huge and I haven't gotten to the bottom of it yet. It is object oriented and pretty hard to follow... Just to be clear, it's not any perl script that causes this bahavior - if I write a short, script that does more or less nothing but start my binary it works fine - it's this particular perl script that does something weird and I need to figure out what and how to stop it.

I know it is a bit hard to believe. I know I wouldn't unless I was sitting here staring at the results. Actually I'd even say more than a bit hard, but then I often see "the power of redirection on the command line" as an example of why *nix is so wonderful, I can only assume it is this power being wielded here without thought of the end result. I might assume wrong though, but the fact is - commands that should only pass between client and server are dumped to stdout and the perl script's log file and never reach the server.

probably you need to show us that perl script, or find the relevant part. There can be a proxy or ?? you can try lsof or strace to check what that perl program tries to do. Actually you have no chance to check what is going on at the other side of the socket, but you may have a chance to check if it was a socket or a terminal (isatty)