This is a general list of command line tricks I find myself doing on Linux. Most of these are often bad ideas and better suited alternatives for the job exist.
ncnetcat is all you need to send files between two Linux hosts that can reach each other:
# where you have the file
nc -l -p 3000 < file.zip`
# where you want the file
nc -w 3 senderIp 3000 > file.zip
This is insecure and rsync or scp are better options, but it surely works!
You can always quickly check with md5sum <file> for integrity.
git clone --depth <n>If you're cloning a project with a huge history you might want to add the --depth <n> flag to your git clones.
This is much quicker and only pulls the last <n> layers. Especially useful in build pipelines where you often don't
need the whole history!
git is mostly used to track changes in code and collaboration but it works just as fine with non-code and your private folder or config files.
You can git init in any folder and keep track of them using your usual git skills.
sshssh -ND <port> host@ip will open a SOCKS5 proxy on the specified port on your laptop.
Firefox and other programs that support SOCKS5 proxying can route all their traffic into SSH.
This traffic is encrypted and has "good" security (as safe as ssh is).
sshfsIf you can ssh into a server whose /etc/ssh/sshd_config has sftp enabled, you can mount directories you can access as local folders.
Because this happens at the filesystem level most programs won't really know the difference and reads will be transparently converted to network requests.
When you have a good network, a fast machine and a slow server, it might be quicker to mount the data directory locally and run the computation there.
There are better ways to share a folder over a network, like nfs or smb, sshfs often requires no prior configuration on the server.
If your Linux distribution isn't already mounting /tmp/ as tmpfs that resides in your RAM, you can mount a directory that lives in your ram where you see fit.
This is very useful when you need very fast filesystem access for a short time, as your RAM will be much faster than your disk.
Just don't ran out of ram!
Using tmpfs will also be very kind to your true disk if you need to download a lot of data (that fits in your ram) and then throw it away immediately. Don't waste precious disk writes!
You often meet the dd command while trying to flash an .iso to a usb stick, doing something like dd if=file.iso of=/dev/sda with your favorite options.
It's just as useful to make a backup of a disk by swapping the arguments, writing the content of the entire medium to an iso file.
If you want to have very quick and dirty backups of a device you could just zstd /dev/sda -o /mnt/sshfs-mounted-dir/home/server/backups/.
This compresses your disk/partition and sends it over safely to your server. Maybe don't use it at work, but I totally did back up small SD cards this way.
grep-pingText search is remarkably useful when navigating codebases and scouring for pretty much anything, really. You often know the content of a file you're looking for, but you might not even know where to start looking for it.
grep-ping for CodebasesIf an application whose codebase you have access to returns you a cryptic error message, a good start could be
rg <error_message>
Which would return, if the error string is from this codebase at all, the locations where it might have been thrown: the actual text string must be somewhere in the codebase regardless of language choice.
Looking for symbol names and how they are used is my primary way of navigating unfamiliar codebases!
In some languages you can grep for specific patterns to narrow your searches.
For instance, if I see a struct named HideAndSeek in Rust, I can grep for the structure declaration pattern:
$ rg "struct HideAndSeek"
bin/main.rs
171:struct HideAndSeek<'a> {
Mileage depends on how searchable your language keywords are and on your regex skills.
You also get to personalize your search results and formats using the classic grep flags, such as -A and -B if you want more context, etc...
grep-ping for everythingIf your disk is fast enough, it might be actually quick to grep the whole filesystem, or maybe just /etc/.
Are you on some unfamiliar Linux system, looking for a familiar configuration file? You could use find, sure, but what about plain grep -rP?
You can even grep an entire block device, your whole /dev/sda. Who's stopping you? It probably isn't what you're looking for, but it will find strings in files, and might make
sense if your filesystem is broken and you desperately need to recover some files.
Your command history is also something useful grepping into.
I just wanted to compile a short list of things I haven't seen many people exploiting regularly to full potential. If any similar trick comes to your mind, dear reader, please contact me in any way for additions.