gmtconvert -S cannot match string longer than 21 characters on intel mac

[noirchen]

Description of the problem

I installed gmt through pygmt on mac, and when I use gmt convert -S to match strings I found that when the string is longer than 21 characters, the command returns nothing. The gmt version is Version 6.5.0 [64-bit] [MP] [4 cores], and on ubuntu linux with gmt installed from the apt source, the bug doesn't exist.

Minimal Complete Verifiable Example

# this extracts the data as intended
gmt convert  gprv.gmt -S"prov_name=Some L01234567ng Name" -V > out.txt
# this extracts nothing
gmt convert  gprv.gmt -S"prov_name=Some L012345678ng Name" -V > out.txt
# this extracts the data as intended
gmt convert  gprv.gmt -S"prov_name=Some L0123456ng Name" -V > out.txt

# contents of data
# @VGMT1.0 @GPOLYGON 
# @Nid|prov_name|prov_type|prov_ref|prov_group|lastorogen|continent|conjugate1|comment|crust_type|conjugate2|area
# @Tdouble|string|string|string|string|string|string|string|string|string|string|double
# FEATURE_DATA
>
# @D1|"Some L012345678ng Name"||||||||||
# @P
119.618 22.2686
119.712279387314 21.9668188009922
119.839341058907 21.6051817356889
120.034820553666 21.1262569735306
>
# @D2|"Some L01234567ng Name”||||||||||
# @P
119.618 22.2686
119.712279387314 21.9668188009922
119.839341058907 21.6051817356889
120.034820553666 21.1262569735306
>
# @D3|"Some L0123456ng Name”||||||||||
# @P
119.618 22.2686
119.712279387314 21.9668188009922
119.839341058907 21.6051817356889
120.034820553666 21.1262569735306
>

Full error message

No response

System information

PyGMT information:
  version: v0.12.0
System information:
  python: 3.10.14 | packaged by conda-forge | (main, Mar 20 2024, 12:53:34) [Clang 16.0.6 ]
  executable: /Applications/homebrew/Caskroom/miniforge/base/bin/python3.10
  machine: macOS-13.6.7-x86_64-i386-64bit
Dependency information:
  numpy: 1.26.4
  pandas: 2.2.2
  xarray: 2024.5.0
  netCDF4: 1.6.5
  packaging: 24.0
  contextily: None
  geopandas: None
  ipython: None
  rioxarray: None
  ghostscript: 10.03.1
GMT library information:
  binary version: 6.5.0
  cores: 4
  grid layout: rows
  image layout:
  library path: /Applications/homebrew/Caskroom/miniforge/base/lib/libgmt.dylib
  padding: 2
  plugin dir: /Applications/homebrew/Caskroom/miniforge/base/lib/gmt/plugins
  share dir: /Applications/homebrew/Caskroom/miniforge/base/share/gmt
  version: 6.5.0

[welcome[bot]]

👋 Thanks for opening your first issue here! Please make sure you filled out the template with as much detail as possible. You might also want to take a look at our contributing guidelines and code of conduct.

[yvonnefroehlich]

It looks like this issue is directly related to GMT, not an PyGMT issue. In this case we should transfer it to the GMT repository. There is no wrapper for gmt convert in PyGMT yet.

I tried the provided examples on Linux and Windows with GMT 6.5/dev and GMT 6.4 and all three seem to work. So this is potentially an OS-dependent / mac-related issue, and we need an mac user to test this.

One side aspect is, that in the last line of the example the separator (the > at the end of the line) should be in the next line.

[noirchen]

Seems like only occurring on intel mac, because I tested a M1 mac running sonoma and the bug doesn't exist

[seisman]

I think I can reproduce the issue on Intel Mac, so there must be a bug.

I agree with @yvonnefroehlich that this is a GMT issue, so I'll transfer it to the GMT repository and will see if I can find some time fix it.

[welcome[bot]]

👋 Thanks for opening your first issue here! Please make sure you filled out the template with as much detail as possible. We appreciate that you took the time to contribute!

Please make sure you read our Contributing Guide and abide by our Code of Conduct.

[Esteban82]

I see that the bug is only on mac? So, in the title we could replace "in pygmt" to "in GMT with mac".

[joa-quim]

Maybe assume this doesn't worth the effort to try fix (Intel Macs will all disappear) and close this?

But I notice that the quotes used in the example file are different "Some L012345678ng Name" vs "Some L01234567ng Name”

Could it cause any side effects?

[seisman]

Maybe assume this doesn't worth the effort to try fix (Intel Macs will all disappear) and close this?

But I notice that the quotes used in the example file are different "Some L012345678ng Name" vs "Some L01234567ng Name”

Could it cause any side effects?

They're just different names for the polygons.

[joa-quim]

Nope. First closed string with a " and second with a ”

[seisman]

Changing ” to " doesn't solve the issue.

[joa-quim]

Guessed so, but had to rule it out.