[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: st: insheet delimiter problem

From   "Nick Cox" <>
To   <>
Subject   RE: st: insheet delimiter problem
Date   Tue, 11 Nov 2008 18:41:05 -0000

My point was not that you were advocating overwriting but that it might
be thought that I was... 

And yes, I agree: Simplicity can be in the eye of the beholder. 

I was thinking largely of brevity, you, it seems, largely of the
familiarity of commands you know well. But -split- might be a strange
command to some. 

On -hexdump-: I don't think it's quite as difficult as you imply. For
example, with "@" as a candidate, you just need to use the -results-
option and check e.g. that r(c64) == 0. 

All amicably, of course, 


Joseph Coveney

Nick Cox wrote:

I would never recommend alteration of the original data file. I would
always recommend that you work on a copy. With that proviso, this route
is more complicated than using -filefilter-.


Lest there be a misunderstanding:  I wasn't advocating overwriting an
original data file (or even a working copy) with -filefilter-.  I don't
about analogous Unix commands, but have to assume that they, too, have
infile=, outfile= among their parameter lists.

We'll have to agree to disagree about relative complexity.  Amicably, I
hope.  I just find stopping to manually parse through -hexdump ,
output hoping that I don't overlook successive members of a list of
candidate substitutes, and then setting up -filefilter- with the winner,
then -insheet-ing the outfile, to be a similarly complicated prospect.
Maybe it's the inherent error-proneness of manually processing parallel
lists looking for things that aren't supposed to be there in one of them
that bothered me.

*   For searches and help try:

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