C, Bash, and X: Strange, strange, strange

C, Bash, and X: Strange, strange, strange

Post by Charles Onsto » Tue, 11 Jul 1995 04:00:00

Here's an interesting problem for any Bash, C, and X gurus
out there.  Maybe it's not so strange after all, but
it sure has me boggling at the monitor.

I wrote a simple, simple C program called "stripcr" which
takes a filename as an argument, strips all of the additional
CRs and CTRL-Zs that DOS/OS2 appends to the files so that
certain UNIX apps can use them.

Here's the gist of it:

   while (--argc > 0)
        if((fp = fopen(*++argv, "rw")) == NULL){        
                        /*make backup copy code goes here*/
                        /*create temporary file code goes here*/
                        /*jump to conversion*/
                        /*move temporary file on top of original file*/

The copy is done using another routine:  copyfile(FILE *ifp, FILE *ofp)
and is simply:

    while((c = fgetc(ifp)) != EOF)

The moving of the file is done with copyfile() and unlink().

(The bottom line being, I am not using system() for anything).

Here's the problem:

  The program works great from a standard console login (not
using X).  It works no matter how many files I give it.

  However, if I am using X (openwin, fwvm..doesn't matter),
the program breaks.  It breaks because eventually
the file name it is working with gets corrupt.
If, however, I telnet to the local host from within a
window on X (say openwin), the program works perfectly.
(When using the shell directly from a window, the program works fine
with one or two files, but after so many it will start to break..)

This doesn't make any sense to me.

I am using the bash shell and have had the same results
using tcsh directly from a window (I've used both rxvt and xterm).

Here is a sample output from the program when it breaks:

whitehead:~/development/stripcr/test$ ./a.out *.c
./a.out: house.1.deck.c...house.1.deck.c done!
./a.out: house.1.deck2.c...house.1.deck2.c done!
./a.out: house.1.dining.c...house.1.dining.c done!
./a.out: house.1.entry.c...house.1.entry.c done!
./a.out: house.1.hall1.c...house.1.hall1.c done!
./a.out: house.1.hall2.c...house.1.hall2.c done!
./a.out: house.1.kitchen.c...house.1.kitchen.c done!
./a.out: house.1.lroom.c...house.1.lroom.c done!
./a.out: house.1.mroom.c..File was empty, skipping...
./a.out: house.1.nsit.c...house.1.nsit.c done!
./a.out:can't open hhouse.1.nsit.c

When it works normally, it will process all 50 some odd files..
I won't post the normal output as it would be superflous.
The first instance of the file name is the one it is reading from
and the second one is the one it is writing to in the
final stage of the program.

Where the program blows up on the "hhouse.1.nsit.c" file,
during normal execution (ie when done from the console or
from a telnet session) it should be processing a file called
"house.1.sroom.c" and then proceed from there...
There is no "hhouse.1.nsit.c" file and I have no
idea why it(*argv?) thinks there is.

Anyone know what is going on here?

I sure would like to know.

If necessary, I'll post the full source.

Confusedly yours,


P.S. I am fully aware there are other ways of doing
this using perl, bash, tr, etc..  I want to know
why this doesn't work the way it seems it should.

"It don't mean a thing, if it ain't got that swing!"  - Duke Ellington