Re: [gccsdk] stderr 2 file advantage

2012-12-20 Thread Ron 
In message 1ad80b0153...@hobbes.bass-software.com
  John Tytgat john.tyt...@aaug.net wrote:

 In message 5b44d00053.b...@ron1954.woosh.co.nz
   Ron b...@woosh.co.nz wrote:
 
  In message 6cddca0053...@hobbes.bass-software.com
John Tytgat john.tyt...@aaug.net wrote:
  
   In message f2d8c70053.b...@ron1954.woosh.co.nz
 Ron b...@woosh.co.nz wrote:
   
I'm not using the very latest crosscompiler, but I think this will be
unchanged.
Using my port of tar

tar -xvf ztmp.tar

stops with UnixLib detected recursion of signal SIGSEGV.  Exiting. 
when I encounter a pax format tar, (unless I specify --format=pax)

I set about trapping the error (in an obey file way) by using

tar -xvf ztmp.tar 2 errlog 

so I could check a file for an error.

But when I do this, the program /does/ create the file errlog,
but it remains empty, and tar now continues on and extracts the
pax format tar perfectly as if --format=pax has been used!

A good result, but it raises the question why, and does stderr
always need to be directed somewhere for better behaviour?
   
   Are you launching tar straight from CLI ? Or is this in a fork()/exec()
   /system() done ?
  
  Either from an Obey file or from the CLI in a taskwindow, same result.
  From memory,fork() is only used for the multipart tar activity.
  
  Directing stderr to stdout works equally as well.
  
  tar -xvf ztmp.tar 21
 
 Very bizar, looks like a real bug somewhere but someone needs to dig into
 this as I don't think we can just guess it based on above facts only.
 
 John.

Ok, looking out for the same result from a port other than tar would at
least confirm it as a unixlib bug.
The only major change I make to tar is setting the constant for ,xyz
filetyping.
There is a clash with gettimeofday, and I use the unixlib version,
but it worked using the one in the source also.
I have been changing fork() for vfork() for multipart tars, but the 
similar error I was encountering there may not be an issue now.

Thanks, Ron M.  

___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] stderr 2 file advantage

2012-12-20 Thread Ralph Corderoy 
John wrote:
  Very bizar, looks like a real bug somewhere but someone needs to dig
  into this as I don't think we can just guess it based on above facts
  only.

Perhaps there's something up with stderr, file descriptor 2, and that
causes the first signal the handling of which wobbles because it would
like to use stderr?

Is there something on RISC OS like strace(1) now?  On Linux, one can see
tar doing things like GET_FD on FD 2 early on, with, for example, an
opening of /dev/null if it's a bad file descriptor.

tar -xvf foo.tar 2-

Cheers, Ralph.

___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK