Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!bloom-beacon!mit-eddie!apollo!mishkin From: mishkin@apollo.HP.COM (Nathaniel Mishkin) Newsgroups: comp.sys.apollo Subject: Re: Controlling case of returned name from name_$get_path Keywords: case, help Message-ID: <452e55a9.1d6d5@apollo.HP.COM> Date: 22 Aug 89 13:01:00 GMT References: <45124af7.14df5@ulsoy.engin.umich.edu> Reply-To: mishkin@apollo.com (Nathaniel Mishkin) Organization: Apollo Computer, Chelmsford, MA Lines: 32 In article <45124af7.14df5@ulsoy.engin.umich.edu> conliffe@caen.engin.umich.edu (Darryl C. Conliffe) writes: >While using name_$get_path, I find the returned pathname >is in all upper case letters. Does anyone know (1) why, >and/or (2) how to get the pathname as it really exists? Contrary to a previous, almost correct followup to this posting, the correct call to use is "name_$get_path_lc", not "name_$get_path_cc". "name_$get_path_cc" (actually all the "_cc" calls) exist only for historical reasons -- they got put out before we realized that we really wanted all the name-returning calls to take an input parameter that specifies the actual length of the caller's output buffer. BTW, the reason that "name_$get_path" (in fact all the very old name-returning calls) didn't start returning mixed-case names at sr10 was because we were concerned about programs that did things like: name_$get_path(...); if (...last 4 chars of returned path is ".TXT"...) { ... } Note that the program would be checking for ".TXT" and not ".txt". Of course, some other program might use the returned pathname as *input* to some call that takes a pathname and then *that* call will fail because the file's name is "foo" not "FOO". Basically, someone loses either way. However, the DOWNCASE hack can sort of accomodate the latter class of program so we decided to not break the former class of program. -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA mishkin@apollo.com