Statalist


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

RE: st: Compund quotes and the -file write- command


From   "Nick Cox" <n.j.cox@durham.ac.uk>
To   <statalist@hsphsun2.harvard.edu>
Subject   RE: st: Compund quotes and the -file write- command
Date   Mon, 20 Aug 2007 18:50:21 +0100

That's worth a chapter in anyone's thesis. 

Alternatively, the Stata Journal is open to 
offers on "Compound double quotes: the real inside
story". 

Nick 
n.j.cox@durham.ac.uk 

Eva Poen
 
> Hello Nick,
> 
> thank you very much. Unfortunately this didn't work either. 
> Same problem.
> 
> I now found this solution. It's a bit clumsy but it writes compound
> double quotes into the text file. I use a backslash to escape the `
> character.
> 
> forvalues x = 1/`n' {
>     file write `handle' "capture label variable `=VarName[`x']' "
>     file write `handle' " \`"
>     file write `handle' `"`=char(34)'"'
>     file write `handle' `" `=VarLabel[`x']' "'
>     file write `handle' `" `=char(34)'"'
>     file write `handle' "'"
>     file write `handle' _n
> }
> 
> 
> Finally I can have quotes in my labels!
> Thanks again,
> Eva
> 
> 
> 
> 2007/8/20, Nick Cox <n.j.cox@durham.ac.uk>:
> > Ho hum.
> >
> > My guess is that Stata is parsing your
> >
> > " `" "
> >
> > as
> >
> > " `"
> >
> > followed
> >
> > by
> >
> > "
> >
> > and the last is unacceptable. Key here is that
> > you can use -char()- to inhibit treatment of
> > ` and " and ' but that trick only works once,
> > i.e. when you do it. Once those characters are in the
> > macro the usual rules will apply when you use it
> > subsequently.
> >
> > So, two suggestions:
> >
> > 1. I see no reason to do what you want as a two-step.
> > So don't define the locals and then use them, but
> > just try the trick directly. For example,
> >
> >      file write `handle' " `=char(96)'`=char(34)' "
> >
> > 2. You might need `" "' rather than " " in the above.
> >
> > Nick
> > n.j.cox@durham.ac.uk
> >
> > Eva Poen
> >
> > > I tried to implement your solution, and it works like a charm for
> > > char(34), but not for a combination of char(34) and char(39) or
> > > char(96), for the opening and closing quotes. Since I want to have
> > > compound quotes printed as characters, I tried the following:
> > >
> > > local compoundopen "`=char(96)'`=char(34)'"
> > > local compoundclose "`=char(34)'`=char(39)'"
> > >
> > > di `" `compoundopen' `compoundclose' "'
> > >
> > > forvalues x = 1/`n' {
> > >     file write `handle' "capture label variable `=VarName[`x']' "
> > >     file write `handle' " `compoundopen' "
> > >     file write `handle' " `=VarLabel[`x']' "
> > >     file write `handle' " `compoundclose' "
> > >     file write `handle' _n
> > > }
> > >
> > > I receive an "invalid syntax" error after line 2 of the loop. -set
> > > trace on- reveals that the code does what I want it to do 
> - only stata
> > > doesn't like the syntax. Here are the relevant lines:
> > >
> > > = file write _VarLabelsFile " `" "
> > > invalid syntax
> > >
> > > Replacing the 39 and 96 chars by the actual characters 
> doesn't help.
> > > I'd be very grateful for any ideas on how to solve this.
> >
> >
> > > 2007/8/9, n j cox <n.j.cox@durham.ac.uk>:
> > > > As I understand it you want the inner compound double
> > > > quotes to be printed as characters, to be interpreted
> > > > later as delimiters, and not to be interpreted as
> > > > delimiters by -file- as it reads your command line.
> > > >
> > > > I haven't tried it, but I guess that using the -char()-
> > > > function may provide a solution. That is, wherever you
> > > > would have
> > > >
> > > > "
> > > >
> > > > put
> > > >
> > > > `=char(34)'
> > > >
> > > > and so forth. -asciiplot- from SSC is one way of
> > > > seeing a list of (your version of) ASCII characters.
> > > > Royalties should be sent directly to the original authors.
> > > >
> > > > Nick
> > > > n.j.cox@durham.ac.uk
> > > >
> > > > Eva Poen
> > > >
> > > > I am currently working with a large number of data sets 
> (Stata 9)
> > > > which all have a common structure and more or less the same
> > > variables.
> > > > To ensure that variables are labeled consistently across
> > > data sets, I
> > > > wrote a little program which defines these labels from 
> information
> > > > stored in an Access database. Everything works fine 
> apart from one
> > > > thing: I cannot have double quotes inside my variable
> > > labels. I tried
> > > > numerous ways to incorporate compound quotes, to no avail.
> > > >
> > > > The relevant code follows below. There are two variables in
> > > memory at
> > > > this point: one is called VarName; it holds all 
> variable names for
> > > > which I want to have common labels. The other one is 
> VarLabel which
> > > > holds the label information. The code generates a do-file
> > > which I can
> > > > then run on my data sets as required.
> > > >
> > > > *************
> > > > count
> > > > local n = r(N)
> > > >
> > > > file open VarLabelsFile using VarLabelsFile.do, write replace
> > > >
> > > > forvalues x = 1/`n' {
> > > >      file write `handle' `"capture label variable 
> `=VarName[`x']'
> > > > "`=VarLabel[`x']'" "' _n
> > > > }
> > > >
> > > > file close VarLabelsFile
> > > > *************
> > > >
> > > > My attempt was to introduce compound quotes like this:
> > > > -file write `handle' `"capture label variable `=VarName[`x']'
> > > > `"`=VarLabel[`x']'"' "' _n-
> > > >
> > > > But the resulting do-file still ends up looking like this:
> > > >
> > > > capture label variable SessionID "zTree (or other) Session ID
> > > > (alpha-numeric)"
> > > > capture label variable SID "unique Session ID (numeric)"
> > > > etc.
> > > >
> > > > instead of like this:
> > > > capture label variable SessionID `"zTree (or other) Session ID
> > > > (alpha-numeric)"'
> > > > capture label variable SID `"unique Session ID (numeric)"'
> > > > etc.

*
*   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/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index