I can not image why . please help me. thanks
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Sounds like the command string you supplied to system(3) doesn't
parse in your shell. Correct the syntax and try again.
Jim Trocki <tro...@transmeta.com>
Computer System and Network Engineer
Transmeta Corporation
Santa Clara, CA
In article <7ji65o$ffp$1...@palladium.transmeta.com>,
Is this a runtime message or a compiletime message?
For the case it is a runtime message...the space (variable/static)
containing your comand might be corrupted. May be it's worth
a try to printf() it to screen before calling command.
Regards Rainer
In article <01beb197$2cbaf2e0$2f9bca95@samos_pc2>,
"Rainer Temme" <Rainer...@Cgk.Siemens.NoSpam.de> wrote:
> zho...@163.net wrote:
> > I use system () function in my program
> > but I got error message as:
> > : is not an identifier
> >
> > I can not image why . please help me. thanks
>
> Is this a runtime message or a compiletime message?
>
> For the case it is a runtime message...the space (variable/static)
It is a runtime error , And I am sure that the space is not
been corrupted before I call system () (with printf () :) )
But now, I have a very stupid method to avoid this error.
I use a simple daemon to call system(). :(
> containing your comand might be corrupted. May be it's worth
> a try to printf() it to screen before calling command.
>
> Regards Rainer
>
The shell executing your command ran into a problem and printed the error.
What does the string look like that you are passing to system()?
--
Bill Rausch
bill at numerical dot com
UNIX, Mac, Windows software development
Michael.
zho...@163.net schrieb:
> I use system () function in my program
> but I got error message as:
> : is not an identifier
>
> I can not image why . please help me. thanks
>
System() uses a shell to parse the string passed to it. Some
(all?) shells also parse the environment strings at startup
in addition to the command line. Something else in the program
has corrupted the environment space and this is making your
shell unhappy.
Les Mikesell
l...@mcs.com
>> > I use system () function in my program
>> > but I got error message as:
>> > : is not an identifier
>It is a runtime error , And I am sure that the space is not
>been corrupted before I call system () (with printf () :) )
In that case, it's probably a bad environment variable that the
shell is complaining about. You can print them out with a bit
of code something like this: (not tested)
extern char **environ;
char **p;
for (p = environ; *p != NULL; p++)
printf("%s\n", *p);
Each line of output should be of the form "name=value", where the
name only contains characters a-z, A-Z, 0-9 and _ (underscore).
Watch out for non-printing characters in the output. (E.g. use
cat -v to view it.) An empty string (blank line in the output)
would also cause the problem you a seeing.
--
Geoff Clare g...@unisoft.com
UniSoft Limited, London, England. g...@root.co.uk
This message comes from ancient (and arguably broken) versions of
the Bourne shell (/bin/sh) when one of the environment strings is
not of the form "identifier=value". The problem is that at startup,
this particular shell does the equivalent of:
extern char **environ;
char **pp, *p;
for (pp = environ; (p = *pp++) != NULL;)
if (export(p))
die();
where "export" is much like the user-level "export" command,
export A=foo
The "export" command demands that the thing on the left of the "="
sign be an "identifier"; examples of things that are *not* identifiers,
and are rejected, include:
export 1=4
export @=blah
In other words, the Bourne shell refuses to let you put these things
into the environment via Bourne shell commands. Suppose you somehow
sneak one in anyway, and start up a fresh copy of the Bourne shell --
what should it do then?
Modern versions apparently just keep the "1=4" and "@=blah"-style
environment variables around. The other obvious alternative is to
delete them at startup, especially since the shell's own variable-access
mechanism cannot get at them -- $@ and $1 always refer to the
positional parameters, never to the environment "@" and "1" variables.
(None of the utilities I have lying around will let me create an
environment variable that is not only not an identifier, but also
lacks an "=", and I am too lazy to write a special-purpose C program
to do it, so I am not sure what our /bin/sh does with those.)
The ancient "sh" you seem to be stuck with, though, not only prevents
the programmer from entering such variables on the command line,
but also aborts when presented with such variables in its startup
environment. Normally this is not a problem, since no one deliberately
exports such strings. Creation of these "bad environment variables"
is typically due to a bug in a C program, usually of the "write
through uninitialized pointer" form. Another popular way to create
them is to strcpy() over top of the argv[] strings without realizing
that those strings have a limited amount of room. In typical Unix
implementations, the environ strings reside just after the argv
strings.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA Domain: to...@bsdi.com +1 510 234 3167
http://claw.bsdi.com/torek/ (not always up) I report spam to abuse@.