Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • invisible blank space

    I have noticed that, seemingly without warning, Stata started put an extra space after the first quotes.
    For example, if I wrote

    Code:
    cd "c:\mypath\myfolder"
    Stata read it as if it was written
    Code:
    cd " c:\mypath\myfolder"
    This is how I solved it. I went to that line of the code, put the cursor right before the "c:", pressed delete and, great surprise, there the cursor did not move.
    However, I rerun the same code immediately afterwards, and now Stata read it correctly, without the extra space before the "c".

    Also, there was a similar further anomaly.
    Probably, it added an extra space somewhere invisible at the end of an ado file of mine, because this is what has happened to me.
    I was working on an ado file that used to work perfectly.
    Then, all of a sudden stopped working only on my machine with Stata 14, while the very same ado file worked with Stata 16, on a different machine.
    In the machine with Stata 14, Stata was giving me this error message:

    Code:
    unexpected end of file
    (error occurred while loading myprogram.ado)
    r(612)
    But I could not understand, because I checked all parentheses "}", I was not using "#delimit ;" and I was not using "infile" (these are the three potential mistakes suggested by Stata, after I cliked on r(612)).

    I tried to debug this ado file with "set trace on", but of course, it could not work because the ado file was not even loading.
    Then I found this old post from the old statalist, which suggests a way to debug it.
    Bill's Point 4. in that linked post suggested running the ado as if it was a do file.

    Code:
    program drop _all
    do <insert full path and filename here>
    And, after I run the ado as if it was a do file, I see that Stata stopped right before "end".
    But I could not see anything strange. So, I did this: the line before "end" was blank, I deleted it, I reinserted the hard return and now the ado file worked.

    Unfortunately, this was so strange and "invisible" that I cannot think of a way of replicating it to show it here.
    I do not think there was something wrong with the computer.
    It is like if in some places of the ado file, the place where the blinking cursor stood actually included one invisible extra blank space that caused the issues I described above.
    And please remember: these issues occured only in the machine with Stata 14 and never before then in other do or ado files, while the same ado was working perfectly with Stata 16.

    Anything like that happened to anybody?
    If yes, do you know why?
    Last edited by FLuca; 08 Feb 2023, 12:53.

  • #2
    I have experienced very similar problems, but not in the context you describe. In particular, I have only seen this happen when the code was copy/pasted into the do-filed editor from some other source such as this Forum or other web pages, or from a Word document. I have never seen it happen with the identical file being used on different machines.

    The explanation is that sources like web pages and word processors insert non-printing characters into the text to control the way the text is displayed. These non-printing characters are not visible to our eyes when we view the text in applications. But Stata sees them and they invariably result in turning legal things into illegal things. By the way, they are not always at the beginning or end of the line--they can occur embedded within a line of text as well. They are a nasty problem when you encounter them. Usually the best solution is to simply delete the lines that are infected with them and re-type the text in properly by hand.

    Another approach is to make a data set out of the do-file: a data set with a single string variable, each line being a separate observation. Then Robert Picard's -chartab- (available from SSC) can show you what extraneous characters are in your data set. Then you can use -filefilter- to remove those characters from the do-file.

    But, as I say, I have never seen this happen with the simple direct transport of a do-file (or ado-file) from one computer to another. I have seen this only with code that was imported from a web page or a word processing document. So perhaps this is something different that I have never encountered.

    Comment


    • #3
      Many thanks, Clyde, for sharing your experience and providing an explanation.
      I could not wrap my head around it and I started to think that it was only me, because I simply was not able to spot the error.
      Also, your suggestion is very useful!
      Hope this post will prevent someone else from wasting hours of their life and some heartache
      Thank you again!

      Comment

      Working...
      X