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
