Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG  Not logged in ELOG logo
icon4.gif   CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Tue Feb 14 16:22:56 2006 
    icon2.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Tue Feb 14 17:43:15 2006 
       icon2.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Tue Feb 14 22:31:08 2006 
          icon2.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Wed Feb 15 18:25:15 2006 
             icon2.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Wed Feb 15 19:02:32 2006 
                icon2.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Fri Feb 17 13:31:00 2006 
                   icon7.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Mon Feb 20 17:50:33 2006 
Message ID: 1697     Entry time: Wed Feb 15 19:02:32 2006     In reply to: 1696     Reply to this: 1698
Icon: Reply  Author: Steve Jones  Author Email: steve.jones@freescale.com 
Category: Bug report  OS: Other  ELOG Version: 2.6.1 
Subject: Re: CONCERN: Cross-platform compiling at risk 

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:
Question: Is the functionality really just to issue an arbitrary command-string to a "shell" and have the result stuffed back into an eLog variable? I'm not an expert but it would seem that such a feature would be universally available or could be used to construct a suitable routine.

If possible, could one use the
int system(const char *s);
function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps
char *tmpnam(char *s);
, running a command via
int system(const char *s);
, then opening that file for a read would accomplish what is being desired?


Indeed the results from the "shell" need to be stuffed back into an elog attribute, that's why you cannot use the system() function directly. The idea with the tmpnam() could however be a clever workaround. I have to see if this works under Windows. If so, it would be a much more portable alternative to forkpty().



Yes, these routines are from the standard C libraries. tmpname() returns a pointer to a filename guaranteed to be unique, then you can create that file. tmpfile() actually creates a temporary file and returns a pointer to the filestream, and auto cleans up upon stream termination. system() passes the command string to the shell/commandproc if available. You could wrap these into a single callable function that is called 'shell()' and accomplish your first gola plus achieve cross-platformness again ;->

My 2 cents - hope that is enough!
ELOG V3.1.5-fe60aaf