-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[RFE] column: option to not exit with error 'Invalid or incomplete multibyte or wide character' #542
Comments
We already support this use-case (ignore wide chars) if compiled without wide chars support. Maybe we can use this code path also when requested by user. Not sure about the option name, maybe --force would be good enough. |
Addresses: #542 Signed-off-by: Karel Zak <kzak@redhat.com>
OK, I have implemented it in another way.
I think it's better to be optimistic for tools like column(1) and print as much as possible rather than exit with EILSEQ. |
example:
|
I love your optimistic approach for this issue, to print as much as possible, without adding a new option. Will test as soon as the release drips down to Arch Linux. |
Addresses: #542 Signed-off-by: Karel Zak <kzak@redhat.com>
@karelzak Could this be related to why I'm seeing Simplified example: printf '\x1b[33mHello\x1b[m\n' | column -t
\x1b[33mHello\x1b[m In older versions of |
The current stable version (v2.31.1) works as expected
See #490 |
Also
works as expected in v2.31.1. |
C
or (??_??.UTF-8
without correct locales set)Imagine a minimal (rescue) boot environment like initramfs.
Trying to print a formatted string in columns that contains multi-byte characters — like ¹ (superscript 1) — using command:
results in an error because of either a
LANG=C
(orPOSIX
, or another non*.UTF-8
setting) or in case there is a*.UTF-8
locale string set, because the environment is without the corresponding locale files being present.I would be nice if the
column
has an option that would exit without an error. Like a best effort result.Assumption
My guess is that
column
needs i18n and/or utf8 for figuring out that \302\271 is actually to be counted as 1 character position while printing.Proposal
The text was updated successfully, but these errors were encountered: