Bug 66 - Newer abcde code doesn't work on OpenBSD
Summary: Newer abcde code doesn't work on OpenBSD
Status: CONFIRMED
Alias: None
Product: abcde
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: All All
: Normal normal
Assignee: Steve McIntyre
URL:
Depends on:
Blocks:
 
Reported: 2017-07-12 11:23 BST by Edd Barrett
Modified: 2018-02-26 18:56 GMT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Edd Barrett 2017-07-12 11:23:03 BST
Hi,

I'm happy to see abcde is once again maintained :)

I wanted to update the ancient OpenBSD port to the latest release, but it appears there are several issues which I also confirm are present in today's master branch too.

First, the shebang on all bash scripts is incorrect for OpenBSD, as all packaged binaries (including bash) go in /usr/local/bin, not /usr/bin. Changing the shebang to `#!/usr/bin/env bash` allows the scripts to run.

Next, I tried to rip a CD:

```
arrakis:abcde> ./abcde        
dasd: 1 13  150 216246  
Insufficient arguments for option discinfo
Usage:
     abcde-musicbrainz-tool [options]

     Options:
       --command {id|data|calcid} mode of operation (default: id)
       --device <DEV>             read from CD-ROM device DEV (default: /dev/cdrom)
       --discid <ID>              Disc ID to query with --command data.
       --discinfo <F> <L> <LI> <LO> <TRK1OFF> [<TRK2OFF> [...]]
                                  Disc information for --command calcid.
       --workdir <DIR>            working directory (default: /tmp)
       --help                     print option summary
       --man                      full documentation

Grabbing entire CD - tracks: 01 02 03 04 05 06 07 08 09 10 11 12 13
URL (http://musicbrainz.org/ws/1/release/?type=xml&discid=13) Request Failed - Code: 400 Error: Bad Request
cut: [-bcf] list: 2049 too large (max 2048)
cut: [-bcf] list: 2050 too large (max 2048)
cut: [-bcf] list: 2051 too large (max 2048)
cut: [-bcf] list: 2052 too large (max 2048)
cut: [-bcf] list: 2053 too large (max 2048)
cut: [-bcf] list: 2054 too large (max 2048)
cut: [-bcf] list: 2055 too large (max 2048)
cut: [-bcf] list: 2056 too large (max 2048)
cut: [-bcf] list: 2057 too large (max 2048)
...
```

It looks to me like we have several issues, the first being that `abcde-musicbrainz-tool --discinfo` has not been given enough arguments. Maybe the other errors follow on from this failure.

The musicbrainz lookup failed. The disc I am using to test is "Meds" by "Placebo": https://musicbrainz.org/release/d67c1834-59d7-4422-82b2-b1de8582fc60

The cut(1) thing is likely because it's BSD cut, not GNU cut, which seems to have a limitation.

I'm using OpenBSD-current/amd64, bash-4.4.12, and perl-5.24.1.

Sorry I have not had time to look into this any deeper.

Thanks
Comment 1 Ronny332 2017-12-10 13:20:12 GMT
Hi,

for OS X the issue is related to the regex of sed, which is used at the main abode file at line 2013.
In my case I force abcde to use cdparanoia, what results in better results. The default settings (seemingly a OS X based ripping), the error doesn't appear.

The sed command of OS X does not support as example the + sign for regex commands out of the box, the -E switch is needed for this. If this switch is used, quoting the braces is no longer needed, so in my case the original line

```
OFFSETS="$(echo "$CDPARANOIAOUTPUT" | sed -n -e's/^ .* \([0-9]\+\) \[.*/\1/p')"
```
changes to
```
OFFSETS="$(echo "$CDPARANOIAOUTPUT" | sed -n -E 's/^ .* ([0-9]+) \[.*/\1/p')"
```

Best wishes,
Ronny
Comment 2 Steve McIntyre 2018-02-26 18:56:33 GMT
Hi Edd,

It looks like there are deeper problems causing the failure to look up a CD with Musicbrainz. abcde will be trying to read information from your drive and generating the numbers needed for the discinfo call, but that's clearly not working. If you can take a look at the code you might be able to see where things are failing; I don't have an OpenBSD machine to do it myself. :-)

(It might be related to the sed issues mentioned by Ronny later...)