Using: REXX-ooRexx_4.2.0(MT)_64-bit 6.04 22 Feb 2014   on a W8.1 system

I stumbled across a problem recently where after redirecting the output
of a command to
a file in my user's temporary files folder, I was unable to read that
file using code like:

   tfstream = .stream~new(tmpfile)
   cresults = tfstream~arrayin 
   tfstream~close                     

I'd been using those three lines of REXX for years; all that had changed
was that the way I
specified the temporary file happened this time to start with "%TEMP%\"
whereas when
the code had worked before I'd first read the value of the %TEMP%
environment variable
& built filenames containing the actual path to %TEMP%, so filenames
looked something
like: "C:\Users\myuserid\....".

I don't know enough about using .stream to know how to find out why it
was unable to 
open the files concerned... which - incidentally - were all created
properly by the redirected 
command in question (which was processing WAV sound files).   When I
first had the problem
I did run file-compares across lots of example files and they were all
the same. 

I've written a test case that just uses:  echo some text > thetempfile
to create each test file, and then shows that when the filename starts
with "%TEMP%" the BIFs
SysIsFile() and SysFileExists() both fail to recognise that the file has
been created, even though 
a Windows 'dir' command will list it.   I assume that whatever these
functions test is possibly 
the same thing as seems then to prevent the .stream stuff from
opening(?) or reading the files. 
running the test code here I see open/read failures on the files that
the BIFs think don't exist,
and success on the ones they think do exist.

The test exec tries to create two files in %TEMP%, one with a leafname
that has spaces in it
and one without - both fail when the BIFs test the file.  It also
creates a similar pair of files 
with an explicit C:\Users....   path, and another pair in an ordinary
subdirectory of C:\.   The
problem only happens with the first pair, and it's clear that whether or
not filenames have spaces
in them doesn't matter.  All six files do get created.

There's no code in the test exec to create the destination directory for
the last pair of files; the 
exec assumes that "C:\WFE"  exists.   There's also no code that deletes
any of the test files
because I needed to be able to check that their contents was right.  I
manually deleted each 
set of 6 files before rerunning the code.  If anyone else tries the exec
they will need to create
C:\WFE  manually (or change the code to use some other place), and
delete the test files
afterwards manually.

Anyone who tries it will also see that some of the BIF calls wrap the
filenames in double quotes 
(which I did not think was needed, but thought I should try).  In the
test code none of the calls 
where double quotes are present work (and I expect they are not meant
to).  The calls that work 
or fail in the unexpected manner all don't have double quotes around the
filenames.

I'm happy to raise a bug report, but I'd like someone else to try the
test code first...

It's accessible at:
https://www.dropbox.com/s/xh1s5rnjtxygyjk/Weird%20tempfile%20error.rexp?dl=0

- oh!  The .rexp  extension is what I use to indicate execs that run
under rexxpaws; you might
need to change that.

-- 
Jeremy Nicoll - my opinions are my own.

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Reply via email to