% Save the sample XML document.
xmlFileName = [filename];
% % for octave you need the octave_xmltoolbox (C) 2007 Thomas Geiger
% % http://wiki.octave.org/wiki.pl?XMLToolboxPort % xml_struct = octave_struct2xml( xml_struct, rootName );
% xml_save( filename, xml_struct, 'any' );
% xml_toolbox is buggy (sequence of elements is not preserved)
fid = fopen( filename, 'w' );
fprintf( fid, '<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>\n'
fprintf( fid, octave_struct2xml_2(xml_struct,rootName,'') );
fclose( fid );
> the following code has a runtime error at line 20 which is about fid
> It seems to me that "fid = fopen( filename, 'w' );" is not successful
> this returns -1
> Installing io package also does not help to eliminate this error.
> Any advice ?
This has nothing to do with xml or the io package.
fopen() does not succeed. That could be because the file exists but is
locked, or the file is not writable maybe because the location (subdir) is
read-only, or some other issue. First sort that out.
What can also happen is that elsewhere in Octave some function (user- or
Octave-) opened the file but the function errored out, didn't close the file
and Octave returned to the prompt and now you have a hidden (dangling) file
handle (= return value of fopen(), it's scope is local to the function).
In such a case restarting Octave is often the only way out.
It looks like that could well be the function you showed - if the first time
you ran it the fopen() succeeded but writing failed, the function itself is
aborted prematurely w/o ever reaching the fclose() statement - and there you
have a dangling file handle. That is an easy and very often occurring
programming error - but again, in your defense, you're not quite the only
one doing this :-)
You *always* need to test for the return value of fopen() *before* doing
anything with the file handle like reading or writing.
It is also good programming practice to enclose file I/O in functions in a
try-catch or maybe better, an unwind_protect block (think of disk full, or
disconnected network share, or pulled thumb drives etc).
IOW, make sure that an fopen() statement is always followed by a matching
fclose() that can be reached & executed whatever happens in between.