Talk:Terminal control/Unicode output: Difference between revisions
Talk:Terminal control/Unicode output (view source)
Revision as of 21:26, 10 August 2018
, 5 years ago→Other characters
| (7 intermediate revisions by 4 users not shown) | |||
Line 17:
:: Which part in the examples do you actually verify your terminal "can do this"> Checking <code>LC_*</code> has almost nothing to do with underlying tty device's capability, and for what it's worth, the awk and shell examples don't even check if output device is a terminal, it could be a file or the bit bucket for all they care. I just don't see how this is a terminal related work. --[[User:Ledrug|Ledrug]] 19:05, 12 September 2011 (UTC)
::: Yeah, checking locale is the current method for determining output type (on a Unix system). There is also termcap, but this has no information on Unicode support AFAIK. Applications should all obey locale, so if the locale says use Unicode, then yay. If not, nay. The locale should always be configured for the terminal, so a session on a Unicode terminal would have a Unicode compatible locale set. On a conventional Ascii compatible terminal the locale would differ. With regards to files and bit buckets, again locale is the boss wrt output. I'm not aware of any other mechanisms for checking terminal type. [[User:Markhobley|Markhobley]] 20:21, 4 November 2012 (UTC)
Yeah, the printf may not work on some systems. I am working on some Unicode compatible helper programs which will be guaranteed to produce the appropriate Unicode output from shell scripts, etc. This in on my todo list.
Line 23 ⟶ 25:
: <code>set -- "$LANG"</code> and <code>unset "$LANG"</code> are not the same. I am using <code>set -- "$LANG"</code> to assign the positional parameters, so "$1" expands to the same value as "$LANG". A program would use <code>unset "$LANG"</code> to unset the variable named en_US.UTF-8 (if "$LANG" expanded to en_US.UTF-8), but there is probably no variable named en_US.UTF-8, so <code>unset "$LANG"</code> would probably do nothing.
Right. What about a set command without hyphens? How does that differ? There is a set command without hyphens, which is portable. [[User:Markhobley|Markhobley]] 19:13, 12 September 2011 (UTC)
: [http://www.in-ulm.de/~mascheck/bourne/index.html ''The Traditional Bourne Shell Family: History and Development''] claims that <code>set --</code> appears in System III. Later, <code>unset</code> appears in System V Release 2 (SVR2). Shell functions, like <code>unicode_tty() { ... }</code>, also appear in SVR2. I expect that today's shells have SVR4 features. --[[User:Kernigh|Kernigh]] 18:04, 12 September 2011 (UTC)
My books are based on System V, and they do not mention it, so it is probably an undocumented feature. There are some compatible shells, where the set -- does not work either. I stumbled across some notes somewhere, which talks about the implementation of the set command, and how the behaviour of the doublehypen is inconsistent when given as a parameter to set. I can't remember where I saw it at the moment though, I think it might have been an awk book, or a korn shell book, rather than a System V book. I am looking into it. [[User:Markhobley|Markhobley]] 19:25, 12 September 2011 (UTC)
: The hyphens with <code>set --</code> are marking end of options, like <code>ls --</code> or <code>rm --</code>. So <code>set -x</code> turns on trace mode, but <code>set -- -x</code> assigns parameter $1. I have used <code>set --</code> around the wiki ([[Factorial#UNIX Shell]], [[Greatest common divisor#UNIX Shell]]). It would be interesting to try a shell where <code>set --</code> does not work. --[[User:Kernigh|Kernigh]] 15:06, 13 September 2011 (UTC)
==Locales and terminal capabilities==
I could probably improve the Unicode detection to include Unicode Transformation locale naming schemes, but I have no data on this. Does anyone know where these are listed? Ideally, I could do with seeing a full list of locales (for Unix). There might be a pattern in there somewhere that could be used to improve Unicode support detection handlers. I am also wondering if there is a terminal capability that could be queried. [[User:Markhobley|Markhobley]] 17:26, 12 September 2011 (UTC)
:If the locale contains a numeral, then the environment is Unicode. (I think, but I am guessing here). If there are no numerals, then the environment is extended Ascii. [[User:Markhobley|Markhobley]] 20:35, 4 November 2012 (UTC)
==Other characters==
Windows unicode does not appear to support delta, at least with the default fonts, effectively making this an anti-microsoft task.
Other unicode characters should be permitted, I propose the following change:
Show at least one unicode character such as pi, root, lambda, sigma, delta, ie "π√λΣ△" or
"\u03C0\u221A\u03BB\u03A3\u25B3".
Note that the last, delta, does not appear to work on Windows (10), but the first four do.
State whether the code submitted works on linux, windows, or both.
[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 16:44, 10 August 2018 (UTC)
| |||