Re: Path to *.m file
- To: mathgroup at smc.vnet.net
- Subject: [mg86594] Re: Path to *.m file
- From: David Bailey <dave at Remove_Thisdbailey.co.uk>
- Date: Fri, 14 Mar 2008 04:17:48 -0500 (EST)
- References: <200803091007.FAA15259@smc.vnet.net> <fr5e8q$odn$1@smc.vnet.net> <frclpk$rml$1@smc.vnet.net>
Vince Virgilio wrote: > On Mar 13, 5:32=A0am, David Bailey <dave at Remove_Thisdbailey.co.uk> > wrote: >> Carl Woll wrote: >>> I'm not sure why this is a `Private` variable, but this information can >>> be found from: >>> System`Private`$InputFileName >> This is very useful, and I have checked, and it was there at 5.2, so I >> guess it is one of those long-term undocumented features! >> >> However, it would be nice if it (or the subsequent documented feature) >> always returned the absolute path-name. As it is, Get["xxx.m"] sets this >> variable to ".\\xx.m", which is less convenient, and misleading if the >> code in the package has already executed a SetDirectory call. >> >> David Baileyhttp://www.dbaileyconsultancy.co.uk > > Some time ago, I think before 6.0, WRI technical support suggested the > following to me (ultimately from the developers): > > System`Private`FindFile[$Input]. > > Vince Virgilio > This seems to fail in the case where you reference a file by changing directory: SetDirectory["c:\\maths"] Get["xxx.m"] In this case, the function you describe returns $Failed, presumably because $Input only returns a string - "xxx.m" in this case - and FindFile is looking elsewhere! I guess it hardly needs saying (to WRI) that the whole value of a reliable version of a function like this would be that it would return its result without potential confusion of this sort! David Bailey http://www.dbaileyconsultancy.co.uk
- References:
- Path to *.m file
- From: Frank Scherbaum <Frank.Scherbaum@geo.uni-potsdam.de>
- Path to *.m file