Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 604 of 807  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Hide attachments  Show only new entries    6456 Entries 
Goto page Previous  1, 2, 3 ... 603, 604, 605 ... 805, 806, 807   Next  
ID Datedown Icon Author Author Email Category OS ELOG Version Subject
  1703   Tue Feb 21 21:01:22 2006 Reply Steve Jonessteve.jones@freescale.comQuestionAll2.6.1Re: svn revision number in the source

Stefan Ritt wrote:

Steve Jones wrote:
There is a variable $Id$ in source that looks like it is supposed to reflect the svn revision number of the compiled code. How is this supposed to be set, manually just before compiling?


It gets set automatically on every commit to the Subversion repository.


So, when we go to the download section and download directly from there, that is not "committed" source? I ask because the revision id there is not set to anything that I can see.
  1702   Tue Feb 21 20:24:18 2006 Reply Stefan Rittstefan.ritt@psi.chQuestionAll2.6.1Re: svn revision number in the source

Steve Jones wrote:
There is a variable $Id$ in source that looks like it is supposed to reflect the svn revision number of the compiled code. How is this supposed to be set, manually just before compiling?


It gets set automatically on every commit to the Subversion repository.
  1701   Tue Feb 21 19:25:28 2006 Question Steve Jonessteve.jones@freescale.comQuestionAll2.6.1svn revision number in the source
There is a variable $Id$ in source that looks like it is supposed to reflect the svn revision number of the compiled code. How is this supposed to be set, manually just before compiling?

Thanks!
  1700   Mon Feb 20 17:52:06 2006 Smile Steve Jonessteve.jones@freescale.comQuestionOther2.6.1Re: compiling elog 2.6.1 on solaris platform

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:
BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS.


Ok, what about adding:
ifeq ($(OSTYPE),SunOS)
OSTYPE=solaris
endif



Steve Jones wrote:

That would work, but my question is "why is this statement needed at all?" In GNU-land it appears that the make utilities use the canonical names rather than the ones returned by the OS. When I simply comment out this section, the solaris compile works fine. Perhaps it does not on other platforms?

Also, I ran into another snag. The include file "pty.h" does not appear to exist in solaris-land, so I am seeing if there is one made available elsewhere.


In working with Stefan changes were made so that the latest release should once again cross-compile fine, and Makefile also works under Solaris. Great job Stefan!
  1699   Mon Feb 20 17:50:33 2006 Smile Steve Jonessteve.jones@freescale.comBug reportOther2.6.1Re: CONCERN: Cross-platform compiling at risk

Stefan Ritt wrote:

Steve Jones wrote:
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?


I implemented exprimentally such a code. Instead of tmpnam() (which the compiler claims to be obsolete), I use a hard-wired file name /tmp/elog-shell for that purpose. I put it under /tmp so that the "elog" user (under which elog should normally run) is able to write to. Can you please check if that works fine now under Solaris?



The compiled version runs fine under Solaris9. When executing Subst Subject = $shell(uname) I got:

"SunOS" !!! ;->

So, short of the items I pointed out below I would say that you have successfully re-rendered eLog as a truly cross platform application once again! My hat is off to you!


thanks

Steve
  1698   Fri Feb 17 13:31:00 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.1Re: CONCERN: Cross-platform compiling at risk

Steve Jones wrote:
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?


I implemented exprimentally such a code. Instead of tmpnam() (which the compiler claims to be obsolete), I use a hard-wired file name /tmp/elog-shell for that purpose. I put it under /tmp so that the "elog" user (under which elog should normally run) is able to write to. Can you please check if that works fine now under Solaris?
  1697   Wed Feb 15 19:02:32 2006 Reply Steve Jonessteve.jones@freescale.comBug reportOther2.6.1Re: 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!
  1696   Wed Feb 15 18:25:15 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.1Re: CONCERN: Cross-platform compiling at risk

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().
Goto page Previous  1, 2, 3 ... 603, 604, 605 ... 805, 806, 807   Next  
ELOG V3.1.5-3fb85fa6