Homebrew
man bash spewing unsupported control character 0x7 errors on Monterey 12.0.1
#2506
Replies: 17 comments 15 replies
-
|
I'm seeing this error too. And not just with the
Probably. Apple seems to have messed up None of these errors seem to cause any real problems, but it would be nice to not see them. Could you try opening a ticket at https://feedbackassistant.apple.com? |
Beta Was this translation helpful? Give feedback.
-
|
@carlocab On my system (M1 Mini @ 12.0.1) |
Beta Was this translation helpful? Give feedback.
-
|
Do you have Rosetta installed? You'll only see it if you don't have Rosetta installed. If you do have Rosetta installed, everything works fine, since |
Beta Was this translation helpful? Give feedback.
-
|
Ah yes I do have Rosetta. |
Beta Was this translation helpful? Give feedback.
-
|
I wouldn't hold my breath for a timely fix: https://twitter.com/zhuowei/status/1429531764503023620 Still, they should hopefully fix this eventually with enough bug reports. |
Beta Was this translation helpful? Give feedback.
-
|
I filed |
Beta Was this translation helpful? Give feedback.
-
|
The brew version gnu-screen man-page produces massive error msg like this, too. |
Beta Was this translation helpful? Give feedback.
-
|
Funny thing is, if I check what command is being executed by And when I run that exact command manually it runs just fine, no errors output at all. So, more head scratching. 🤷 |
Beta Was this translation helpful? Give feedback.
-
|
Did you solve the problem? |
Beta Was this translation helpful? Give feedback.
-
|
@Alexandreee100 No, and it's not fixed in 12.2 either. |
Beta Was this translation helpful? Give feedback.
-
|
if you find a solution to the problem, can you let me know? |
Beta Was this translation helpful? Give feedback.
-
|
I am seeing this as well, does not seem to fit with the currently allowed sort of issues to report for homebrew: |
Beta Was this translation helpful? Give feedback.
-
|
I'm experiencing the issue on a 2019 Intel Macbook Pro, so it's not M1 related, Monterey in general seems to be affected (I'm on 12.3.1). ❯ man bash
mandoc: /usr/local/share/man/man1/bash.1:34:28: UNSUPP: unsupported control character: 0x7
mandoc: /usr/local/share/man/man1/bash.1:34:35: UNSUPP: unsupported control character: 0x7
mandoc: /usr/local/share/man/man1/bash.1:36:17: UNSUPP: unsupported control character: 0x7
mandoc: /usr/local/share/man/man1/bash.1:36:34: UNSUPP: unsupported control character: 0x7
It does show the manpage, but I'm seeing this as the first few lines on the terminal before man page is shown. |
Beta Was this translation helpful? Give feedback.
-
|
Same problem here on
When and how will this get fixed? 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
When enough people report the bug to Apple I guess. |
Beta Was this translation helpful? Give feedback.
-
|
I noticed similar messages this morning after running Interestingly, I don't see the messages when running nroff or groff to dump the bash manpage as formatted text, so it's definitely something the macOS man binary doesn't like. |
Beta Was this translation helpful? Give feedback.
-
|
Definitely not a Homebrew issue. It happens on the system-provided |
Beta Was this translation helpful? Give feedback.
-
|
Is there anyone from Apple lurking here? I don't have a developer license so I can't file real bug reports. The ones sent to https://www.apple.com/feedback/macos.html I am pretty sure get routed directly to |
Beta Was this translation helpful? Give feedback.
-
|
Well, this is a surprise! Just got this back from Apple to my feedback... looks like it might be fixed in macOS 13 "Ventura". 🎉
|
Beta Was this translation helpful? Give feedback.
-
|
Similarly, when running And the error:
OS: macOS 13.1 Related: bug#31228: Update GREP manpage |
Beta Was this translation helpful? Give feedback.
-
|
As of macOS 13.2.1, the error message has changed $ man bash
This manpage is not compatible with mandoc(1) and might display incorrectly. |
Beta Was this translation helpful? Give feedback.
-
|
@luckman212 There is a workaround that I just tried, and it works. Btw, this happens with most man pages with tables too. Luckily for us, on macOS
You could comment out |
Beta Was this translation helpful? Give feedback.
-
|
This is a not a good workaround… suppressing this message by leaving not sufficient time to display it 🤔 I hoped there's a way to fix it "locally" before Apple will fix the root cause. This would be a nicer workaround! |
Beta Was this translation helpful? Give feedback.
-
|
It is a good workaround if one knows the man page they are interested in renders well, but they don't want man to keep adding an annoying delay and message. A user can always test if the man page they are viewing has any problem by either scrolling up to look for this line or by invoking man as |
Beta Was this translation helpful? Give feedback.
-
|
I understand from your point of view… But why didn't you also remove this line, too? 😉
|
Beta Was this translation helpful? Give feedback.
-
|
@thomas-merz You didn't read the last line of my comment. Repeating it here:
It won't be viewed by the the user when they open a man page greater in height than terminal height as the pager ( |
Beta Was this translation helpful? Give feedback.
-
|
Btw, here's an issue I filed on asciidoc's generator for roff. It shows a simple example with a manpage table, and what bytes are output by |
Beta Was this translation helpful? Give feedback.
-
|
FYI, if you want to simply remove the unsupported gsed -i '' 's/\x07//g' /opt/homebrew/share/man/man1/bash.1 /opt/homebrew/share/man/man3/expr.3You may consider making it an alias or function for later use. |
Beta Was this translation helpful? Give feedback.
-
|
Been updating this bugreport steadily for 3 years now hoping someone @ Apple will eventually see it. Sadly even as of the upcoming 14.4 release, still not fixed. Would be amazing if others could report as well and reference FB9775632. |
Beta Was this translation helpful? Give feedback.
-
|
Think I've figured out what's really going on. (My system is macOS Monterey 12.7.3 so the error msgs are the original mandoc UNSUPP type.) Root causeRun Run Since Apple releases macOS's source code at https://opensource.apple.com/releases/ , the issue can be verified at the code: https://github.com/apple-oss-distributions/man/blob/man-30/man/src/man.c#L774 char *test_command = my_xsprintf("%s -W unsupp,stop %s 2>&1 >/dev/null",
"/usr/bin/mandoc", file);It's definitely introduced by Apple since it's inside a What's going onmacOS Monterey ships with a customized
So here at step 1, if It is a common mistake for shell programming. One could find a detailed explanation at http://mywiki.wooledge.org/BashFAQ/055 . Some related information taken from the This also explains why the command for formatting & displaying a bash manual page like this (see by because this is the step 3. One can further verify it by doing a This time the step 2 is chosen. How to fixfor macOS MontereyWhile workaround may vary, the real fix should take place at the Apply the patch below to the source tree https://github.com/apple-oss-distributions/man/tree/man-30 should fix the problem: From 7f9e33f21cdd7fc930c064e709ee297693ee3b9e Mon Sep 17 00:00:00 2001
From: Rui Chen <[email protected]>
Date: Mon, 12 Feb 2024 22:58:52 +0800
Subject: [PATCH 1/1] Fix mandoc unsupp warning msg
---
man/src/man.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/src/man.c b/man/src/man.c
index f3a7246..d934ca1 100644
--- a/man/src/man.c
+++ b/man/src/man.c
@@ -771,7 +771,7 @@ make_mandoc_command(const char * path, const char *file) {
return NULL;
}
- char *test_command = my_xsprintf("%s -W unsupp,stop %s 2>&1 >/dev/null",
+ char *test_command = my_xsprintf("%s -W unsupp,stop %s >/dev/null 2>&1",
"/usr/bin/mandoc", file);
int test_status = do_system_command(test_command, 1);
if (test_status == 0) {
--
2.37.1 (Apple Git-137.1)
Unfortunately, compile process isn't as straight; I am still struggling at it. for macOS 13 and newerStarting from macOS 13, Apple ships its system with a |
Beta Was this translation helpful? Give feedback.
-
|
Apple recently updated my feedback FB9775632 on this to read "Potential fix identified - For a future OS update" 
So, a fix may be forthcoming. |
Beta Was this translation helpful? Give feedback.
-
|
To fix the bash manual error, I typed this : gsed -i 's/\x07//g' $(man -w bash) |
Beta Was this translation helpful? Give feedback.
-
Since the issue tracker seems to be down, I guess I'll just post this here in case anyone else has seen it.
I noticed that on both of my Macs (one M1 Mini and one Intel MacBook Air) both running 12.0.1, and fully updated brew, I'm getting the following error when running
man bash:The
/opt/homebrew/share/man/man1/bash.1file definitely does contain that^Gcharacter, but it seems to have been there forever, so not sure why it's suddenly causing errors:Here's a video:
bash1.mp4
I posted a bugreport on the GNU Bash homepage, and it was basically pointed back to Apple.
Anyone else seeing this? Is this really a Monterey issue?
Beta Was this translation helpful? Give feedback.
All reactions