build missing HTML files for entries
Setup a simple topnav for missing HTML files for entries. Added `bin/gen-other-html.sh` to build entry HTML files from markdown other than README.md to index.html HTML files. Fixed duplicate link text in `2020/ferguson1/gameplay.md`. Improved `inc/md2html.cfg` to support building the missing HTML files for entries. Added `make gen_other_html` to top level Makefile. Added `make gen_other_html` to `make quick_www` and `make www`. Fixed inventory links for year level index.html files. Changed `bin/output-year-index.sh` VERSION from "1.0.1 2024-02-23" to "1.1 2024-02-27". Added missing lines in `manifest.numbers`. Update the affected `.entry.json` files. The manifest (in both `manifest.numbers` and the collection of manifests from of all entry `.entry.json` files) now match. Errors from `make verify_entry_files` will now abort both `make quick_www` and `make www` rules in the top level `Makefile`. Changed markdown files in manifest to have an _inventory_order_ of _2000000000_ so that the `index.html` file will usually appear at the start of the _Secondary files_ set for the "#inventory" section of an entry's `index.html` file. Changed compressed tar files (files that end in _.tar.bz2_) in manifest to have an _inventory_order_ of _100000_ so that these files will usually appear at the end of the _Primary files_ set for the "#inventory" section of an entry's `index.html` file. Added 'Jump to top` link above the _Primary files_ section. Changed `bin/output-index-inventory.sh` VERSION from "1.1.1 2024-02-23" to "1.2 2024-02-27". Updated HTML files to perform the above via `make www`.
This commit is contained in:
1 parent
7babf792e4
commit
9d3438fb88
718 files changed
+17515
-4084
No files matched your search
@@ -0,0 +1,464 @@
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||||
<!-- START: two lines up starts content from: inc/top.default.html -->
|
||||
<!-- -->
|
||||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||||
<!-- -->
|
||||
<!-- END: this line ends content from: inc/top.default.html -->
|
||||
<!-- -->
|
||||
<!-- The original markdown content was formed by the tool: bin/gen-other-html.sh -->
|
||||
<!-- The HTML was converted from markdown by the tool: bin/md2html.sh -->
|
||||
<!-- -->
|
||||
<!-- START: this line starts content from: inc/head.default.html -->
|
||||
|
||||
<head>
|
||||
<link rel="stylesheet" href="../../ioccc.css">
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
|
||||
<title>The International Obfuscated C Code Contest</title>
|
||||
<meta name="description" content="terminals.md for 2020/ferguson1">
|
||||
<meta name="keywords" content="IOCCC, 2020/ferguson1, terminals.md">
|
||||
</head>
|
||||
|
||||
<!-- END: this line ends content from: inc/head.default.html -->
|
||||
<!-- START: this line starts content from: inc/body.default.html -->
|
||||
|
||||
<body>
|
||||
|
||||
<!-- END: this line ends content from: inc/body.default.html -->
|
||||
<!-- START: this line starts content from: inc/header.default.html -->
|
||||
|
||||
<div class="header">
|
||||
<img src="../../png/ioccc.png" alt="IOCCC image by Matt Zucker" width=300 height=110>
|
||||
<h1>The International Obfuscated C Code Contest</h1>
|
||||
<h2>terminals.md for 2020/ferguson1</h2>
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/header.default.html -->
|
||||
<!-- START: this line starts content from: inc/topnav.up2index.html -->
|
||||
|
||||
<div class="topnav">
|
||||
<a class="Left" href="index.html">↑ jump to index.html ↑</a>
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/topnav.up2index.html -->
|
||||
<!-- START: this line starts content from: inc/begin-row.default.html -->
|
||||
|
||||
<div class="row">
|
||||
|
||||
<!-- END: this line ends content from: inc/begin-row.default.html -->
|
||||
<!-- START: this line starts content from: inc/begin-leftcolumn.default.html -->
|
||||
|
||||
<div class="leftcolumn">
|
||||
|
||||
<!-- END: this line ends content from: inc/begin-leftcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/sidenav.default.html -->
|
||||
|
||||
<div class="sidenav">
|
||||
<a href="#content">Jump to contents</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="../../index.html">IOCCC Home</a>
|
||||
<a href="../../years.html">Winning Entries</a>
|
||||
<a href="../../authors.html">People who have won</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="../../news.html">IOCCC News</a>
|
||||
<a href="../../faq.html#submit">How to enter the IOCCC</a>
|
||||
<a href="../../faq.html">FAQ</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="../../bugs.html">Bugs & (mis)features</a>
|
||||
<a href="../../faq.html#fix_an_entry">Fixing IOCCC entries</a>
|
||||
<a href="../../faq.html#fix_web_site">Fixing the web site</a>
|
||||
<a href="../../faq.html#fix_author">Fixing author info</a>
|
||||
<a href="../../thanks-for-help.html">Thanks for the help</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="../../judges.html">The IOCCC Judges</a>
|
||||
<a href="../../contact.html">Contacting the IOCCC</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="#top">Jump to top</a>
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/sidenav.default.html -->
|
||||
<!-- START: this line starts content from: inc/end-leftcolumn.default.html -->
|
||||
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/end-leftcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/begin-rightcolumn.default.html -->
|
||||
|
||||
<div class="rightcolumn">
|
||||
|
||||
<!-- END: this line ends content from: inc/begin-rightcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/before-content.default.html -->
|
||||
|
||||
<a name="content"></a>
|
||||
|
||||
<!-- END: this line ends content from: inc/before-content.default.html -->
|
||||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
|
||||
<h1 id="terminals">Terminals</h1>
|
||||
<p>Terminals are very easy to mess up and for that reason they deserve
|
||||
their own file. I discuss terminal capabilities, dimensions (setting and
|
||||
how to restore sanity if it causes any problems) as well as colours
|
||||
(limitations etc.).</p>
|
||||
<p><a name="toc"></a></p>
|
||||
<ul>
|
||||
<li><p><a href="#termcaps">Capabilities support testing
|
||||
program</a></p></li>
|
||||
<li><p><a href="#dimensions">Setting the game dimensions</a></p>
|
||||
<ul>
|
||||
<li><p><a href="#linescolumns">The LINES and COLUMNS environmental
|
||||
variables</a></p></li>
|
||||
<li><p><a href="#insanity">Terminal insanity</a></p></li>
|
||||
<li><p><a href="#restore">Restoring the terminal</a></p></li>
|
||||
<li><p><a href="#abuse">Terminal size abuse</a></p></li>
|
||||
</ul></li>
|
||||
<li><p><a href="#termlimitations">Terminal limitations</a></p></li>
|
||||
<li><p><a href="#colours">Terminal colours</a></p>
|
||||
<ul>
|
||||
<li><p><a href="#background">Curses background</a></p></li>
|
||||
<li><p><a href="#monochrome">Monochrome terminals</a></p></li>
|
||||
<li><p><a href="#colourlimitations">Colour limitations</a></p></li>
|
||||
<li><p><a href="#disablecolour">Disabling colour</a></p></li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
<h1
|
||||
id="capabilities-support-testing-program"><a name="termcaps" href="#toc">Capabilities
|
||||
support testing program</a></h1>
|
||||
<p>Although it should be playable without the features I use (except
|
||||
that cursor movement is required) I have provided a source file that can
|
||||
test your terminal for the capabilities I use in the entry.</p>
|
||||
<p>It also tries to determine the minimum number of columns to play
|
||||
without the status line overflowing - even with the dynamic length.
|
||||
Try:</p>
|
||||
<div class="sourceCode" id="cb1"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> make test</span></code></pre></div>
|
||||
<p>This compiles the program <a href="termcaps.c">termcaps.c</a> and
|
||||
runs it; you should see something like:</p>
|
||||
<pre><code>terminal supports cursor movement
|
||||
terminal supports making cursor invisible
|
||||
terminal supports bold
|
||||
terminal supports colours
|
||||
|
||||
terminal rows 41 (38 playable)
|
||||
terminal cols 155 (153 playable)
|
||||
|
||||
snake size: 997 (max size: 5776)
|
||||
bugs: 199 (max size: 1155)
|
||||
|
||||
at least 34 columns (currently 155) recommended for snake size 997
|
||||
at least 37 columns (currently 155) recommended for capped snake size 5776
|
||||
|
||||
No problems detected.</code></pre>
|
||||
<p>Terminal rows and cols are the current values (the number of columns
|
||||
shown later as well). The snake size is the default size to win (based
|
||||
on the variables, see below). The <code>max size: 5776</code> is the
|
||||
capped size (or ‘capsize’). The 199 bugs is approximately the
|
||||
<code>snake_size / growth_size</code> i.e. how many bugs it will take to
|
||||
win the game. The max bugs in the <code>bugs</code> line is
|
||||
approximately <code>max_snake_size / growth_size</code> i.e. how many
|
||||
bugs it’ll take to win at the maximum (capped) snake size.</p>
|
||||
<p>If I pass in any of the variables <strong><code>GROW</code></strong>,
|
||||
<strong><code>MAXSIZE</code></strong>,
|
||||
<strong><code>SIZE</code></strong> and/or
|
||||
<strong><code>LINES</code></strong> or
|
||||
<strong><code>COLUMNS</code></strong> it bases its calculations on those
|
||||
variables. For example:</p>
|
||||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">terminal</span> supports cursor movement</span>
|
||||
<span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a><span class="ex">terminal</span> supports making cursor invisible</span>
|
||||
<span id="cb3-3"><a href="#cb3-3" aria-hidden="true" tabindex="-1"></a><span class="ex">terminal</span> supports bold</span>
|
||||
<span id="cb3-4"><a href="#cb3-4" aria-hidden="true" tabindex="-1"></a><span class="ex">terminal</span> supports colours</span>
|
||||
<span id="cb3-5"><a href="#cb3-5" aria-hidden="true" tabindex="-1"></a></span>
|
||||
<span id="cb3-6"><a href="#cb3-6" aria-hidden="true" tabindex="-1"></a><span class="ex">terminal</span> rows 41 <span class="er">(</span><span class="ex">38</span> playable<span class="kw">)</span></span>
|
||||
<span id="cb3-7"><a href="#cb3-7" aria-hidden="true" tabindex="-1"></a><span class="ex">terminal</span> cols 155 <span class="er">(</span><span class="ex">153</span> playable<span class="kw">)</span></span>
|
||||
<span id="cb3-8"><a href="#cb3-8" aria-hidden="true" tabindex="-1"></a></span>
|
||||
<span id="cb3-9"><a href="#cb3-9" aria-hidden="true" tabindex="-1"></a><span class="ex">snake</span> size: 5776 <span class="er">(</span><span class="ex">max</span> size: 5776<span class="kw">)</span></span>
|
||||
<span id="cb3-10"><a href="#cb3-10" aria-hidden="true" tabindex="-1"></a> <span class="ex">bugs:</span> 5771 <span class="er">(</span><span class="ex">max</span> size: 5771<span class="kw">)</span></span>
|
||||
<span id="cb3-11"><a href="#cb3-11" aria-hidden="true" tabindex="-1"></a></span>
|
||||
<span id="cb3-12"><a href="#cb3-12" aria-hidden="true" tabindex="-1"></a><span class="ex">at</span> least 37 columns <span class="er">(</span><span class="ex">currently</span> 155<span class="kw">)</span> <span class="ex">recommended</span> for snake size 5776 </span>
|
||||
<span id="cb3-13"><a href="#cb3-13" aria-hidden="true" tabindex="-1"></a><span class="ex">at</span> least 37 columns <span class="er">(</span><span class="ex">currently</span> 155<span class="kw">)</span> <span class="ex">recommended</span> for capped snake size 5776 </span>
|
||||
<span id="cb3-14"><a href="#cb3-14" aria-hidden="true" tabindex="-1"></a></span>
|
||||
<span id="cb3-15"><a href="#cb3-15" aria-hidden="true" tabindex="-1"></a><span class="ex">No</span> problems detected.</span></code></pre></div>
|
||||
<p>As you can see it tells you the max size (the ‘capsized’ snake) as
|
||||
well as the requested max size (if the requested size is bigger than the
|
||||
capped size then it will be set to that value instead) of the snake. The
|
||||
capped size is like in the Snake game itself but the suggested minimum
|
||||
number of columns is based on a number of variables.</p>
|
||||
<p>If I were to do the above but set columns to less < 35 then there
|
||||
would be a problem. But why if the utility recommends at least 37? This
|
||||
is because the max size of the snake also depends on the terminal size.
|
||||
This utility is not perfect: I don’t consider shedding; I set growth to
|
||||
5 if it’s 0 (since it would be indeterminate how many bugs are possible
|
||||
before ‘winning’ since there would be no ‘winning’); and there are
|
||||
probably other things too.</p>
|
||||
<p>As for capabilities: besides cursor movement the others are just nice
|
||||
to have. From my tests keeping the cursor visible doesn’t ruin gameplay
|
||||
but it is less distracting if nothing else to have it invisible (in fact
|
||||
due to the sequence of function calls the cursor would mostly appear to
|
||||
be not in the game field itself - from memory at least).</p>
|
||||
<p>Maybe there are other capabilities I should check for that I’m
|
||||
unaware of but this should give you an idea.</p>
|
||||
<p>If there are any problems it will say how many (fatal and otherwise).
|
||||
The fatal problems are if curses fails to initialise or if movement of
|
||||
cursor cannot be done (both seem unlikely to happen nowadays).</p>
|
||||
<p>Both scripts run this utility and prompt if there are any problems;
|
||||
you can continue either way.</p>
|
||||
<h1
|
||||
id="setting-the-game-dimensions"><a name="dimensions" href="#toc">Setting
|
||||
the game dimensions</a></h1>
|
||||
<p>There are a number of ways to do this and only one will keep the
|
||||
terminal sane all the time but that’s by running it under a terminal
|
||||
emulator that you can resize the window with first. But what if you want
|
||||
exacts?</p>
|
||||
<h2
|
||||
id="the-lines-and-columns-environmental-variables"><a name="linescolumns" href="#toc">The
|
||||
LINES and COLUMNS environmental variables</a></h2>
|
||||
<p>To specify the lines/columns of curses program per instance use the
|
||||
<code>LINES</code> and <code>COLUMNS</code> environmental variables.</p>
|
||||
<p>For demonstration consider the following:</p>
|
||||
<pre><code> $ echo $LINES $COLUMNS
|
||||
42 157</code></pre>
|
||||
<p>Note: I subtract 1 from the max y/x and the max coords in the game
|
||||
output include the walls and score line but these values are for the
|
||||
terminal itself.</p>
|
||||
<p>Say you want 55 columns:</p>
|
||||
<pre><code> $ COLUMNS=55 ./prog</code></pre>
|
||||
<p>This will force curses to detect the max columns (X) of your terminal
|
||||
(for the game dimensions) - to be 55; it might look like this
|
||||
instead:</p>
|
||||
<pre><code> X:27/54 Y:20/41 S:5/997 B:0</code></pre>
|
||||
<p>But problems can arise with messing with dimensions: in my tests this
|
||||
held only to lines.</p>
|
||||
<h2 id="terminal-insanity"><a name="insanity" href="#toc">Terminal
|
||||
insanity</a></h2>
|
||||
<p>Terminal sanity can be compromised and it can cause all sorts of
|
||||
output problems; it might not appear right away but it will show its
|
||||
ugly head eventually if you use it. For example pager output might be
|
||||
screwy, echo might be turned off, output of commands might overwrite the
|
||||
input of those commands, etc. For the game you might not see the final
|
||||
score.</p>
|
||||
<h3 id="restoring-the-terminal"><a name="restore" href="#toc">Restoring
|
||||
the terminal</a></h3>
|
||||
<p>In my tests there is one thing that at least allows you to see the
|
||||
final score and that is by running <code>clear</code> before running the
|
||||
program. That’s what the prog.alt version does. You might run it as one
|
||||
of:</p>
|
||||
<pre><code> LINES=20 ./prog.alt
|
||||
LINES=20 ./snake.alt</code></pre>
|
||||
<p>Even if the final score is visible though the terminal may very well
|
||||
still be messed up. There are numerous things you might try but probably
|
||||
the easiest is to run the game again without modifying the dimensions
|
||||
(and then just quit) or even just the <code>reset</code> command.</p>
|
||||
<p>The Linux man page says:</p>
|
||||
<pre><code>You might have to run the `reset` tool like:
|
||||
|
||||
<LF>reset<LF>
|
||||
|
||||
(the line-feed character is normally control-J) to get the terminal
|
||||
to work, as carriage-return may no longer work in the abnormal state.</code></pre>
|
||||
<p>If you don’t have the reset utility you can try:</p>
|
||||
<pre><code> echo -e \\033c</code></pre>
|
||||
<p>Otherwise try <code>clear; stty sane</code> (that will turn on echo
|
||||
also) or if all else fails log out and back in.</p>
|
||||
<p>For more information on this subject generally see the <a
|
||||
href="https://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO.html">Linux
|
||||
keyboard and console HOWTO</a> (specifically <a
|
||||
href="https://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-4.html">Linux
|
||||
keyboard and console HOWTO section 4</a>). Yes this works under macOS
|
||||
(at least it did for me).</p>
|
||||
<h3 id="terminal-size-abuse"><a name="abuse" href="#toc">Terminal size
|
||||
abuse</a></h3>
|
||||
<p>So players 1, 2 and 3 are content with not meddling with the terminal
|
||||
sizes outside what’s actually possible with their screen. But then
|
||||
player 4 comes along and thinks he/she will be clever and mess with the
|
||||
dimensions a bit. Let’s say they have a 13” monitor and they think it’d
|
||||
be funny to see how 997 lines would work; they might try something
|
||||
like:</p>
|
||||
<pre><code> LINES=997 ./prog</code></pre>
|
||||
<p>What then? Well expect trouble; curses will not know any better and
|
||||
the max number of lines will be 997. If they were to do:</p>
|
||||
<pre><code> COLUMNS=997 ./prog</code></pre>
|
||||
<p>Then they will see a different effect. Again the same reason: the
|
||||
player trying to be funny.</p>
|
||||
<p>The game will try and be funny in return and you can expect it to not
|
||||
function properly. Because that’s what funny means in this context.</p>
|
||||
<h1
|
||||
id="terminal-limitations"><a name="termlimitations" href="#toc">Terminal
|
||||
limitations</a></h1>
|
||||
<p>It’d be nice if curses could detect hitting more than one arrow key
|
||||
at the same time so that diagonal directions would be possible but
|
||||
unfortunately it’s not (<code>cat -v</code> confirms this). Even if I
|
||||
were to define four extra keys what would they be? And what about the
|
||||
head character? The <a href="HACKING.html">HACKING.html</a> (<a
|
||||
href="HACKING.md">HACKING</a> on GitHub) file has information on
|
||||
this.</p>
|
||||
<p>I also limit the terminal size to 10 lines/columns but most likely it
|
||||
would require the cheat modes to win and in any event allowing certain
|
||||
low values causes problems e.g. <strong>LINES=6 COLUMNS=6</strong> and
|
||||
<strong>LINES=3 COLUMNS=3</strong> caused some nasty issues.</p>
|
||||
<h1 id="terminal-colours"><a name="colours" href="#toc">Terminal
|
||||
colours</a></h1>
|
||||
<p>N.B.: If all you’re after is wanting to change the colours see the
|
||||
script <a href="snake-colours.sh">snake-colours.sh</a> instead. The rest
|
||||
of this file was mostly notes for the judges; here I discuss the
|
||||
background, foreground as well as limitations (in particular runtime
|
||||
limitations).</p>
|
||||
<h2 id="curses-background"><a name="background" href="#toc">Curses
|
||||
background</a></h2>
|
||||
<p>The documentation I have seen says that the background will always be
|
||||
black and from a quick test this holds even with a terminal that has a
|
||||
white background. There is a way to force the background to remain white
|
||||
though that’s by way of monochrome (so no colours); I discuss that and
|
||||
another related terminal specific in the troubleshooting guide (there’s
|
||||
another way but it would take me over the iocccsize; I talk about it in
|
||||
the <a href="HACKING.html">HACKING.html</a> (<a
|
||||
href="HACKING.md">HACKING</a> on GitHub) file).</p>
|
||||
<h2
|
||||
id="monochrome-terminals"><a name="monochrome" href="#toc">Monochrome
|
||||
terminals</a></h2>
|
||||
<p>According to my tests for monochrome terminals the screen has the
|
||||
white and black background; if terminal is configured to be black
|
||||
background white foreground that is the order it is too. You can try
|
||||
that like:</p>
|
||||
<pre><code> TERM=linux-m ./prog</code></pre>
|
||||
<p>But I do not specifically check if the terminal has colours. Is there
|
||||
a curses implementation that has a problem here? Below I explain what to
|
||||
comment out should you need colours to be disabled but I personally have
|
||||
not run into any problems even with monochrome terminals. Later I say
|
||||
what to do to remove colour support in the source code itself.</p>
|
||||
<h2
|
||||
id="colour-limitations"><a name="colourlimitations" href="#toc">Colour
|
||||
limitations</a></h2>
|
||||
<p>According to X/Open Curses, Issue 7 (pg. 57):</p>
|
||||
<pre><code>With init_pair() and pair_content(), the value of pair must be in a range
|
||||
from 0 to and including COLOR_PAIRS-1. (There may be an
|
||||
implementation-specific upper limit on the valid value of pair, but any such
|
||||
limit is at least 63.) Valid values for f and b are the range from 0 to and
|
||||
including COLORS-1.</code></pre>
|
||||
<p>The manpage for <code>init_pair()</code> says this:</p>
|
||||
<pre><code> These limits apply to color values and color pairs. Values outside these limits are not legal, and may result in a runtime error:
|
||||
|
||||
[...]
|
||||
|
||||
COLOR_PAIRS corresponds to the terminal database's max_pairs capability, (see terminfo(5)).</code></pre>
|
||||
<p>Based on the two as well as the fact that monochrome terminals (I’ve
|
||||
tried under both Linux and macOS) seem to work fine I believe I am fine
|
||||
here too. And to confirm this I wrote the following code with the output
|
||||
below:</p>
|
||||
<pre><code> #include <curses.h>
|
||||
|
||||
int main()
|
||||
{
|
||||
initscr();
|
||||
start_color();
|
||||
printw("COLORS: %d\nCOLOR_PAIRS: %d\n", COLORS, COLOR_PAIRS);
|
||||
getch();
|
||||
endwin();
|
||||
}
|
||||
|
||||
TERM=linux-m ./colour_pairs
|
||||
COLORS: 0
|
||||
COLOR_PAIRS: 0</code></pre>
|
||||
<p>Without specifying the TERM I get:</p>
|
||||
<pre><code> COLORS: 256
|
||||
COLOR_PAIRS: 32767</code></pre>
|
||||
<p>In the case that colour is supported the standard states that there
|
||||
will be more possible colour pairs than I have used so that’s not a
|
||||
problem either. Perhaps even it would only be a runtime error if the
|
||||
colours are supported and the number is out of the range? To try and
|
||||
figure this out I did another test:</p>
|
||||
<pre><code> int main()
|
||||
{
|
||||
initscr();
|
||||
start_color();
|
||||
|
||||
init_pair(COLOR_PAIRS+1, COLOR_WHITE, COLOR_GREEN);
|
||||
bkgd(COLOR_PAIR(COLOR_PAIRS+1));
|
||||
init_pair(1, COLOR_WHITE, COLOR_BLACK);
|
||||
attron(COLOR_PAIR(1));
|
||||
printw("COLORS: %d\nCOLOR_PAIRS: %d\n", COLORS, COLOR_PAIRS);
|
||||
|
||||
getch();
|
||||
endwin();
|
||||
}</code></pre>
|
||||
<p>Running it like</p>
|
||||
<pre><code> TERM=linux-m ./colour_pairs</code></pre>
|
||||
<p>I got the output as if colours weren’t used: 0 and 0. With coloured
|
||||
terminals however it was not visible. If I however comment out the call
|
||||
to <code>bkgd()</code> I get instead:</p>
|
||||
<pre><code> COLORS: 256
|
||||
COLOR_PAIRS: 32767</code></pre>
|
||||
<p>Which leads me to believe that if you try using a value outside the
|
||||
range it won’t work for a colour-capable terminal but it doesn’t matter
|
||||
for monochrome terminals one way or another. And since I don’t go beyond
|
||||
the ranges (as I cited earlier) there shouldn’t be any problem here.</p>
|
||||
<h2 id="disabling-colour"><a name="disablecolour" href="#toc">Disabling
|
||||
colour</a></h2>
|
||||
<p>Nevertheless if it is a problem and you don’t want to use a
|
||||
monochrome terminal (or can’t):</p>
|
||||
<p>First comment out the code that has <code>start_color();</code> and
|
||||
then add <code>return;</code> to the top of the <code>C()</code>
|
||||
function (the rest of the code won’t be reached). If necessary you can
|
||||
also comment out the <code>init_pair()</code> calls.</p>
|
||||
<p>Perhaps you only need to add the <code>return;</code> to
|
||||
<code>C()</code>. My guess is that’s the case but I do not know for
|
||||
certain.</p>
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="width: 100%" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td>(c) Copyright 1984-2020, [Leo Broukhis, Simon Cooper, Landon Curt
|
||||
Noll][judges] - All rights reserved This work is licensed under a
|
||||
[Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].</td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>[judges]: https://www.ioccc.org/judges.html [cc]:
|
||||
http://creativecommons.org/licenses/by-sa/3.0/</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
<!-- START: this line starts content from: inc/after-content.default.html -->
|
||||
|
||||
<!-- END: this line ends content from: inc/after-content.default.html -->
|
||||
<!-- START: this line starts content from: inc/end-rightcolumn.default.html -->
|
||||
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/end-rightcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/end-row.default.html -->
|
||||
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/end-row.default.html -->
|
||||
<!-- START: this line starts content from: inc/footer.default.html -->
|
||||
|
||||
<div class="footer">
|
||||
<hr>
|
||||
<h2>Coda</h2>
|
||||
<p><a href="https://validator.w3.org/nu/?doc=#">Nu HTML check this web page</a></p>
|
||||
<p><a href="#top">Jump to top</a> <a href="#content">Jump to Content</a> <a href="#inventory">Jump to Inventory</a></p>
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/footer.default.html -->
|
||||
<!-- START: this line starts content from: inc/bottom.default.html -->
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
<!-- END: this line ends content from: inc/bottom.default.html -->
|
||||
Reference in new issue
Block a user