I don't have a strong feeling for what you are
trying to do here. It might be that a much
simpler approach is to loop over a set of
graph-making commands and assign filenames
and numbers using a counter. Even if your
users are not very Stata-wise, teaching them
how to apply a general trick can score over
teaching them an idiosyncratic command.
Nick
[email protected]
David Elliott
> I have accessed the returned system values from the -log- command to
> get the path and filename for the log. I guess my opening comment was
> meant to indicate that there appears to be no system value available
> *without* issuing the -log- command first, unlike having the current
> -use-ed filename available.
>
> Incidently, this wrapper is to be used to capture and export graphs to
> the logfile directory preparatory to running a graphical log to HTML
> conversion -grlog2html- to allow viewing of logfiles in a browser
> complete with any generated graphs.
>
> I could issue a -gr2log, option : twoway connect ...- for each of my
> graphs and they would be exported as
> ""`logpath'""`logstem'""_$grcount.png" ($grcount would be initialized
> by calling -gr2log- with no arguments)
>
> The limitation to my initial approach was that graph export would save
> the files in the pwd unless told otherwise. I looked at the
> user-supplied routine -grss- but it was too fussy for my purposes.
> Ensuring that exported graphs are (1) saved in the logfile directory
> and (2) systemmatically named based on the logfile name should
> automate the export process nicely.
>
> I appreciate the comments from Phil and David Harrison. Incidently,
> David, I think _getfilepath should become an addition or modification
> to _getfilename such that the return variables would be r(filename)
> and r(pathname). And Phil, I'll take the dot in filename advice and
> reconsider how I am approaching that part of my problem.
>
> Thanks again,
>
> DCE
> On 5/30/06, Nick Cox <[email protected]> wrote:
> > A plain
> >
> > . log
> >
> > returns the information you need as r-class stuff.
> > This is documented at [R] log.
> >
> > With commands of the kind you indicated,
> > I have done what you outline, split with
> > -gettoken- and then use -syntax-. It is
> > worth knowing that -syntax- looks at the
> > contents of local 0. Thus you need to
> > assign that before each call to -syntax-.
> > Note also that each -syntax- call will
> > zap (overwrite, possibly with empty strings)
> > the contents of local macros like varlist,
> > if, in, etc. Hence you may need to save
> > these before any second -syntax- call.
> >
> > Nick
> > [email protected]
> >
> > David Elliott
> >
> > > I'd like to test to see if (1) a logfile is open and (2)
> > > capture its name.
> > > The logfile name does not seem to be part of the creturn
> c() system
> > > values although the currently used file name -c(filename)
> - and pwd
> > > -c(pwd) are available.
> > >
> > > Is there an equivalent to mata's
> pathsplit(path,path1,path2) command
> > > which would be very useful for filename handling? I have
> found the
> > > undocumented _getfilename which is useful for popping the
> filename off
> > > the end of a path/filename string and one can then do a bit of
> > > manipulation to get the path, filename and extension for further
> > > manipulation.
> > >
> > > Currently I have the following which will do the job:
> > >
> > > // Get the filename, path and extension for the log file.
> > > quietly log
> > > local log = r(filename)
> > > if "`log'" != "." {
> > > _getfilename "`log'"
> > > local logfile = r(filename)
> > > local logpath = subinstr(substr("`log'",1,
> > > length("`log'")-length("`logfile'")),"\","/",.)
> > > gettoken nameonly extonly: logfile, parse(".")
> > > local logstem "`logpath'""`nameonly'"
> > > local extonly = substr(`"`extonly'"',2,.)
> > > di in gr "`logpath'" in ye "`nameonly'" in gr "." in
> > > white "`extonly'"
> > > }
> > > else {
> > > di in red "No logfile open"
> > > }
> > > // end excerpt
> > >
> > > The other question I have is whether there is a way for
> -syntax- to
> > > handle command lines in the form: -cmd1, options: cmd2,
> options- or is
> > > it always necessary to nibble the command line apart with
> gettoken, or
> > > at least to get the left and right halves into a form for
> syntax to
> > > handle. If not obvious already, I am trying to create a
> "wrapper" for
> > > another command(s). If one didn't want the wrapper
> command to have
> > > options, one could simply use -cmd1 cmd2,options- that
> could be parsed
> > > by syntax. It is the need to have the ",options" and the ":"
> > > separator following cmd1 that causes the difficulties.
> > >
> > > This is my first foray into writing this kind of ado and I'd
> > > appreciate any insights or cautions from the pros. Thanks.
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
