diff options
Diffstat (limited to 'docs/busybox.net/programming.html')
| -rw-r--r-- | docs/busybox.net/programming.html | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/docs/busybox.net/programming.html b/docs/busybox.net/programming.html index f54f018ed..f5433f519 100644 --- a/docs/busybox.net/programming.html +++ b/docs/busybox.net/programming.html @@ -22,7 +22,7 @@ <li><a href="#who">Who are the BusyBox developers?</a></li> </ul> -<h2><b><a name="goals" />What are the goals of busybox?</b></h2> +<h2><b><a name="goals">What are the goals of busybox?</a></b></h2> <p>Busybox aims to be the smallest and simplest correct implementation of the standard Linux command line tools. First and foremost, this means the @@ -31,7 +31,7 @@ and cleanest implementation we can manage, be <a href="#standards">standards compliant</a>, minimize run-time memory usage (heap and stack), run fast, and take over the world.</p> -<h2><b><a name="design" />What is the design of busybox?</b></h2> +<h2><b><a name="design">What is the design of busybox?</a></b></h2> <p>Busybox is like a swiss army knife: one thing with many functions. The busybox executable can act like many different programs depending on @@ -53,9 +53,9 @@ binaries for each applet, and a "libbb.so" to make the busybox common code available as a shared library. Neither is ready yet at the time of this writing.</p> -<a name="source" /> +<a name="source"></a> -<h2><a name="source_applets" /><b>The applet directories</b></h2> +<h2><a name="source_applets"><b>The applet directories</b></a></h2> <p>The directory "applets" contains the busybox startup code (applets.c and busybox.c), and several subdirectories containing the code for the individual @@ -95,7 +95,7 @@ html, txt, and man page formats) in the docs directory. See <a href="#adding">adding an applet to busybox</a> for more information.</p> -<h2><a name="source_libbb" /><b>libbb</b></h2> +<h2><a name="source_libbb"><b>libbb</b></a></h2> <p>Most non-setup code shared between busybox applets lives in the libbb directory. It's a mess that evolved over the years without much auditing @@ -110,7 +110,7 @@ of open(), close(), read(), and write() that test for their own failures and/or retry automatically, linked list management functions (llist.c), command line argument parsing (getopt_ulflags.c), and a whole lot more.</p> -<h2><a name="adding" /><b>Adding an applet to busybox</b></h2> +<h2><a name="adding"><b>Adding an applet to busybox</b></a></h2> <p>To add a new applet to busybox, first pick a name for the applet and a corresponding CONFIG_NAME. Then do this:</p> @@ -151,10 +151,10 @@ bugs. Be sure to try both "allyesconfig" and "allnoconfig" (and </ul> -<h2><a name="standards" />What standards does busybox adhere to?</a></h2> +<h2><a name="standards">What standards does busybox adhere to?</a></h2> <p>The standard we're paying attention to is the "Shell and Utilities" -portion of the <a href=http://www.opengroup.org/onlinepubs/009695399/>Open +portion of the <a href="http://www.opengroup.org/onlinepubs/009695399/">Open Group Base Standards</a> (also known as the Single Unix Specification version 3 or SUSv3). Note that paying attention isn't necessarily the same thing as following it.</p> @@ -330,7 +330,7 @@ return 0 unless it has hit the end of input, and an attempt to write 0 bytes should be ignored by the OS.)</p> <p>As for short writes, play around with two processes piping data to each -other on the command line (cat bigfile | gzip > out.gz) and suspend and +other on the command line (cat bigfile | gzip > out.gz) and suspend and resume a few times (ctrl-z to suspend, "fg" to resume). The writer can experience short writes, which are especially dangerous because if you don't notice them you'll discard data. They can also happen when a system is under @@ -340,7 +340,7 @@ text console scrolling...)</p> <p>So will data always be read from the far end of a pipe at the same chunk sizes it was written in? Nope. Don't rely on that. For one -counterexample, see <a href="http://www.faqs.org/rfcs/rfc896.html">rfc 896</p> +counterexample, see <a href="http://www.faqs.org/rfcs/rfc896.html">rfc 896 for Nagle's algorithm</a>, which waits a fraction of a second or so before sending out small amounts of data through a TCP/IP connection in case more data comes in that can be merged into the same packet. (In case you were |