lyrics-to-sqlite.pl fails to parse the database

[C0rn3j]

Looks like it doesn't escape the three dots and completely, my attempts to fix are a failure as I don't know any perl.

Can't open ../lyrics/database/A/A Split-Second/…From the Inside/Mambo Witch : No such file or directory at lyrics-to-sqlite.pl line 38, <> chunk 23.

EDIT: Looks like I don't have access to the repo, could I get it? Wanted to add this to the readme:

You will need to install perl sqlite package(s) to get the scripts running. On Arch Linux, the package name is `perl-dbd-sqlite`.

EDIT2: Rather than opening 5 million issues for a WIP thing I'll post it here. Re-running the lyrics-to-sqlite.pl just adds data on top of the current file instead of deleting it and recreating the data.

[defanor]

It's not because of the album name, but because of the song name, which is "Mambo Witch " (with a space in the end). It's a bit strange, but can be fixed in the file name itself (I don't think it should have a space in the end).

There's also a related issue, with files starting with a regular dot ("."): plain "*" in glob patterns doesn't match on those, but I'm not sure if we should match on those: conventionally they should be ignored, and could be used for metadata or similar purposes.

[defanor]

Added you as a collaborator, I guess that should do it.

[defanor]

By the way, a DBI package is required too (though maybe it comes with Perl on Arch). And probably the one providing File::Basename. While the CGI script requires CGI, XML::LibXML, and XML::LibXSLT in addition to DBD::SQLite and DBI. Would be nice to sort out versions of those packages, and figure whether/how they can be pinned in a Perl project.

[C0rn3j]

perl-dbd-sqlite depends on perl-dbi in Arch, so it gets pulled

[C0rn3j]

How do I get the search running, both terminal and webserver wise?

Running it without any params just exits with 0

c0rn3j@Aleksandra ‹ docu-fix ● › : ~/lyrics-api
[0] % perl search.pl

[defanor]

It's a CGI script, so can be invoked as such: REQUEST_METHOD="GET" QUERY_STRING="title=foo" ./search.pl for CLI. As for a web server, either something supporting CGI should be used, or something supporting FastCGI (e.g., nginx supports FastCGI, but not CGI), and fcgiwrap. Here's the nginx config I'm using for testing:

server {
    listen localhost:80;
    server_name lyrics;

    location / {
        include fastcgi_params;
        fastcgi_pass 127.0.0.1:5151;
        fastcgi_param SCRIPT_FILENAME /home/defanor/proj/lyrics/lyrics-api/search.pl;
    }
}

[defanor]

Actually the example with title=foo finds a song with something strange in its lyrics. And will need to work on better error handling/messages.

Update: it finds nothing with the regular database, I just found a leftover from testing here, with intentionally broken unicode.

[defanor]

Re-running the lyrics-to-sqlite.pl just adds data on top of the current file instead of deleting it and recreating the data.

This one is fixed now, but by throwing an error rather than deleting, so that it won't lead to accidental loss of data. Perhaps could later introduce a --force flag to enforce removal.