Convert misc pages to Markdown

docs/misc/bashphorisms.md

@@ -0,0 +1,52 @@
+# The Bashphorisms
+
+Bashphorisms are aphorisms for the IRC channel `#bash` on Freenode. Keep
+in mind that this version is a snapshot, the bashphorisms are changed
+here and there. Also, [another
+snapshot](http://mywiki.wooledge.org/BashFAQ/064).
+
+I think `greycat` was the first one who had the idea, but I\'m not sure.
+
+Our bashphorisms can be queried from `greybot` using `!bN`, where `N` is
+the bashphorism number.
+
+And yes, these bashphorisms reflect the daily reality in `#bash`.
+
+  Number   Bashphorism
+  -------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------
+  0        The questioner will never tell you what they are really doing the first time they ask.
+  1        The questioner\'s first description of the problem/question will be misleading.
+  2        The questioner will keep changing the question until it drives the helpers in the channel insane.
+  3        Offtopicness will continue until someone asks a bash question that falls under bashphorisms 1 and/or 2, and `greycat` gets pissed off.
+  4        The questioner will not read and apply the answers he is given but will instead continue to practice bashphorism #1 and bashphorism #2.
+  5        The ignorant will continually mis-educate the other noobies.
+  6        When given a choice of solutions, the newbie will always choose the wrong one.
+  7        The newbie will always find a reason to say, \"It doesn\'t work.\"
+  8        If you don\'t know to whom the bashphorism\'s referring, it\'s you.
+  9        All examples given by the questioner will be broken, misleading, wrong, and not representative of the actual question.
+  10       See B1
+  11       Please apply `(( % 10 ))` to the bashphorism value.
+  12       All logic is deniable; however, some logic will \*plonk\* you if you deny it.
+  13       Everyone ignores greycat when he is right. When he is wrong, it is !b1
+  14       The newbie doesn\'t actually know what he\'s asking. If he did, he wouldn\'t need to ask.
+  15       The more advanced you are, the more likely you are to be overcomplicating it.
+  16       The more beginner you are, the more likely you are to be overcomplicating it.
+  17       A newbie comes to #bash to get his script confirmed. He leaves disappointed.
+  18       The newbie will not accept the answer you give, no matter how right it is.
+  19       The newbie is a bloody loon.
+  20       The newbie will always have some excuse for doing it wrong.
+  21       When the newbie\'s question is ambiguous, the proper interpretation will be whichever one makes the problem the hardest to solve.
+  22       The newcomer will abuse the bot\'s factoid triggers for their own entertainment until someone gets annoyed enough to ask them to message it privately instead.
+  23       Everyone is a newcomer.
+  24       The newcomer will address greybot as if it were human.
+  25       The newbie won\'t accept any answer that uses practical or standard tools.
+  26       The newbie will not TELL you about this restriction until you have wasted half an hour.
+  27       The newbie will lie.
+  28       When the full horror of the newbie\'s true goal is revealed, the newbie will try to restate the goal to trick you into answering. Newbies are stupid.
+  29       It\'s always git. Or python virtualenv. Or docker. One of those pieces of shit. ALWAYS.
+  30       They won\'t show you the homework assignment. That would make it too easy.
+  31       Your teacher is a f\*\*king idiot.
+  32       The more horrifyingly wrong a proposed solution is, the more likely it will be used.
+  33       The newbie cannot explain what he is doing, or why. He will show you incomprehensible, nonworking code instead. What? You can\'t read his mind?!
+
+Please feel free to correct or extend this page whenever needed.

docs/misc/readthesourceluke.md

@@ -0,0 +1,68 @@
+Comments extracted from the bash source and therefore Copyright (C)
+1987-2004 Free Software Foundation, Inc. under the terms of the GNU
+General Public License etc..
+
+from `mailcheck.c`:
+
+``` C
+/* check_mail () is useful for more than just checking mail.  Since it has
+   the paranoids dream ability of telling you when someone has read your
+   mail, it can just as easily be used to tell you when someones .profile
+   file has been read, thus letting one know when someone else has logged
+   in.  Pretty good, huh? */
+```
+
+From `builtins/read.def`:
+
+``` C
+ /* If there are no variables, save the text of the line read to the
+     variable $REPLY.  ksh93 strips leading and trailing IFS whitespace,
+     so that `read x ; echo "$x"' and `read ; echo "$REPLY"' behave the
+     same way, but I believe that the difference in behaviors is useful
+     enough to not do it.  Without the bash behavior, there is no way
+     to read a line completely without interpretation or modification
+     unless you mess with $IFS (e.g., setting it to the empty string).
+     If you disagree, change the occurrences of `#if 0' to `#if 1' below. */
+```
+
+from `variables.c`:
+
+``` C
+     /*
+      * 24 October 2001
+      *
+      * I'm tired of the arguing and bug reports.  Bash now leaves SSH_CLIENT
+      * and SSH2_CLIENT alone.  I'm going to rely on the shell_level check in
+      * isnetconn() to avoid running the startup files more often than wanted.
+      * That will, of course, only work if the user's login shell is bash, so
+      * I've made that behavior conditional on SSH_SOURCE_BASHRC being defined
+      * in config-top.h.
+      */
+```
+
+From `shell.h`:
+
+``` C
+/* Values that can be returned by execute_command (). */
+#define EXECUTION_FAILURE 1
+#define EXECUTION_SUCCESS 0
+
+/* Usage messages by builtins result in a return status of 2. */
+#define EX_BADUSAGE     2
+
+/* Special exit statuses used by the shell, internally and externally. */
+#define EX_RETRYFAIL    124
+#define EX_WEXPCOMSUB   125
+#define EX_BINARY_FILE  126
+#define EX_NOEXEC       126
+#define EX_NOINPUT      126
+#define EX_NOTFOUND     127
+
+#define EX_SHERRBASE    256     /* all special error values are > this. */
+
+#define EX_BADSYNTAX    257     /* shell syntax error */
+#define EX_USAGE        258     /* syntax error in usage */
+#define EX_REDIRFAIL    259     /* redirection failed */
+#define EX_BADASSIGN    260     /* variable assignment error */
+#define EX_EXPFAIL      261     /* word expansion failed */
+```

docs/misc/shell_humor.md

@@ -0,0 +1,35 @@
+# Shell Humor
+
+Nothing special, just my private collection of some more or less funny
+shell stuff I saw during the years.
+
+Usually Bash and/or Linux (GNU Toolset) specific.
+
+    $ %blow
+    -bash: fg: %blow: no such job
+
+    $ ar m god
+    ar: creating god
+
+    $ touch /pussy
+    touch: cannot touch `/pussy': Permission denied
+
+    $ mount; fsck; fsck; fsck; umount; sleep
+
+    # the lover variant
+    $ unzip; strip; touch; finger; grep; mount; fsck; more; yes; fsck; fsck; umount; sleep
+
+    # it's not directly funny, only because it's not obvious that this is an sed command
+    # for the <<<, it works only in Bash
+    $ sed streetlight <<< reeter
+    lighter
+
+    # see above for comments
+    $ sed statement <<< cat
+    cement
+
+    $ \(-
+    bash: (-: command not found
+
+    $ echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
+    GET A LIFE!