Forum Archive

(This is to record a question I asked Ole earlier - and the answer, in a separate email - before I post a follow-up...)

Hi,

Thank you very much for Editorial. With a few workflows and snippets, it
has saved me huge amounts of time.

I would like to publish a couple of workflows that act on an entire
Dropbox tree, and to do this, I would like to find a safe way to get the
Dropbox root folder.

I've found that mine is this, with GUID (or similar) removed:

/var/mobile/Applications/08.../Library/Application Support/Dropbox

Is there a recommend way to obtain this in a Python script, please?

Things I considered:

• just hard-coding in my path - but I guess that wouldn't work with
  other languages, and I don't know if the GUID-like think is unique to my
  environment, or version of Editorial

• walking up the path of the open file until I found Dropbox, but
  someone could have a folder called Dropbox inside their Dropbox, so that
  isn't reliable

Thanks in advance,

Clare

Ole's reply:

Hi Clare,

you can use something like this:

import os
dropbox_root = os.path.expanduser('~/Library/Application Support/Dropbox')

Thanks,

--Ole

I just tried that out, and it almost worked, but directory it returned was:

/private/var/mobile/Applications/08.../Library/Application Support/Dropbox

i.e. prefixed with /private - and when the script runs, I get an error message:

Workflow error
An error occurred in the action "Run
Python Script": Line 50: TypeError:
'NoneType' object is not iterable

The code I'm using is virtually identical to the Search Filenames public workflow - I'm simply changing how the starting directory is obtained, to be able to search my whole Dropbox folder.

When I Google for editorial workflows expanduser there are loads of matches of the form os.path.expanduser('~/Library/Application Support/...'), so the basic principle seems fine.

What might I be doing wrong, to get the /private prefix?

The /private/... prefix is normal, could you show what's in line 50 of your workflow script (or better: the entire script)?

Thanks.

I've got it down to a minimal repro. When the line beginning root, is uncommented, I get the error:

import editor
import os
from StringIO import StringIO

html = StringIO()

dir = os.path.expanduser('~/Library/Application Support/Dropbox')
full_path = os.path.join( dir, 'Top.md')
# This line gives the error:
#root, rel_path = editor.to_relative_path(full_path)

html.write(dir + '<p>')

Trivia: editor.to_relative_path() isn't in the current docs.

Well, I guess to_relative_path isn't in the docs because it doesn't really work... ;)

To be honest, I'm a bit surprised by this, it should work like this, and I'll look into it, but I don't really see why you'd want to use it here anyway. If it worked properly, it would just return ('dropbox', 'Top.md'), which is basically what you already have...

:-)

The example I posted was created by pruning out lots of text from either the workflow "Search Filenames" or "Global Search" - I forget which. And they use to_relative_path to construct an encoded URL...

All I was trying to do was change those scripts - that search only from the directory of the currently open file - so that they search the entire Dropbox - but without containing a hard-coded path.

(It may depend on whether the editorial://open/-style URLs will work with the /private prefix)

Your comment makes me think that:

1. Either I deleted so much from the script that it failed to show the problem being solved
2. Or maybe I can rework the code to avoid the need to use to_relative_path
3. Or I just delete /private from the start of the result of os.path.expanduser

This probably gives me enough to get going. Thanks!

Clare

After looking into it a little bit, it seems that the reason why to_relative_path fails is that it's implemented in a pretty naive way – it basically just does a prefix check to determine the document root (dropbox/local). Internally, Editorial uses /var/... paths instead of /private/var/... and /var/ is a symlink to /private/var/...

Thank you for looking at it.

To any who gets here via search, my workflows to search all filenames in my Dropbox account, and all file contents, have been superceded by the much faster search functionality in the file browser in Editorial v1.1 - so thank you very much for that!