Shell Programming and Scripting

hello,
Someone can help me with redirectors?
I am writing this script in bash enviroment on Fedora:

Code:

exec 4<> /dev/tcp/10.10.11.30/5000    #open socket in input/output
strings<&4 >file.txt &

I send file descriptor 4 to string command to purge data stream from special char while come from connection but if i try to redirect the output to >file.txt I get no data.

Without >file.txt stream is correctly processed and sent to video (stdout)
I have also tryed with tee command without success... where I am getting wrong?

Tnx in advantage

Moderator's Comments:

Please use code tags next time for your code and data.

I do not have a fedora, but does it work without the exec, just redirect the /dev/tcp/10.10.11.30/5000 as stdin to strings? I use "cat -vt" more often than 'strings' (more oriented to compiled objects), so I can see all the control characters, but printable. Timing can be touchy with a lot of tcp protocols. Since the shell opens the file.txt and strings just inherits fd 1, it may be reacting to that fd not being a terminal, but I never though of strings as having any terminal orientation, like a curses program - vim or cscope.

Using strace can tell you a lot about what is happening. You can strace a bash -c that does it all. Turn on all the options and point it at a file! It's an education!

Tnx DG, I will try, and answer you back if your way, can be an alternative solution to apply, anyway googling around, and, maybe, also well written on manual of stdout, it say that STDOUT is a buffered stream, so, it should write to file just each Carriage return, or in my case, when I kill STRING process...

Well, stdout in C is a FILE* and by default buffered. A FILE* is a fd plus a buffer and controls to say how full it is, inside a process. The > refers to fd 1, which is standard output. fd's are not buffered in any app-visible way, but databases and other paranoid things do fsync(), which is like an open-close, and flushes data some distance closer to the disk or network. Close will wait for the data to be written. Exit of a process will flush all FILE*. So, inside bash ">file.txt" is open( "file.txt", O_CREAT | O_APPEND) and then after forking the new process, close(1) the inherited standard out and dup2( new_fd, 1 ) so the new fd is now standard out, with an fd that survives exec(), then exec( new_cmd ). You can watch this on strace. The new_cmd can examine fd 1 with a variety of commands to see if it is a terminal and such, will automatically buffer it with a FILE* called stdout. The app can use stdout or ignore it and use fd 1 on a rawer level of i/o. Because of the buffer, if you switch, you fflush( stdout ) first. Strace cannot see FILE* actions on most machines and then only if you trace library calls, but it sees all fd activity.