Linuxgems – A succinct cheat sheet for newbie Linux coders and sysadmins(github.com)
github.com
Linuxgems – A succinct cheat sheet for newbie Linux coders and sysadmins
https://github.com/kevinthew/linuxgems
59 comments
If this is really aimed toward newbies, it’s going to cause a lot of confusion that there are Debian-only commands (apt-get, etc), whereas the claim is that it’s Linux cheat sheet.
Agreed. A note that this only applies to Debian based distros would be good. Also have some example of package managers for other mainstream distros and an example of what to search for for looking up your distro's package manager.
As someone who started on Debian, it was a hump to get over to realize which software was Debian specific. Best to get that out of the way early.
As someone who started on Debian, it was a hump to get over to realize which software was Debian specific. Best to get that out of the way early.
Ugh, these cheat sheets are so misleading.
For example:
They mention 'sudo -s' but omit 'sudo -i' which is better, and generally more desirable.
The use of 'iwconfig'. iwconfig has been deprecated for 8 years now and isn't even included in RHEL anymore[0].
[0] https://access.redhat.com/solutions/1194553#:~:text=Resoluti....
For example:
# Forensically clone filesystems and do other low-level operations on files. Very dangerous:
dd
They mention 'sudo -s' but omit 'sudo -i' which is better, and generally more desirable.
The use of 'iwconfig'. iwconfig has been deprecated for 8 years now and isn't even included in RHEL anymore[0].
[0] https://access.redhat.com/solutions/1194553#:~:text=Resoluti....
dd is dangerous in context, because it is used as root/sudo to write to a block device, which can corrupt your whole system, not just one file at a time.
i am forced to do sudo -s, enter my password and then enter
echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
this is because somehow my usb is broken on motherboard and it makes cpu 100% with full fan running, some over current issue. this command disables all usb.
the problem is i am forced to open terminal, up, enter password, enter, up, enter, exit, exit on every boot time.
it gets tiring and i found no good way for bash to automate typing password on sudo -s. any ideas?
echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
this is because somehow my usb is broken on motherboard and it makes cpu 100% with full fan running, some over current issue. this command disables all usb.
the problem is i am forced to open terminal, up, enter password, enter, up, enter, exit, exit on every boot time.
it gets tiring and i found no good way for bash to automate typing password on sudo -s. any ideas?
There are multiple ways to fix this, here's some of the methods of the top of my head ranked best to worst:
1: Write a udev rule to unbind the 0000:00:14.0 device when detected. This is the best solution, and a google search can show you how. But does require some underlying knowledge of devices and udev. [A][B][C]
2: Create a systemd startup service that runs your above commands at startup. This is less elegant than the above, but the end result would mostly be the same. [H]
3: Configure sudo to not require a password, then create an xdg-autostart script that runs your command. [W][X]
[A] https://wiki.gentoo.org/wiki/Udev
[B] https://www.linuxquestions.org/questions/linux-software-2/ud...
[C] https://github.com/Roboy/flexrayusbinterface/issues/13
[H] https://wiki.archlinux.org/title/systemd#Writing_unit_files
[W] https://phpraxis.wordpress.com/2016/09/27/enable-sudo-withou...
[X] https://specifications.freedesktop.org/autostart-spec/autost...
1: Write a udev rule to unbind the 0000:00:14.0 device when detected. This is the best solution, and a google search can show you how. But does require some underlying knowledge of devices and udev. [A][B][C]
2: Create a systemd startup service that runs your above commands at startup. This is less elegant than the above, but the end result would mostly be the same. [H]
3: Configure sudo to not require a password, then create an xdg-autostart script that runs your command. [W][X]
[A] https://wiki.gentoo.org/wiki/Udev
[B] https://www.linuxquestions.org/questions/linux-software-2/ud...
[C] https://github.com/Roboy/flexrayusbinterface/issues/13
[H] https://wiki.archlinux.org/title/systemd#Writing_unit_files
[W] https://phpraxis.wordpress.com/2016/09/27/enable-sudo-withou...
[X] https://specifications.freedesktop.org/autostart-spec/autost...
The hack would be to put it in rc.local but don’t do that. The more correct way would be to make an init.d/systemd service to run on boot, which executes as root.
The most correct solution would be to get a new keyboard or re-pin your usb connector.
The most correct solution would be to get a new keyboard or re-pin your usb connector.
Yup that should do it
this is a laptop so i am out of luck on that one.
Other answers are better, but in the shell you can do above without a separate sudo login. For example:
echo -n "0000:00:14.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind
echo -n "0000:00:14.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind
>The use of 'iwconfig'. iwconfig has been deprecated for 8 years now and isn't even included in RHEL anymore
well the github repository's last commit was 10 years ago so...
well the github repository's last commit was 10 years ago so...
In this case a [2012] tag seems appropriate. Its a dead project.
dd's reputation comes from someone calling it "disk destroyer" a long time ago. This is one in a long and storied line of such articles that predate the web: https://cloudnull.io/2011/12/dd-and-the-mighty-disk-destroye...
Usually when something is targeted at beginners it was written by a beginner or intermediate person who hasn't yet realized how much better they can understand the $THING.
I think there is a cultural misapprehension of what these tidbits of knowledge we share with one another should be seen as.. It's usually framed as something the person who wrote it knows and that the person who reads it should learn.. and that's kinda what is happening, but everything I wrote after the ".." to try and pinpoint how to shift this framing is not going to get across. Maybe in a real conversation..
I think there is a cultural misapprehension of what these tidbits of knowledge we share with one another should be seen as.. It's usually framed as something the person who wrote it knows and that the person who reads it should learn.. and that's kinda what is happening, but everything I wrote after the ".." to try and pinpoint how to shift this framing is not going to get across. Maybe in a real conversation..
It is like the running joke on Haskell circles, the first thing one does after finally getting monads is to write a blog post about how monads are like burritos.
Starts pretty early with "pwd", "ls", "rm", "cp", but does not mention "cd" anywhere. Might be good to review the grouping of commands.
Several years ago, I put on a tutorial workshop for a bunch of truly fresh "never opened Terminal before" beginners that I think was well-received. I don't have a video of it unfortunately (although I think someone did record it), but here is the script I followed: https://github.com/gwerbin/unix-cli-tutorial
This was a 2-hour seminar with lots of interactive demos and Q&A. I don't think you can provide this kind of information in a cheat sheet. It's a completely different and new way of interacting with your computer for most people nowadays. A good learning resource is one that gives the learner enough context to make sense of what they are doing, but not overwhelming them with unnecessary information... and that's hard to do.
This was a 2-hour seminar with lots of interactive demos and Q&A. I don't think you can provide this kind of information in a cheat sheet. It's a completely different and new way of interacting with your computer for most people nowadays. A good learning resource is one that gives the learner enough context to make sense of what they are doing, but not overwhelming them with unnecessary information... and that's hard to do.
why write the 100th listing of basic commands?
Previous discussion (previous GitHub repository seems to have been deleted): https://news.ycombinator.com/item?id=5340181
The title should probably contain a reference to the year since it has last been updated (2012).
I'd like to point out that the following statement from the cheat sheet is incorrect:
Examples for such documents have been found since the original cheat sheet has been published: https://shattered.io/ It is now trivial to produce an arbitrary number of documents with hash collisions, although it is not trivial (yet?) to find a second document which has the same checksum as a specific document.
The title should probably contain a reference to the year since it has last been updated (2012).
I'd like to point out that the following statement from the cheat sheet is incorrect:
# Checksum a file (safer algorithm with no hash collisions):
sha1sum
Examples for such documents have been found since the original cheat sheet has been published: https://shattered.io/ It is now trivial to produce an arbitrary number of documents with hash collisions, although it is not trivial (yet?) to find a second document which has the same checksum as a specific document.
Appreciate this is about 10 years old but just in case any newbies do actually look at this...
This bit is quite iffy, and potentially dangerously so:
> # All files in target directory. (Be very careful.):
> /*
On it's own this will be all paths in the file system root (system directories like /bin/ /var/ etc.).
A better way to describe it would be:
> # All files in the current directory
> ./*
Or
> ./[dirname]/*
If you're running things as the root user always make sure to check your paths!
This bit is quite iffy, and potentially dangerously so:
> # All files in target directory. (Be very careful.):
> /*
On it's own this will be all paths in the file system root (system directories like /bin/ /var/ etc.).
A better way to describe it would be:
> # All files in the current directory
> ./*
Or
> ./[dirname]/*
If you're running things as the root user always make sure to check your paths!
1. This was written in 2012, and it mostly applies to Debian/Ubuntu-derived Linux only.
2. The cheat_sheet.org.sh file should be renamed to Readme.md for more newbie friendliness. Github doesn't render the file correctly as-is. But, as this was last updated a decade ago, it probably will not happen.
2. The cheat_sheet.org.sh file should be renamed to Readme.md for more newbie friendliness. Github doesn't render the file correctly as-is. But, as this was last updated a decade ago, it probably will not happen.
Looks nice. I've got my own cheat sheet, if anyone is interested: https://github.com/r0f1/linuxhelp
My addendums:
tail -f
# -f follows live files. Very useful for watching log files from /var/log in real time
grep -Iir “pattern” *
# search local and subdirectories for pattern, skip binary files, case insensitive. Handy for searching whole source trees
tail -f file | grep “pattern”
# useful for live watching very busy logs where you know a specific pattern you’re looking for
find . | grep “filenamepattern”
# search the local directory and down for filenames matching a pattern. Find actually has arguments for doing the search itself, but I know grep already. For more structured types of searches “e.g. I want to find a file named that is of a particular type”, man find
tail -f
# -f follows live files. Very useful for watching log files from /var/log in real time
grep -Iir “pattern” *
# search local and subdirectories for pattern, skip binary files, case insensitive. Handy for searching whole source trees
tail -f file | grep “pattern”
# useful for live watching very busy logs where you know a specific pattern you’re looking for
find . | grep “filenamepattern”
# search the local directory and down for filenames matching a pattern. Find actually has arguments for doing the search itself, but I know grep already. For more structured types of searches “e.g. I want to find a file named that is of a particular type”, man find
To extend a little:
> tail -f
Or
> find . | grep
I add “-type f” to find's params when doing that, as I'm almost invariably doing something that I don't want to apply to sub-directories (just the files within them).
Also if sending the file list to grep for searching the contents not the names:
> tail -f
Or
tail -f filename-to-watch
> find . | grep
I add “-type f” to find's params when doing that, as I'm almost invariably doing something that I don't want to apply to sub-directories (just the files within them).
Also if sending the file list to grep for searching the contents not the names:
find . -type f -print0 | xargs -0 grep options-and-stuff-to-find
find . -type f -exec grep stuff-to-find {} \;
> if looking at a file that might be renamed and stop updating (i.e. log files that are rotated). Without a filename the file descriptor is followed so when for instance access.log becomes access.log.1 your display keeps following access.log.1 not the new access.log which is probably what you want.
I believe that's true if you name a file as well (just tested it on Ubuntu). You keep following the original file you named, even if it becomes renamed; you don't follow a new file by the same name.
Using something like "watch -n5 tail filename" polls every few seconds to show the bottom of a file, and goes for the current file at that filename each time.
I believe that's true if you name a file as well (just tested it on Ubuntu). You keep following the original file you named, even if it becomes renamed; you don't follow a new file by the same name.
Using something like "watch -n5 tail filename" polls every few seconds to show the bottom of a file, and goes for the current file at that filename each time.
Ah, checking the man-page it would seem that you need to use the long-form option for the behaviour I described to work:
That works too, and for many other uses, but doesn't allow scroll-back which can be significant when a lot of information comes through at once.
tail --follow=file-to-follow-by-name
That works too, and for many other uses, but doesn't allow scroll-back which can be significant when a lot of information comes through at once.
--follow does not take a file name.
There is no difference between long and short options, at least not in this case.
There is no difference between long and short options, at least not in this case.
The manpage appears to differ on those facts: https://manpages.debian.org/bullseye/coreutils/tail.1.en.htm...
"Use --follow=name in that case. That causes tail to track the named file in a way that accommodates renaming, removal and creation."
I will test to be extra sure when I have a few minutes spare.
"Use --follow=name in that case. That causes tail to track the named file in a way that accommodates renaming, removal and creation."
I will test to be extra sure when I have a few minutes spare.
Nothing in that sentence says that --follow takes a filename. `name` in that sentence is not a standin for a filename.
Ah, yes. It looks like I was combining misreading with misremembering, wronging mashing “tail -f some-file” and “tail --follow=name some-file” into “tail --follow=some-file”.
Though there is a difference between the short and long forms as -f can't take the extra parameter. “-f=name” is incorrect as it takes “=” to be a short-form option and “-f name” also as it takes “name” to be one of the objects to tail. As per the manpage and --help, for that behaviour you need “-F”. As well as meaning “--follow=name” that also implies “--retry”, though I can't think of a circumstance where this would be a problem.
Though there is a difference between the short and long forms as -f can't take the extra parameter. “-f=name” is incorrect as it takes “=” to be a short-form option and “-f name” also as it takes “name” to be one of the objects to tail. As per the manpage and --help, for that behaviour you need “-F”. As well as meaning “--follow=name” that also implies “--retry”, though I can't think of a circumstance where this would be a problem.
`tail -F` is what you're looking for. No need to implement it manually with `watch`.
TIL! Thanks
As a note,
find . -type f -exec grep stuff {} \;
find . -type f -exec grep stuff {} + # note plus sign
Ah, yes, the other reason not to use that form: remembering to use + instead of ; for efficiency! No point removing xargs just to add in many more invocations of the target command.
I used to use find and grep together but find is really so easy to use by itself:
find . -name 'filenamepattern'
Really fgrep (or grep -F) should be used if there's no need for grep magic.
This is from a decade ago. While I'm sure the fundamentals haven't changed much, are there any more up-to-date versions?
`ls` seems to have changed (unless ls has distro specific arguments). When I use `ls -r` I get reverse order. To get sub-directories, I have to use `ls -R`. I'm running Mint.
I don't think it has changed. IIRC recursive in ls has always (in the near ¼ century I've been using Linux and occasionally other unix-a-likes) been specified with an upper-case R. I suspect an uncorrected typo.
These might help:
* https://github.com/jlevy/the-art-of-command-line notes and tips on using the command-line, suitable for both beginners and experienced users
* https://github.com/tldr-pages/tldr collection of community-maintained help pages for command-line tools
* http://www.compciv.org/unix-tools/ examples for most common usecases
* https://devmanual.gentoo.org/tools-reference/bash/index.html Bash reference cheatsheet
* https://github.com/jlevy/the-art-of-command-line notes and tips on using the command-line, suitable for both beginners and experienced users
* https://github.com/tldr-pages/tldr collection of community-maintained help pages for command-line tools
* http://www.compciv.org/unix-tools/ examples for most common usecases
* https://devmanual.gentoo.org/tools-reference/bash/index.html Bash reference cheatsheet
Thank you!
A cheat sheet for newbies and a search for tmux yields nothing ?
Surely anyone who does any sort of remote work on Linux (perhaps ESPECIALLY newbie sysadmins) needs to have tmux ingrained into their muscle memory as the very first thing you do when you SSH in.
Surely anyone who does any sort of remote work on Linux (perhaps ESPECIALLY newbie sysadmins) needs to have tmux ingrained into their muscle memory as the very first thing you do when you SSH in.
I tend to not use tmux unless I know I'm going to need multiple shells out of the gate. If I get more than 4 terminal tabs then I'll switch over to tmux. But to each their own.
> But to each their own.
I should perhaps clarify that my recommendation for tmux was predominantly being made because of the "what happens when my SSH connection drops".
Being able to ssh back in and do "tmux at" and resume where you left off, I'm not sure there's a better tool out there than tmux.
I should perhaps clarify that my recommendation for tmux was predominantly being made because of the "what happens when my SSH connection drops".
Being able to ssh back in and do "tmux at" and resume where you left off, I'm not sure there's a better tool out there than tmux.
Abduco or dtach are probably easier for beginners. I, for one, am not that bothered by the drops, because if the connection is really choppy I tend to just use mosh. Also I have a few connections made via ZeroTier and I found that the connection is remarkably stable. That's all with a huge asterisk, that I am not enough bothered to improve my setup.
Not everyone has unstable connections, nor need to be logged-in to remote systems for long periods of time.
> tmux at
`tmux a` also works as a shortcut to "attach".
> tmux at
`tmux a` also works as a shortcut to "attach".
strange decision to cater towards newbies by publishing something for org-mode
'publishing' is doing some heavy lifting here... I wonder why the author didn't prefer a .org extension on the file. GitHub does a pretty decent job of displaying org-mode as if it were written in Github flavored markdown.
Never mind! I see that this was committed some 10 years ago now. I'm not sure how long GitHub has been doing org-mode rendering or if this was originally hosted in GitHub.
> # Forensically clone filesystems and do other low-level operations on files. Very dangerous:
> dd
this kind of mindset is not helping and IMO only alienates newcomers (they seem to be the target here) from the many uses that dd has (other than overwriting your data)
> dd
this kind of mindset is not helping and IMO only alienates newcomers (they seem to be the target here) from the many uses that dd has (other than overwriting your data)
As far as I can tell, the danger is around the of=somefile option. Maybe because the english word "of" feels more like "from" than "to", and "out file" isn't the first thing that comes to mind.
absolutely the case. i'm new to Linux and wasn't around in the good old terminal only days - the abbreviations are arcane
why is ch change directory but chmod is change mode? why not cm? or chd?
i had to look this one up because the only explanation i was given for the name of the command dd was 'disk destroyer'. had to go into some old forum to learn that cc was already taken for make and so they just went to the next letter down the line??
it's buck wild in there. i like it, but i've taken to just treating some commands like magic spells because the commands are so impenetrable
why is ch change directory but chmod is change mode? why not cm? or chd?
i had to look this one up because the only explanation i was given for the name of the command dd was 'disk destroyer'. had to go into some old forum to learn that cc was already taken for make and so they just went to the next letter down the line??
it's buck wild in there. i like it, but i've taken to just treating some commands like magic spells because the commands are so impenetrable
Kind of reminds me of github Awesome pages. Here is a bash one https://github.com/joseluisq/awesome-bash-commands
Tangent: visually/design wise, what cheat-sheet formats do you like the most? What is a good UI to consume cheat sheets from?
This is a pretty decent cheat sheet. It might be worth noting that not all these commands may be available on every Linux distribution. In fact, there is no set of commands or packages guaranteed to be installed on every distro.
Though I'd guess that most distros should have bash[0], coreutils[1], findutils[2], util-linux[3], procps[4], as well as the usual text wrangling commands such as grep(1), sed(1), and awk(1).
From there on, browsing through man pages is a great way of gaining a deep understanding of a specific command. However, man pages are often too verbose and technical for those unfamiliar with the command. So prior to viewing man pages I find it useful to use cheat.sh[5] to see what my typical use cases of a command are, I then consult the manuals to figure out what each option means.
Eg.
[1] https://www.gnu.org/software/coreutils/
[2] https://www.gnu.org/software/findutils/
[3] https://en.wikipedia.org/wiki/Util-linux
[4] https://gitlab.com/procps-ng/procps
[5] https://github.com/chubin/cheat.sh
Though I'd guess that most distros should have bash[0], coreutils[1], findutils[2], util-linux[3], procps[4], as well as the usual text wrangling commands such as grep(1), sed(1), and awk(1).
From there on, browsing through man pages is a great way of gaining a deep understanding of a specific command. However, man pages are often too verbose and technical for those unfamiliar with the command. So prior to viewing man pages I find it useful to use cheat.sh[5] to see what my typical use cases of a command are, I then consult the manuals to figure out what each option means.
Eg.
$ curl cht.sh/tldr:tar
...
# Create an archive from files:
tar cf target.tar file1 file2 file3
# Create a gzipped archive:
tar czf target.tar.gz file1 file2 file3
...
[1] https://www.gnu.org/software/coreutils/
[2] https://www.gnu.org/software/findutils/
[3] https://en.wikipedia.org/wiki/Util-linux
[4] https://gitlab.com/procps-ng/procps
[5] https://github.com/chubin/cheat.sh
ifconfig is obsolete and superseded by ip and related tools.
ifconfig -a ip addr