[HN Gopher] Linuxgems - A succinct cheat sheet for newbie Linux ...
___________________________________________________________________
Linuxgems - A succinct cheat sheet for newbie Linux coders and
sysadmins
Author : graderjs
Score : 118 points
Date : 2022-01-05 12:34 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| shmerl wrote:
| ifconfig is obsolete and superseded by ip and related tools.
| ifconfig -a
|
| - ip addr
|
| And so on.
| VeninVidiaVicii wrote:
| 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.
| jjice wrote:
| 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.
| r0f1 wrote:
| Looks nice. I've got my own cheat sheet, if anyone is interested:
| https://github.com/r0f1/linuxhelp
| nyolfen wrote:
| strange decision to cater towards newbies by publishing something
| for org-mode
| _ix wrote:
| '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.
| _ix wrote:
| 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.
| traceroute66 wrote:
| 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.
| dijksterhuis wrote:
| 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.
| traceroute66 wrote:
| > 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.
| hawski wrote:
| 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.
| johndough wrote:
| 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: # 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.
| jsisto wrote:
| Kind of reminds me of github Awesome pages. Here is a bash one
| https://github.com/joseluisq/awesome-bash-commands
| runjake wrote:
| 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.
| lijogdfljk wrote:
| Tangent: visually/design wise, what cheat-sheet formats do you
| like the most? What is a good UI to consume cheat sheets from?
| travisgriggs wrote:
| 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
| assbuttbuttass wrote:
| I used to use find and grep together but find is really so easy
| to use by itself: find . -name
| 'filenamepattern'
|
| The only difference is it's a glob, not a regex.
| dspillett wrote:
| To extend a little:
|
| _> tail -f_
|
| Or tail -f filename-to-watch
|
| 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).
| thestoicattack wrote:
| As a note, find . -type f -exec grep stuff
| {} \;
|
| will also invoke a new grep process for every file, which can
| be slow. If you think find is going to return a lot of files,
| it is often better to use find . -type f
| -exec grep stuff {} + # note plus sign
|
| which will replace {} with as many filenames as allowed (all
| correctly quoted, etc).
| dspillett wrote:
| 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.
| martinflack wrote:
| > 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.
| Arnavion wrote:
| `tail -F` is what you're looking for. No need to implement
| it manually with `watch`.
| dspillett wrote:
| Ah, checking the man-page it would seem that you need to
| use the long-form option for the behaviour I described to
| work: tail --follow=file-to-follow-by-
| name
|
| _> watch -n5 tail filename_
|
| 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.
| Arnavion wrote:
| --follow does not take a file name.
|
| There is no difference between long and short options, at
| least not in this case.
| traceroute66 wrote:
| Really _fgrep_ (or _grep -F_ ) should be used if there's no
| need for _grep_ magic.
| CraneWorm wrote:
| > # 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)
| tyingq wrote:
| 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.
| goblinux wrote:
| 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
| mmh0000 wrote:
| Ugh, these cheat sheets are so misleading.
|
| For example: # Forensically clone filesystems
| and do other low-level operations on files. Very dangerous:
| dd
|
| 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....
| indymike wrote:
| 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...
| lupire wrote:
| 2Gkashmiri wrote:
| 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?
| hawski wrote:
| 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
| dgfitz wrote:
| 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.
| 2Gkashmiri wrote:
| this is a laptop so i am out of luck on that one.
| 2Gkashmiri wrote:
| https://tecadmin.net/run-shell-script-as-systemd-service/
| this?
| mmh0000 wrote:
| 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...
| diogenesjunior wrote:
| >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...
| Fnoord wrote:
| In this case a [2012] tag seems appropriate. Its a dead
| project.
| dijksterhuis wrote:
| 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!
| notRobot wrote:
| This is from a decade ago. While I'm sure the fundamentals
| haven't changed much, are there any more up-to-date versions?
| asicsp wrote:
| 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
| notRobot wrote:
| Thank you!
| jaidan wrote:
| `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.
| dspillett wrote:
| I don't think it has changed. IIRC recursive in ls has always
| (in the near 1/4 century I've been using Linux and
| occasionally other unix-a-likes) been specified with an
| upper-case R. I suspect an uncorrected typo.
| ArtWomb wrote:
| How did I ever forget "apropos" exists ;)
| tyingq wrote:
| 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.
| zaidhaan wrote:
| 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 ...
|
| [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
| tyingq wrote:
| Starts pretty early with "pwd", "ls", "rm", "cp", but does not
| mention "cd" anywhere. Might be good to review the grouping of
| commands.
| nerdponx wrote:
| 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.
| lupire wrote:
| openfuture wrote:
| 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..
___________________________________________________________________
(page generated 2022-01-05 23:01 UTC)