Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error on launch of ncneofetch: encoding ("utf-8") was neither ANSI_X3.4-1968 nor UTF-8, refusing to start #2779

Closed
barracuda156 opened this issue Jun 3, 2024 · 12 comments · Fixed by #2782
Assignees
Labels
bug Something isn't working
Milestone

Comments

@barracuda156
Copy link
Contributor

barracuda156 commented Jun 3, 2024

Please include the following data:

36-174% export | egrep 'LANG|LC_CTYPE|TERM'
LANG=en_US.utf-8
TERM=xterm-color
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=250

36-174% port -v installed notcurses
The following ports are currently installed:
  notcurses @3.0.9_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2023-08-06T13:11:40+0800'

ncneofetch refuses to launch:

36-174% ncneofetch
encoding ("utf-8") was neither ANSI_X3.4-1968 nor UTF-8, refusing to start
 did you call setlocale()?

However UTF-8 is apparently set:

36-174% printenv
PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin
SHELL=/bin/zsh
SSH_AUTH_SOCK=/tmp/launch-NXSood/Listeners
Apple_PubSub_Socket_Render=/tmp/launch-sZR7nB/Render
DISPLAY=/tmp/launch-iPI3L8/org.macports:0
__CF_USER_TEXT_ENCODING=0x1F5:0:0
COMMAND_MODE=unix2003
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=250
LANG=en_US.utf-8
TERM=xterm-color
SHLVL=1
OLDPWD=/Users/svacchanda
_=/usr/bin/printenv
@barracuda156 barracuda156 added the bug Something isn't working label Jun 3, 2024
@dankamongmen
Copy link
Owner

hrmmm so as i'm reading this, you had utf-8 rather than UTF-8 as your locale, is that correct? yes, i see it is from your LANG.

that's interesting. is there a reason why you have lowercase utf-8? I wouldn't have expected that to work. i'll look into this. thanks for bringing it to my attention!

@dankamongmen dankamongmen self-assigned this Jun 5, 2024
@dankamongmen dankamongmen added this to the 3.1.0 milestone Jun 5, 2024
@dankamongmen
Copy link
Owner

from locale(7):

       LOCPATH
              A list of pathnames, separated by colons (':'), that should be used to find locale data.  If this  variable  is  set,
              only  the  individual  compiled  locale data files from LOCPATH and the system default locale data path are used; any
              available locale archives are not used (see localedef(1)).  The individual compiled locale data  files  are  searched
              for under subdirectories which depend on the currently used locale.  For example, when en_GB.UTF-8 is used for a cat‐
              egory,  the  following  subdirectories  are  searched  for,  in this order: en_GB.UTF-8, en_GB.utf8, en_GB, en.UTF-8,
              en.utf8, and en.

this makes me think it ought work. continuing to research...

@dankamongmen
Copy link
Owner

yeah this looks like my bug. probably just need strcasecmp() where we have strcmp(). thanks for the report!

@dankamongmen
Copy link
Owner

so we're always checking the result of nl_langinfo(), which doesn't return utf-8 on my linux machine. @barracuda156 , can you please show me the output of locale -m on your machine? we probably want to use strcasecmp() in any case, but my curiosity is piqued...

@dankamongmen
Copy link
Owner

interesting:

[schwarzgerat](0) $ locale -a | grep -i utf
be_BY.utf8
C.utf8
en_GB.utf8
en_US.utf8
fr_FR.utf8
[schwarzgerat](0) $ locale -m | grep -i utf
UTF-8
[schwarzgerat](0) $ locale | grep -i utf
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
[schwarzgerat](0) $ 

@dankamongmen
Copy link
Owner

i'm furthermore always seeing either UTF-8 or utf8, but @barracuda156 claims utf-8. hrrmm!

@dankamongmen
Copy link
Owner

this ought be fixed by #2781 . please verify if possible!

@barracuda156
Copy link
Contributor Author

@dankamongmen I will check once back to the machine and let you know. Thank you!

@dankamongmen
Copy link
Owner

oops, we also need to get the ncdirect case!

@barracuda156
Copy link
Contributor Author

@dankamongmen I have built it from b41af4e commit, and it behaves strange. Here is what I get on launch:

/opt/local/bin/ncneofetch
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\Gi=1,a=q;

Then with control+C:

36-173% /opt/local/bin/ncneofetch
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\Gi=1,a=q;couldn't remove alternate signal stack (Invalid argument)

BTW, locale -m does not work, there is no output.
locale -a gives this:

36-173% locale -a
af_ZA
af_ZA.ISO8859-1
af_ZA.ISO8859-15
af_ZA.UTF-8
am_ET
am_ET.UTF-8
be_BY
be_BY.CP1131
be_BY.CP1251
be_BY.ISO8859-5
be_BY.UTF-8
bg_BG
bg_BG.CP1251
bg_BG.UTF-8
ca_ES
ca_ES.ISO8859-1
ca_ES.ISO8859-15
ca_ES.UTF-8
cs_CZ
cs_CZ.ISO8859-2
cs_CZ.UTF-8
da_DK
da_DK.ISO8859-1
da_DK.ISO8859-15
da_DK.UTF-8
de_AT
de_AT.ISO8859-1
de_AT.ISO8859-15
de_AT.UTF-8
de_CH
de_CH.ISO8859-1
de_CH.ISO8859-15
de_CH.UTF-8
de_DE
de_DE.ISO8859-1
de_DE.ISO8859-15
de_DE.UTF-8
el_GR
el_GR.ISO8859-7
el_GR.UTF-8
en_AU
en_AU.ISO8859-1
en_AU.ISO8859-15
en_AU.US-ASCII
en_AU.UTF-8
en_CA
en_CA.ISO8859-1
en_CA.ISO8859-15
en_CA.US-ASCII
en_CA.UTF-8
en_GB
en_GB.ISO8859-1
en_GB.ISO8859-15
en_GB.US-ASCII
en_GB.UTF-8
en_IE
en_IE.UTF-8
en_NZ
en_NZ.ISO8859-1
en_NZ.ISO8859-15
en_NZ.US-ASCII
en_NZ.UTF-8
en_US
en_US.ISO8859-1
en_US.ISO8859-15
en_US.US-ASCII
en_US.UTF-8
es_ES
es_ES.ISO8859-1
es_ES.ISO8859-15
es_ES.UTF-8
et_EE
et_EE.ISO8859-15
et_EE.UTF-8
eu_ES
eu_ES.ISO8859-1
eu_ES.ISO8859-15
eu_ES.UTF-8
fi_FI
fi_FI.ISO8859-1
fi_FI.ISO8859-15
fi_FI.UTF-8
fr_BE
fr_BE.ISO8859-1
fr_BE.ISO8859-15
fr_BE.UTF-8
fr_CA
fr_CA.ISO8859-1
fr_CA.ISO8859-15
fr_CA.UTF-8
fr_CH
fr_CH.ISO8859-1
fr_CH.ISO8859-15
fr_CH.UTF-8
fr_FR
fr_FR.ISO8859-1
fr_FR.ISO8859-15
fr_FR.UTF-8
he_IL
he_IL.UTF-8
hi_IN.ISCII-DEV
hr_HR
hr_HR.ISO8859-2
hr_HR.UTF-8
hu_HU
hu_HU.ISO8859-2
hu_HU.UTF-8
hy_AM
hy_AM.ARMSCII-8
hy_AM.UTF-8
is_IS
is_IS.ISO8859-1
is_IS.ISO8859-15
is_IS.UTF-8
it_CH
it_CH.ISO8859-1
it_CH.ISO8859-15
it_CH.UTF-8
it_IT
it_IT.ISO8859-1
it_IT.ISO8859-15
it_IT.UTF-8
ja_JP
ja_JP.eucJP
ja_JP.SJIS
ja_JP.UTF-8
kk_KZ
kk_KZ.PT154
kk_KZ.UTF-8
ko_KR
ko_KR.CP949
ko_KR.eucKR
ko_KR.UTF-8
lt_LT
lt_LT.ISO8859-13
lt_LT.ISO8859-4
lt_LT.UTF-8
nl_BE
nl_BE.ISO8859-1
nl_BE.ISO8859-15
nl_BE.UTF-8
nl_NL
nl_NL.ISO8859-1
nl_NL.ISO8859-15
nl_NL.UTF-8
no_NO
no_NO.ISO8859-1
no_NO.ISO8859-15
no_NO.UTF-8
pl_PL
pl_PL.ISO8859-2
pl_PL.UTF-8
pt_BR
pt_BR.ISO8859-1
pt_BR.UTF-8
pt_PT
pt_PT.ISO8859-1
pt_PT.ISO8859-15
pt_PT.UTF-8
ro_RO
ro_RO.ISO8859-2
ro_RO.UTF-8
ru_RU
ru_RU.CP1251
ru_RU.CP866
ru_RU.ISO8859-5
ru_RU.KOI8-R
ru_RU.UTF-8
sk_SK
sk_SK.ISO8859-2
sk_SK.UTF-8
sl_SI
sl_SI.ISO8859-2
sl_SI.UTF-8
sr_YU
sr_YU.ISO8859-2
sr_YU.ISO8859-5
sr_YU.UTF-8
sv_SE
sv_SE.ISO8859-1
sv_SE.ISO8859-15
sv_SE.UTF-8
tr_TR
tr_TR.ISO8859-9
tr_TR.UTF-8
uk_UA
uk_UA.ISO8859-5
uk_UA.KOI8-U
uk_UA.UTF-8
zh_CN
zh_CN.eucCN
zh_CN.GB18030
zh_CN.GB2312
zh_CN.GBK
zh_CN.UTF-8
zh_HK
zh_HK.Big5HKSCS
zh_HK.UTF-8
zh_TW
zh_TW.Big5
zh_TW.UTF-8
C
POSIX

@dankamongmen
Copy link
Owner

this stuff is another bug, one i think has been reported, but i'm unsure. we are now starting, right? let me look for that other bug.

@barracuda156
Copy link
Contributor Author

@dankamongmen Yes, I am getting that when trying to start /opt/local/bin/ncneofetch binary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants