Andrew,
There is some trickery in that I know of. Unicon will not allow a null
character in the open string. No poison null attacks.
David
----- Original Message ----
From: Andrew Clarke <[EMAIL PROTECTED]>
To: [email protected]
Cc: Jonathan Kaye <[EMAIL PROTECTED]>
Sent: Thursday, January 17, 2008 5:39:45 PM
Subject: Re: [Unicon-group] porting to Windows?
On Fri, 18 Jan 2008 05:53, Jonathan Kaye wrote:
>
> Hi Jafar,
> Thanks so much. You are a gentleman and a scholar. This is what I
> thought. The bad news is now I have no clue as to why some Windows
users
> can't open the data file. My code looks like this:
> # Setup i/o
> datadir := "Data/"
> outdir := "Output/"
> resp := "y"
> while resp == "y" do {
> writes("Specify page to proof: ")
> flnm := read()
> infile := open(datadir || flnm || ".txt") | stop("can't open data
> file: ", chdir(), "/", datadir, flnm, ".txt")
> outfile := open((outdir || flnm || ".out"), "w") | stop("can't
open
> output file: ", chdir(), "/", outdir, flnm, ".out")
/ and \ have been interchangeable in the MS-DOS and Windows system
calls
since the day MS-DOS got directories. The idea was taken from Unix, but
since there was already a solid convention of using
cmd /switch
on MS-DOS from the CP/M ancestry, they were stuck in a bind. So some
genius
decided to use \ and the rest is a travesty (I mean history). In fact,
at
around MS-DOS 2.11, there was a config.sys setting
switchar = -
which allowed you set the command line option lead-in character to be
either / or -. No other characters were allowed. Then it disappeared
again,
although I *think* there was actually a system call to set this which
persisted for quite a few releases.
I always use / in my code when calling a windows function. It saves a
lot of
backslashitis, obsessive use of constants or whatever. I am far from
the
only person on the planet who uses / in their Windows system calls.
I've
seen a lot of it in all sorts of source code. Therefore if it was ever
pulled, it would break a lot of software. I seriously doubt that
Microsoft
would even consider the action.
There is one simple gotcha with the use of /; if you are going to do
the
equivalent of a system("command /options paths") then you must expect
the
command to process the command line in the same old dirty way that it
has
always been done. In this situation only, you need to map your slashes.
Note that this will probably occur if you use a pipe-like variation of
any
of the Icon opening functions.
Quick question for the Unicon masters (I'm more of an Iconer): is there
any
trickery in the open functions? EG trying to assign magical value to
any
contents on the filename? Does it REALLY pass the string on untouched
to
the O/S?
> Could this be a Vista issue?
Probably not. It's too unlikely for something so core as the file
opening
calls. More likely some surprise in your own code. Can you dump the
actual
strings being passed to the open functions? I've looked at your code
and it
looks harmless enough...
Having said that, I haven't had the inclination to go near a Vista
machine
yet.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group
