Pour tous ceux ayant des besoins 
de documentation/exemple de code, ou modes d’emploi, bref, tout ce que nous trouvons d’habitude dans les CheatSheets (Antisèche in French), il existe un outil en ligne de commande et un site web pour récupérer ce type d’info.
C’est donc multi-langages de programmation, multi-domaines.
Il existe de nombreux moyens d’exploiter les informations, depuis votre éditeur, depuis la ligne de commande, etc.
Avantages, entre autres :
- Zéro installation, dispo partout par inet
- Mise à jour coopérative
- 56 langages de programmation
- Plusieurs DBMS
- Au choix, interface curl/browser
- 1000 commandes unix-linux essentielles
- Utilisable en direct dans votre éditeur
il est auto-documenté. La version courte et rapide, frappez en ligne de commande :
curl cht.sh/:help
et vous aurez l’aide en direct.
Pour plus de détail, en anglais, et oui :
- Se trouve sur GitHub, // la plus user-friendly
- S’affiche en tapant
curl cht.sh/:intro - Se lit sur le site cheat.sh/:intro
Pour chaque langage, il y a 4 Sheets particulières. Essayez :
- curl cht.sh/lua
- curl cht.sh/lua/hello
- curl cht.sh/lua/:list
- curl cht.sh/lua/:learn
De manière basique, il suffit de lancer en ligne de commande des requêtes CURL sur cheat.sh (abrégé cht.sh).
Exemple 0: (pour à peu près 1000 commandes *nix )
curl cht.sh/tar~extract
cheat:tar
---
tags: [ compression ]
---
# To extract an uncompressed archive:
tar -xvf /path/to/foo.tar
# To extract a .gz archive:
tar -xzvf /path/to/foo.tgz
# To extract a .bz2 archive:
tar -xjvf /path/to/foo.tgz
# To extract a .tar in specified Directory:
tar -xvf /path/to/foo.tar -C /path/to/destination/
tldr:tar
# Extract a specific file without preserving the folder structure:
tar xf source.tar source.tar/path/to/extract --strip-components=depth_to_strip
Exemple 1:
curl cheat.sh/python/json
réponse :
# python - What's the best way to parse a JSON response from the ...
#
# If you're using Requests, you should use the response's json
# (http://docs.python-requests.org/en/latest/user/quickstart/json-
# response-content) method. It guesses which UTF encoding was used if no
# encoding was specified (https://github.com/requests/requests/blob/4ea0
# 9e49f7d518d365e7c6f7ff6ed9ca70d6ec2e/requests/models.pyL868-L892) and
# uses the simplejson package if it is installed (https://github.com/req
# uests/requests/blob/4ea09e49f7d518d365e7c6f7ff6ed9ca70d6ec2e/requests/
# compat.pyL28-L31).
import requests
response = requests.get(...)
data = response.json()
# [pswaminathan] [so/q/16877422] [cc by-sa 3.0]
Exemple 2:
curl cht.sh/sql/join
-- SQL | JOIN USING vs JOIN ON
--
-- For the most part, it is a matter of style (and the fact that not all
-- databases support using). There is one small difference. If you do:
select *
from t1 join
t2
on t1.col1 = t2.col1
-- Then col1 appears twice in the result set. If you do:
select *
from t1 join
t2
using (col1)
-- Then col1 appears only once.
--
-- One aspect of using that I like is that it encourages foreign keys to
-- have the same names as primary keys. When this is possible (and it is
-- not always possible), I think this is a good design that makes
-- databases easier to use.
--
-- There are situations where using could do unexpected things. In long
-- chains of joins, it doesn't specify where the keys come from.
-- However, I don't find this to be a problem in well-designed databases.
--
-- On the other hand, natural joins are an abomination and should never
-- be used. They do not specify the columns being joined. They do not
-- even respect foreign key relationships. Not being clear on the
-- columns being compared is just an invitation for bugs in the code --
-- bugs that can be really, really hard to find.
--
-- [Gordon Linoff] [so/q/45531762] [cc by-sa 3.0]
Exemple 3:
curl cht.sh/bash/for
# shell - Bash 'for' loop syntax?
#
# Replace
for (($i=0...
# with
for ((i=0;i<10;i++))
# [jman] [so/q/6854118] [cc by-sa 3.0]
Il y a plein de manières de faire des requêtes. RTFM ! 
