Is there a way to make a '\' be a folder delimiter

Added by Ed Biow almost 2 years ago

I sometimes boot windows and like to have playlists with relative paths readable by either OS. As I recall Audacious 1.4 used to have an option to allow a backslash to be interpreted as a folder delimiter (/), but audacious 2.+ seems to have dropped that feature. Or is there some way to configure it that I am overlooking?

Since I figured out how to dock lyrics and album art panes I'm very happy with audacious, it is light, fast, stable and does what I want, except this little issue. Now I'm using mostly foobnix or amarok, both of which support lyrics and \ relative paths, but are not as stable or fast as audacious.


Replies (7)

RE: Is there a way to make a '\' be a folder delimiter - Added by John Lindgren almost 2 years ago

Windows has accepted '/' as a folder delimiter for some time now.

RE: Is there a way to make a '\' be a folder delimiter - Added by Ed Biow almost 2 years ago

I was unaware of that, interesting. I guess I don't use Windows much, and then mostly on older machines with XP. Still, the tool I use to tag my music files is a great open source project called mp3tag, which is Windows only, albeit I use it almost exclusively in wine, and it makes its m3u files with the conventional MS backslash delimiter. I guess I need to figure out a way to search through my thousands of playlists and switch the slash direction, maybe sed?

Still, many Linux players have no difficulty recognizing the \ as a /; off hand, foobnix, totem, decibel-audio-player, amarok, rhythmbox, xmms, and audacious 2.x used to do it, I'm sure I wouldn't be the only person who would appreciate this feature.Perhaps I should make a feature request if there is not any way to do it with the present incarnation of the player.

RE: Is there a way to make a '\' be a folder delimiter - Added by John Lindgren almost 2 years ago

After looking at the code, I believe it would have failed to accept '\' in relative paths even when running on Windows, which I would consider a bug. (Did I just say that I consider Windows a bug? Whoops ...) I've added an option to interpret '\' in Windows paths correctly, which will be enabled by default on Windows but disabled by default on other systems (since it would break on filenames containing '\' -- legal in UNIX).
https://github.com/audacious-media-player/audacious/commit/c4f2b61fd9be7077e39517fb1143cdefbef98680

RE: Is there a way to make a '\' be a folder delimiter - Added by Ed Biow almost 2 years ago

Thanks, John, though I'm pretty sure I have no idea what you are talking about (I'm obviously a non-technical end-user). I didn't even realize there was a Windows build of audacious (I use foobar or something in Windows-land). But even if it solves my problem of letting the Linux version of audacious correctly interpret the Windows-readable .m3u files created by my Mp3tag file tagger it would probably take a smallish eternity to get in to the repository versions of audacious that I use in Debian stable & Ubuntu LTS. I was hoping against hope that there was an option I could configure in ~/.config/audacious

I know there are a number of plugins available for audacious in the repositories, but none of them seemed like they would do what I want.

I made a little script that changes the slash direction in .m3u files in the current directory that I am in. I put it in ~/bin/m3u

#!/bin/bash
perl -pi -w -e 's/\\/\//g;' *.m3u

That will work when I freshly create a playlist with Mp3tag.

I tried various combinations of sed, xargs, find, etc. to find something that could do that recursively throughout my music directory but I seem to be foiled by the specific nature of the characters involved, the commands seem to barf when they see the "/" & "\" characters that I am trying to change, since these are obviously rather special in OS-land. The "escape" "\" that I put in to the little 1-line script above doesn't seem to help.

Examples:
find . -name '*.m3u' | xargs sed -i 's/\\/\//'

The 'find' part works fine but the part after the "|" gives me a bunch of "sed: can't read WORD_IN_FILE_OR_DIRECTORY_NAME: No such file or directory" errors. I guess this is caused by spaces between words in file and directory names, but I'm not going to try to change that. I have hundreds of files & directories and all the m3us expect to see those spaces in the directory names. I've tried a bunch of variations with escape characters in various places but since it is all "black magic" to me & I have no real idea what I'm doing it isn't working. Seems like I have to figure out how to tell xargs & sed to interpret the result of my "find" command as single files rather than seeing each word in the file names as a unique file.

Anyway, thanks again for looking at this, John.

RE: Is there a way to make a '\' be a folder delimiter - Added by John Lindgren almost 2 years ago

Try this:

find -name '*.m3u' -exec sed -i 's/\\/\//g' {} \;

RE: Is there a way to make a '\' be a folder delimiter - Added by Ed Biow almost 2 years ago

Well, that seems to be doing the trick, thanks. I guess it is the last 2 expressions: {} \;
I have no idea what they do, but I don't see any smoke pouring out of my hard drive.

Now I just have to run that every once in a while or run my little script whenever I create a new m3u.

I'd pretty much given up on audacious in the last few months since the 3.x stuff starting hitting the repositories except for starting individual music files (I tend to listen to playlists, though). But I was not real happy with amarok (heavy, unstable), foobnix (the same, lyric engine works only on some systems, wasn't in Ubuntu repository) & decibel-audio-player (too limited, no lyrics or tag editing).

There are a few things I'd love to see, but over all I'm quite happy.

RE: Is there a way to make a '\' be a folder delimiter - Added by John Lindgren almost 2 years ago

{} \; are a standard part of the -exec command. "find" replaces the {} with an .m3u filename. \; just means the end of the "sed" command line (the backslash makes sure that the semicolon is seen by "find" and not interpreted by the shell).

(1-7/7)