Convert misc pages to Markdown

This commit is contained in:
flokoe 2023-07-05 11:26:49 +02:00
parent 2c151a8682
commit 854c84588c
3 changed files with 155 additions and 0 deletions

52
docs/misc/bashphorisms.md Normal file
View File

@ -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.

View File

@ -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 */
```

35
docs/misc/shell_humor.md Normal file
View File

@ -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!