Announcement

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

  • Use Mac alias files in a .do file

    Dear all,

    I'm new to Statalist, so any comment on the style of this post are welcome.

    In what follows, I summarize my issue.
    To better organize my work I use Mac alias files, i.e. file shortcuts that point to the original path of the file. However, when using Stata, this approach doesn't work properly. In particular, if I type the following in the .do file or command prompt:

    Code:
    use alias_file, clear
    Stata returns the error message:

    Code:
    file alias_file.dta not Stata format
    Nevertheless, if I manually open the file, Stata correctly points to the original path of the file. Is there any way to solve this issue?

    Thanks in advance.

  • #2
    Welcome to Statalist.

    I have confirmed your disappointing (to me, as well as to you) experience on my Mac, using Stata 15 on macOS 10.12.6.

    I then used the File > Open dialog and Stata generated a use command that resolved the alias to the full path to the original file. And from macOS terminal window, the shell command open given the alias name as an argument apparently fed Stata the full path to the original file.

    So here's a (grotesque) workaround.
    Code:
    . dir al*
    
    -rw-r--r--@ 1 lisowskiw  staff  956 Oct  5 13:57 alias_file.dta
    
    . use alias_file
    file alias_file.dta not Stata format
    r(610);
    
    . shell open alias_file.dta
    
    
    . use "/Users/lisowskiw/Research/Stata sandbox/170908/test_data.dta"
    
    .
    I suggest however that you also direct your question to Stata Technical Services at https://www.stata.com/support/tech-support/.

    It seems to me this should be a solvable problem without requiring the hack I used.

    Comment


    • #3
      Thank you very much William, your solution does work!

      Comment


      • #4
        I second William's suggestion to report this to Stata technical support, this seems to be a bug.

        Here's another workaround: Whilst macOS alias files do not seem to work from within Stata, symbolic links do. You could
        Code:
        ln -s /path/to/original/file /path/to/alias_file
        once in macOS' terminal and everything works as expected. The only caveat, however, is that symbolic links do not update when the original file is moved or renamed (whilst alias files are), so you have to recreate the symlink it this happens.

        Regards
        Bela

        Comment


        • #5
          This is not a bug.

          Symbolic links are handled at the file system level and the application doesn't know or care that the file being used is a symbolic link because the file system resolves it to the original file.

          An alias is a file that represents another filesystem object and is similar to a Windows shortcut which is also just a special file on disk. An alias is a Finder (and GUI) concept and functions at a higher level than the file system. If you use a file dialog to select an alias for opening or saving, macOS resolves the alias and returns the original filename. That's why File > Filename... returns the original filename rather than the alias filename. The application that asks for the filename doesn't know or care that the file you selected was an alias. shell open alias_file.dta works because open is a shell command that behaves as if you double-clicked on the filename from the Finder.

          If you have a file named file.do and create a symbolic link to it named link.do, opening link.do with Emacs or vi from a terminal will edit the original file file.do. If you create an alias to file.do named alias.do and try to edit alias.do with Emacs or vi from a terminal, you'll be editing the actual alias binary file, just like Stata.

          Resolving alias files is actually quite expensive and not something you want to do at the low level Stata operates at to read and write files because it can have a very negative effect on performance.
          -Chinh Nguyen

          Comment

          Working...
          X