cheat.sh 安装及使用
你需要的唯一备忘录 https://cheat.sh/
[root@python3 ~]# curl cht.sh
_ _ _ __
___| |__ ___ __ _| |_ ___| |__ \ \ The only cheat sheet you need
/ __| '_ \ / _ \/ _` | __| / __| '_ \ \ \ Unified access to the best
| (__| | | | __/ (_| | |_ _\__ \ | | |/ / community driven documentation
\___|_| |_|\___|\__,_|\__(_)___/_| |_/_/ repositories of the world
+------------------------+ +------------------------+ +------------------------+
| $ curl cheat.sh/ls | | $ cht.sh btrfs | | $ cht.sh lua/:learn |
| $ curl cht.sh/btrfs | | $ cht.sh tar~list | | Learn any* programming |
| $ curl cht.sh/tar~list | | | | language not leaving |
| $ curl https://cht.sh | | | | your shell |
| | | | | *) any of 60 |
| | | | | |
+-- queries with curl ---+ +- own optional client --+ +- learn, learn, learn! -+
+------------------------+ +------------------------+ +------------------------+
| $ cht.sh go/f| | $ cht.sh --shell | | $ cht.sh go zip lists |
| go/for go/func | | cht.sh> help | | Ask any question using |
| $ cht.sh go/for | | ... | | cht.sh or curl cht.sh: |
| ... | | | | /go/zip+lists |
| | | | | (use /,+ when curling) |
| | | | | |
+---- TAB-completion ----+ +-- interactive shell ---+ +- programming questions-+
+------------------------+ +------------------------+ +------------------------+
| $ curl cht.sh/:help | | $ vim prg.py | | $ time curl cht.sh/ |
| see /:help and /:intro | | ... | | ... |
| for usage information | | zip lists _ | | real 0m0.075s |
| and README.md on GitHub| | KK | | |
| for the details | | *awesome* | | |
| *start here*| | | | |
+--- self-documented ----+ +- queries from editor! -+ +---- instant answers ---+
[Follow @igor_chubin for updates][github.com/chubin/cheat.sh] 命令行下统一访问世界上最好的备忘录，支持56种编程语言，超快，通常在100毫秒内返回答案，有一个方便的客户端，cht.sh。
具体使用请详见https://github.com/chubin/cheat.sh
安装客户端
#下载，可以叫任何名字
curl https://cht.sh/:cht.sh > ~/bin/cht.sh
#赋予执行权限即可
chmod +x ~/bin/cht.shlinux命令帮助，比man命令好看多了
[root@python3 ~]# cht.sh tar
# To extract an uncompressed archive:
tar -xvf /path/to/foo.tar
# To create an uncompressed archive:
tar -cvf /path/to/foo.tar /path/to/foo/
# To extract a .gz archive:
tar -xzvf /path/to/foo.tgz
# To create a .gz archive:
tar -czvf /path/to/foo.tgz /path/to/foo/
# To list the content of an .gz archive:
tar -ztvf /path/to/foo.tgz
# To extract a .bz2 archive:
tar -xjvf /path/to/foo.tgz
# To create a .bz2 archive:
tar -cjvf /path/to/foo.tgz /path/to/foo/
# To extract a .tar in specified Directory:
tar -xvf /path/to/foo.tar -C /path/to/destination/
# To list the content of an .bz2 archive:
tar -jtvf /path/to/foo.tgz
# To create a .gz archive and exclude all jpg,gif,... from the tgz
tar czvf /path/to/foo.tgz --exclude=\*.{jpg,gif,png,wmv,flv,tar.gz,zip} /path/to/foo/
# To use parallel (multi-threaded) implementation of compression algorithms:
tar -z ... -> tar -Ipigz ...
tar -j ... -> tar -Ipbzip2 ...
tar -J ... -> tar -Ipixz ...python 命令帮助
[root@python3 ~]# cht.sh python append file
# python - How do you append to a file?
with open("test.txt", "a") as myfile:
myfile.write("appended text")sql语句帮助，mysql，oracle等都支持
[root@python3 ~]# cht.sh sql select
-- sql - Why is SELECT * considered harmful?
--
-- There are really three major reasons:
--
-- * Inefficiency in moving data to the consumer. When you SELECT *,
-- you're often retrieving more columns from the database than your
-- application really needs to function. This causes more data to move
-- from the database server to the client, slowing access and increasing
-- load on your machines, as well as taking more time to travel across
-- the network. This is especially true when someone adds new columns to
-- underlying tables that didn't exist and weren't needed when the
-- original consumers coded their data access.
-- * Indexing issues. Consider a scenario where you want to tune a
-- query to a high level of performance. If you were to use , and it
-- returned more columns than you actually needed, the server would often
-- have to perform more expensive methods to retrieve your data than it
-- otherwise might. For example, you wouldn't be able to create an index
-- which simply covered the columns in your SELECT list, and even if you
-- did (including all columns [shudder*]), the next guy who came around
-- and added a column to the underlying table would cause the optimizer
-- to ignore your optimized covering index, and you'd likely find that
-- the performance of your query would drop substantially for no readily
-- apparent reason.
-- * Binding Problems. When you SELECT , it's possible to retrieve
-- two columns of the same name from two different tables. This can
-- often crash your data consumer. Imagine a query that joins two
-- tables, both of which contain a column called "ID". How would a
-- consumer know which was which? SELECT can also confuse views (at
-- least in some versions SQL Server) when underlying table structures
-- change the view is not rebuilt, and the data which comes back can
-- be nonsense (http://www.mssqltips.com/tip.asp?tip=1427). And the
-- worst part of it is that you can take care to name your columns
-- whatever you want, but the next guy who comes along might have no way
-- of knowing that he has to worry about adding a column which will
-- collide with your already-developed names.
--
-- But it's not all bad for SELECT *. I use it liberally for these use
-- cases:
--
-- * Ad-hoc queries. When trying to debug something, especially off
-- a narrow table I might not be familiar with, SELECT * is often my best
-- friend. It helps me just see what's going on without having to do a
-- boatload of research as to what the underlying column names are. This
-- gets to be a bigger "plus" the longer the column names get.
-- * When * means "a row". In the following use cases, SELECT * is
-- just fine, and rumors that it's a performance killer are just urban
-- legends which may have had some validity many years ago, but don't
-- now:
SELECT COUNT(*) FROM table;
in this case, means "count the rows". If you were to use a column name instead of , it would count the rows where that column's value was not null. COUNT(), to me, really drives home the concept that you're counting rows*, and you avoid strange edge-cases caused by NULLs being eliminated from your aggregates.
Same goes with this type of query:
SELECT a.ID FROM TableA a
WHERE EXISTS (
SELECT *
FROM TableB b
WHERE b.ID = a.B_ID);
in any database worth its salt, just means "a row". It doesn't matter what you put in the subquery. Some people use b's ID in the SELECT list, or they'll use the number 1, but IMO those conventions are pretty much nonsensical. What you mean is "count the row", and that's what signifies. Most query optimizers out there are smart enough to know this. (Though to be honest, I only know this to be true with SQL Server and Oracle.)
-- [Dave Markle] [so/q/3639861] [cc by-sa 3.0]powershell命令也支持
[root@python3 ~]# cht.sh powershell get-aduser