Using directory separator ("/") inside conditional expression raises PatternSyntaxError

Bug #387470 reported by Michael Helmling on 2009-06-15
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pytagsfs
Wishlist
Unassigned

Bug Description

Hi,
if you try to use "conditional subdirectories", e.g.:
pytagsfs -o format='%a/%?%l/%?%t.%e' src dest

this throws a syntax error. Of course, in easy examples one can circumvent this by putting the / outside the condition:
pytagsfs -o ro,format='%a/%?%l%?/%t.%e'

since UNIX (and probably windows, too?) will ignore subsequent slashes, but in more complex scenarios this is not an option. I would have loved to submit a patch to fix this, but I have no chance in understanding how subspat.py works. ;-)

Regards,
Michael

Forest Bond (forest-bond) wrote :

Hi,

There's probably a bit more to this than you might think. The complications all come from renames; pytagsfs needs to know which tag field to update. With paths that vary by number of directory segments, this gets trickier. It seems possible, but it is not implemented now.

-Forest

Changed in pytagsfs:
assignee: nobody → Forest Bond (forest-bond)
importance: Undecided → Wishlist
status: New → Confirmed
Michael Helmling (supermihi) wrote :

That indeed sounds reasonable. In fact, up to now I wasn't aware of the renames feature of pytagsfs - pretty cool stuff. :-) However I'm afraid this makes my suggestion impossible to implement in a consistent manner, since in theory you could, for example, have fancy cases such as a name appearing both as composer and artist, so there would be no way to deterministically decide what the user did mean.

Still, I find this very sad, because pytagsfs is extremely useful even if you use it only "in one direction", i.e. mounting read-only, in which case the above doesn't harm. What about allowing slashes inside conditions if the -r option is set? Would this be easy to implement?
At least, I think pytagsfs shouldn't throw a SyntaxError but display a short explanation about what's going on, to preserve the user from checking his format string again and again.

kind regards,
Michael

Hi,

Thanks for the report, by the way.

On Mon, Jun 15, 2009 at 09:28:50PM -0000, Michael Helmling wrote:
> That indeed sounds reasonable. In fact, up to now I wasn't aware of the
> renames feature of pytagsfs - pretty cool stuff. :-)

Glad you think so. ;)

> However I'm afraid this makes my suggestion impossible to implement in a
> consistent manner, since in theory you could, for example, have fancy cases
> such as a name appearing both as composer and artist, so there would be no way
> to deterministically decide what the user did mean.

The specific case that you mention is non-ambiguous, and is possible. I agree
that there are other more complicated cases that are ambiguous. pytagsfs could
conceivably detect patterns that could result in ambiguous renames and either
reject them or warn the user that renames might not yield the expected result.

> Still, I find this very sad, because pytagsfs is extremely useful even if you
> use it only "in one direction", i.e. mounting read-only, in which case the
> above doesn't harm. What about allowing slashes inside conditions if the -r
> option is set? Would this be easy to implement?

Possible, but not easy because it requires deep modification that runs all the
way from the UI and down into subspat.py (and probably elsewhere, too). It'd be
a fun project. ;)

> At least, I think pytagsfs shouldn't throw a SyntaxError but display a short
> explanation about what's going on, to preserve the user from checking his
> format string again and again.

I absolutely agree. Would you mind filing a separate bug for this?

As always, patches are welcome. I hope to make a 0.9.1 release soon, but I'm
shorter on time than I've ever been due to starting a business, so I can't say
I'll be able to do any real work on pytagsfs right away.

BTW, I've never tested using conditional format strings that could result in
empty directory names. I'm curious if that should be disallowed because it may
cause problems for renames, but I don't really know. I'd like to add some unit
tests covering that scenario (another item for the large-and-growing todo
list!).

Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

Changed in pytagsfs:
assignee: Forest Bond (forest-bond) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers