RE: [Dev-C++] BC++, gcc and Win98SE shell

[<gi...@li...>]

Sorry for my previous post, it was not very clear.

Let me try again.

The test program is, this time, a little different:

/* echo.c */
#include <stdio.h>
int main(int argc, char *argv[])
{
    while (--argc > 0)
       printf("%s%s", *++argv, (argc > 1) ? " ": "");
    printf("\n");
    return 0;
}

IMHO the above is more or less equivalent to the program I posted before 
but I changed in the hope that Ioannis won't yell at me this time :-)

Anyway the program is not the point, it is just a mean to show that:
when I use a program compiled by gcc, it seems that the shell expands 
wildcards before invoking the program (as it should always be), instead 
when I compile the same program using BC++, the shell does not expand the 
wildcards.

To prove it, what I did was:
1. create a directory named c:\temp
2. used the program "touch" (a Borland tool) to create: c:\temp\foo.c and 
c:\temp\bar.c
3. switched to the directory c:\temp
4. issued the command: echo_g *.c

The ouput of the command was:

bar.c foo.c

This means that the shell expanded "*.c" into "bar.c foo.c", the two 
arguments were then echoed by the program "echo_g" (where the "_g" means 
compiled using gcc).

Instead if I use the version of echo compiled by BC++ (named "echo_b.exe"), 
that is, when step #4 becomes:

4. issued the command: echo_b *.c

The output is:

*.c

This means that the shell did not expand "*.c". Or, if you prefer, I have 
the same  ANSI C89 program give two different outputs, according to which 
compiler was used to build the executable. I have no explanation for this, 
other than there is some bug in the shell.

My questions are
1. Why is the Windows shell (or command.com, if you prefer) acting 
differently?
2. Is this happening on my Win98SE or is it happening on other versions of 
Windows too?


At 18:45 24/02/02 +0200, Ioannis Vranos wrote:
> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...] On Behalf
> > Of gi...@li...
> > Sent: Sunday, February 24, 2002 5:03 PM
> > To: dev...@so...
> > Subject: [Dev-C++] BC++, gcc and Win98SE shell
> >
> >
> > Hello list,
> >
> > here is one, funny, thing of which I have no explanation:
> >
> > consider the following program:
> >
> > /* echo.c */
> > #include <stdio.h>
> >
> > int
> > main(int argc, char **argv)
> > {
> >    while (--argc)
>
>  This decreases the number reported, which has no effect.
>
>
> >      printf("%s ", *++argv);
>
>Here you printf *after* you increment, that is you lose the first
>string.
>
>
>Now something delicate. argc is *not* guaranteed to be one if you do not
>pass any argument. It is guaranteed that if you pass an argument then it
>will be non zero and argv[0] will be the name of the program itself. In
>few words, if you do not pass any name it is not guaranteed that argv[0]
>contains the name of the program. As the C++ standard says:
>
>
>"An implementation shall not predefine the main function. This function
>shall not be overloaded. It shall
>have a return type of type int, but otherwise its type is
>implementationdefined.
>All implementations
>shall allow both of the following definitions of main:
>int main() { /* ... */ }
>and
>int main(int argc, char* argv[]) { /* ... */ }
>In the latter form argc shall be the number of arguments passed to the
>program from the environment in
>which the program is run. If argc is nonzero these arguments shall be
>supplied in argv[0] through
>argv[argc1]
>as pointers to the initial characters of nullterminated
>multibyte strings (NTMBSs)
>(17.3.2.1.3.2) and argv[0] shall be the pointer to the initial character
>of a NTMBS that represents the
>name used to invoke the program or "". The value of argc shall be
>nonnegative. The value of
>argv[argc] shall be 0. [Note: it is recommended that any further
>(optional) parameters be added after
>argv. ]".
>
>
>
>This is exactly the same for ANSI C89 and C99 too.
>
>
>
> >
> >    return 0;
> > }
> >
> > I compiled it using:
> > GNU gcc 2.95 shipped with Dev-C++ (gcc -o echo_g.exe echo.c)
> > BC++ 5.5 of thge "Borland free command line tools" (bcc32 -eecho_b.exe
> > echo.c).
> >
> > Then I've "touched" the files "foo.c" and "bar.c" and tried
> > the following:
> >
> >    command            output
> > echo_g *.c           bar.c foo.c
> > echo_b *.c           *.c
> >
> > All of this on Win98SE.
> > Is there somebody that can tell what is going on?
> > Is this bug(?) common to the shell of other Windows systems too?
>
>I do not understand what you did.
>
>
>
>Ioannis
>
>* Ioannis Vranos
>* Programming pages: http://www.noicys.d2g.com
>* Alternative URL: http://run.to/noicys
>

--
gisan
gi...@li...