brb@philabs.UUCP (Brian Bertan) (09/21/85)
I am unable to open files using a directory search with either the
Mark Williams or Lattice "C" compilers. The file really does exist
in the specified directory. When I exclude the pathname from the
fopen statement, and execute the program from the directory
\usr\text, the file opens properly.
The function:
infile=fopen("c:\usr\text\things.txt","r")
returns NULL to infile.
The function:
infile=fopen("things.txt","r")
does NOT return NULL -- it succeeds in opening the file when the
program is executed from directory \usr\text.
Does anyone know why I can't properly use a pathname in fopen() ?
Thanks,
Brian Bertan
Philips Labs
Briarcliff Manor, NY
{allegra | decvax | seismo}!philabs!brb (914) 945-6309johnl@ima.UUCP (09/22/85)
/* Written 7:38 pm Sep 20, 1985 by brb@philabs in ima:net.micro.pc */ > I am unable to open files using a directory search with either the > Mark Williams or Lattice "C" compilers. ... > The function: > infile=fopen("c:\usr\text\things.txt","r") > returns NULL to infile. > The function: > infile=fopen("things.txt","r") > does NOT return NULL -- it succeeds in opening the file ... Try opening "c:\\usr\\text\\things.txt". Remember, this is C and \t turns into a tab character. John Levine, ima!johnl PS: MS-DOS and the C language clearly were not born to be friends.
jlt@styx.UUCP (John L. Thomas) (09/23/85)
> > infile=fopen("c:\usr\text\things.txt","r") > *** REPLACE THIS LINE WITH YOUR ESCAPE CHARACTER *** Remember? '\\' is an escape character? Try feeding an extra one to the parser. infile=fopen("c:\\usr\\text\\things.txt","r") John -- ARPA jlt@styx UUCP ...!seismo!lognet2!styx!jlt ...!idi!styx!jlt From Stebwer's Dictionary: Absent minded -adj. 1. Uh, well, uh, ... I forget. 2. What were we talking about?
edg@micropro.UUCP (Ed Greenberg) (09/23/85)
In article <450@philabs.UUCP> brb@philabs.UUCP (Brian Bertan) writes: >I am unable to open files using a directory search with either the >Mark Williams or Lattice "C" compilers. The file really does exist > ... > >The function: > > infile=fopen("c:\usr\text\things.txt","r") > >returns NULL to infile. > ... >Does anyone know why I can't properly use a pathname in fopen() ? > Brian Bertan Sounds to me that you need to double the backslashes in your pathname, a problem that Unix C programmers would never encounter. Try: infile=fopen("c:\\usr\\text\\things.txt","r") This is only required if the filename is created as a quoted string constant, as above. If, for example, the user typed the pathname in, I suspect that the double backslashes would not be necessary. -- -edg UUCP: {hplabs,dual,ptsfa}!well!micropro!edg
broehl@watdcsu.UUCP (Bernie Roehl) (09/23/85)
<bug line> In article <450@philabs.UUCP> brb@philabs.UUCP (Brian Bertan) writes: > >The function: > > infile=fopen("c:\usr\text\things.txt","r") > >returns NULL to infile. Remember that in C, the \ character is an escape (\n for newline, for example). To get what you want, double the \'s, as in infile = fopen("c:\\usr\\text\\things.txt", "r"); > >The function: > > infile=fopen("things.txt","r") > >does NOT return NULL ... because there are no \'s in it. Hope this helps (quite sure that it will!) --Bernie
bet@ecsvax.UUCP (Bennett E. Todd III) (09/23/85)
In article <450@philabs.UUCP> brb@philabs.UUCP (Brian Bertan) writes: > infile=fopen("c:\usr\text\things.txt","r") The '\' character is special in C character strings. To use it you must write two of them: infile=fopen("c:\\usr\\text\\things.txt","r") Why, oh why, did Microsoft elect to use the quoting character on the operating system they seem to be trying to migrate DOS towards for the file pathname separator? Oh well. -Bennett -- "Hypocrisy is the vaseline of social intercourse." (Who said that?) Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695 UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet
jpn@teddy.UUCP (09/24/85)
>> I am unable to open files using a directory search with either the >> Mark Williams or Lattice "C" compilers. ... >> The function: >> infile=fopen("c:\usr\text\things.txt","r") >> returns NULL to infile. >> The function: >> infile=fopen("things.txt","r") >> does NOT return NULL -- it succeeds in opening the file ... > >Try opening "c:\\usr\\text\\things.txt". Remember, this is C and \t >turns into a tab character. Alternatively, try opening "c:/usr/text/things.txt". MSDOS itself understands '/' as a directory seperator just as well as '\\'. Too bad microsoft opted to use '/' as the option introducer character for command line parsing. On the other hand, Thank goodness microsoft left the back door open and allows me to change the option character to '-'. At least in MSDOS 2.XX.
gst@ewj01.UUCP (Gary S. Trujillo) (09/24/85)
> >> I am unable to open files using a directory search with either the > >> Mark Williams or Lattice "C" compilers. ... > > > >Try opening "c:\\usr\\text\\things.txt". Remember, this is C and \t > >turns into a tab character. > > Alternatively, try opening "c:/usr/text/things.txt". MSDOS itself understands > '/' as a directory seperator just as well as '\\'. Too bad microsoft opted to > use '/' as the option introducer character for command line parsing. On the > other hand, Thank goodness microsoft left the back door open and allows me to > change the option character to '-'. At least in MSDOS 2.XX. The following article, from the January 1985 issue of the Boston Computer Society's "PC Report" appears relevant in this context: Several articles have pointed out that DOS 2.x provides the capability, not documented in the manual, to replace the default switch character "/" with a character of the users's own choosing. For example, if you would prefer to enter commands that look like "DIR!W" instead of "DIR/W", you need only create or revise a CONFIG.SYS file that includes the line, "SWITCHAR=!", and then boot your computer with the CONFIG.SYS file on the disk in the default drive. (It must be in the root directory if the disk includes subdirectories.) Moreover, if you specify a hyphen as the switch character ("SWITCHAR=-"), DOS assumes you want your keyboard and monitor to feel like UNIX, and helpfully changes the path separator from "\" to "/". These features appeared very attractive to one writer until he discovered that BACKUPed files couldn't be RESTOREd. Goodbye backups. No other problems reported. Since you use undocumented features at your own risk, take care. There may be a good reason a feature is undocumented. From the comments cited above from <1332@teddy.UUCP>, it would appear that the SWITCHAR variable need not be changed in order to be able to use "/" as pathname component separators from a C program, but only to permit one to use slashes in pathnames at MS-DOS command level. -- Gary S. Trujillo ...!{harvard,seismo,ihnp4,talcott,wjh12,decvax}!bbnccv!ewj01!gst
matt@prism.UUCP (09/24/85)
> /* Written 2:58 pm Sep 22, 1985 by johnl@ima in prism:net.micro.pc */ > /* Written 7:38 pm Sep 20, 1985 by brb@philabs in ima:net.micro.pc */ > > I am unable to open files using a directory search with either the > > Mark Williams or Lattice "C" compilers. ... > > The function: > > infile=fopen("c:\usr\text\things.txt","r") > > returns NULL to infile. > > The function: > > infile=fopen("things.txt","r") > > does NOT return NULL -- it succeeds in opening the file ... > > Try opening "c:\\usr\\text\\things.txt". Remember, this is C and \t > turns into a tab character. > > John Levine, ima!johnl You could also take advantage of the fact that MS-DOS internally allows either forward or backward slash as a path separator, so it's perfectly acceptable to use "C:/usr/text/things" (unless Microschlock decides to stop supporting this feature in some future DOS version). ----------------------------------------------------------------------------- Matt Landau {cca, ihnp4, inmet, mit-eddie, wjh12}... Mirror Systems, Inc. ...mirror!prism!matt Cambridge, MA (617) 661-0777 -----------------------------------------------------------------------------
alan@drivax.UUCP (Alan Fargusson) (09/24/85)
> In article <450@philabs.UUCP> brb@philabs.UUCP (Brian Bertan) writes: > >I am unable to open files using a directory search with either the > >Mark Williams or Lattice "C" compilers. The file really does exist > > ... > > > >The function: > > > > infile=fopen("c:\usr\text\things.txt","r") > > > >returns NULL to infile. > > ... > >Does anyone know why I can't properly use a pathname in fopen() ? > > Brian Bertan > > Sounds to me that you need to double the backslashes in your pathname, > a problem that Unix C programmers would never encounter. Try: > > infile=fopen("c:\\usr\\text\\things.txt","r") > This sounds very unlikly to me. I would suspect that the runtime is using DOS 1.0 style calls, and not DOS 2.0 style calls. Let me know what you find out. -- Alan Fargusson. { ihnp4, amdahl, mot }!drivax!alan
peter@graffiti.UUCP (Peter da Silva) (09/25/85)
> >The function: > > > > infile=fopen("c:\usr\text\things.txt","r") > > > >returns NULL to infile. > > ... > >Does anyone know why I can't properly use a pathname in fopen() ? > > Brian Bertan > > Sounds to me that you need to double the backslashes in your pathname, > a problem that Unix C programmers would never encounter. Try: > > infile=fopen("c:\\usr\\text\\things.txt","r") > Also try: infile = fopen("c:/usr/text/things.txt","r"); In theory this should work.
frank@sagan.UUCP (Frank Whaley) (09/26/85)
In article <103700016@ima.UUCP>, johnl@ima.UUCP writes: > > I am unable to open files using a directory search with either the > > Mark Williams or Lattice "C" compilers. ... > > The function: > > infile=fopen("c:\usr\text\things.txt","r") > > returns NULL to infile. > > The function: > > infile=fopen("things.txt","r") > > does NOT return NULL -- it succeeds in opening the file ... > Try opening "c:\\usr\\text\\things.txt". Remember, this is C and \t > turns into a tab character. > PS: MS-DOS and the C language clearly were not born to be friends. Note that most library implementations and MS-D*S itself allow the ``real'' version "c:/usr/text/things.txt". Guess I'll have to post source to SWITCH.COM which lets you define your own switch char -- anything other than '/' turns off '\' mode. -- frank ... Frank Whaley, MicroPro Product Development {dual,hplabs,glacier,lll-crg}!well!micropro!sagan!frank "I knew the bride when she used to rock and roll"
nather@utastro.UUCP (Ed Nather) (09/26/85)
> Thank goodness microsoft left the back door open and allows me to > change the option character to '-'. At least in MSDOS 2.XX. *sigh* --- too bad Microsoft is not Microsoft-compatible. Their new, spiffy C compiler v 3.0 has a neat option: expand command-line wild cards before your very eyes! Amaze your programmer friends! So long as you *don't* change the pathname separator to "/"!! This new, true- blue Unix-like option generates pathnames with "\" only! *sigh* -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.UTEXAS.EDU
coleman@sask.UUCP (Geoff Coleman) (09/28/85)
> > > > infile=fopen("c:\usr\text\things.txt","r") > > > > *** REPLACE THIS LINE WITH YOUR ESCAPE CHARACTER *** > > Remember? '\\' is an escape character? > Try feeding an extra one to the parser. > > infile=fopen("c:\\usr\\text\\things.txt","r") > > John > -- > ARPA jlt@styx > UUCP ...!seismo!lognet2!styx!jlt ...!idi!styx!jlt > > From Stebwer's Dictionary: > Absent minded -adj. > 1. Uh, well, uh, ... I forget. > 2. What were we talking about? You could always just specify the name as a valid unix path. ie: fp = fopen("c:/user/text/things.txt","r"); This works vary nicely from a lattice C program and the same can be done if you use a charecter string that is read in from a lattice C program. Apparently DOS uses "/" or "\" as valid path characters but command.com does not. Geoff Coleman University of Saskatchewan
brb@philabs.UUCP (Brian Bertan) (10/01/85)
>The function: > infile=fopen("c:\usr\text\things.txt","r") >returns NULL to infile. >The function: > infile=fopen("things.txt","r") >does NOT return NULL -- it succeeds in opening the file when the >program is executed from directory \usr\text. I received many responses, and I tried two suggestions: "c:\\usr\\text\\things.txt" worked with both the Lattice and Mark Williams compilers. "c:/usr/text/things.txt" did not work with either compiler. My thanks to everyone for helping me with this. Brian Bertan Philips Labs Briarcliff Manor, NY {allegra | decvax | seismo}!philabs!brb (914) 945-6309
larry@cca.UUCP (Laurence Schmitt) (10/07/85)
> >The function: > > infile=fopen("c:\usr\text\things.txt","r") > >returns NULL to infile. > > I received many responses, and I tried two suggestions: > > "c:\\usr\\text\\things.txt" worked with both the Lattice and Mark > Williams compilers. > > "c:/usr/text/things.txt" did not work with either compiler. Just to set things straight, which version of the Lattice compiler were you using? We have release 2.12 and it has no problem fopen'ing files named "c:/work/vw/sept.rpt", "c:../autoexec.bat", etc. -- Larry Schmitt Computer Corporation of America larry@cca 4 Cambridge Center decvax!cca!larry Cambridge, MA 02142 (617)-492-8860