`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.
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.
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.
'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.
Pretty sure "man -k some_keywords" is an alias for apropos, and might be easier to remember. Using a capital K searches all text versus just the short descriptions.
> # 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)
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
# -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
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.
> 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
which deals with the common issue of spaces in filenames. Or you can do
find . -type f -exec grep stuff-to-find {} \;
to avoid the extra invocation of xargs, but I consider this less beginner-friendly (you have to remember the “;” and that it usually needs to be escaped or the shell will take it as an end of statement marker and not pass it to find, the error message “missing argument to `-exec'” received when you forget it not particularly helpful IMO if you don't know _or_ temporarily draw a mental blank).
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.
> 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.
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.
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.
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.
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.
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.
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?
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.
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]
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.
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..
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.
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
Since there are only 2^160 possible SHA-1 checksums, but an infinite number of possible documents, there MUST be an infinite number of documents that map to the same SHA-1 checksum due to the pigeonhole principle.
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.
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.
$ 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
...
59 comments
[ 2.8 ms ] story [ 104 ms ] thread* 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
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.
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.
> 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)
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
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
Or
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.> 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:
which deals with the common issue of spaces in filenames. Or you can do to avoid the extra invocation of xargs, but I consider this less beginner-friendly (you have to remember the “;” and that it usually needs to be escaped or the shell will take it as an end of statement marker and not pass it to find, the error message “missing argument to `-exec'” received when you forget it not particularly helpful IMO if you don't know _or_ temporarily draw a mental blank).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.
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.
There is no difference between long and short options, at least not in this case.
"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.
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.
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 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.
> tmux at
`tmux a` also works as a shortcut to "attach".
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.
For example:
The 'dd' command is just a glorified 'cat' command. Calling 'dd' dangerous, is the same as calling 'cat' dangerous.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....
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?
The most correct solution would be to get a new keyboard or re-pin your usb connector.
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...
echo -n "0000:00:14.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind
well the github repository's last commit was 10 years ago so...
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!
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..
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:
Since there are only 2^160 possible SHA-1 checksums, but an infinite number of possible documents, there MUST be an infinite number of documents that map to the same SHA-1 checksum due to the pigeonhole principle.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.
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.
[0] https://www.gnu.org/software/bash/[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