Linux Learning Resources - Share Yours Too!

i'm currently using "The Linux Command Line" by william shotts, second paperback edition, and i have to say it's a great and current book. I only found one thing so far (i'm on page 40), that doesn't work: he says "cp -r dir1 dir2" will copy contents from the first directory to the second, but it doesn't. You have to do it like this: "cp dir1/* dir2".
 


1- Guides already on Linode.com on DigitalOcean.com
2- Official documentation
3- Set up a command line virtual machine or any command line tool as a basic lab
4- Will to experience and test and build.
5- online free videos.
So many guys on youtube.
I like videos bc the way things on linux are done can be done in different ways with different tools.
I like those videos that explaining everthing, and I don't like those which just tell you about some lazy scripts from gits. Most of those lazy scripts don't work. And I stay away from Indian youtubers. Very bad English, very bad explaining, very bad content, very poor explanations. I just can't forget those brown hands soldering cellphone camera module to a USB cable and snap to PC and work. They are all the same.
I just remember "HackerSploit" since he has an accent and I like the way he speaks English. Very easy to understand. And his channel is very old and updated frequently. He's worth donation. However his old YT vids, the font size of commandline is small. I always change command line to bigger size for demonstrations.
There are many youtube linux wizards out there. I find "ChrisTitusTech" has great content for the "linux experience" itself as he mentions it. The list will be updated.

I would stay away from Nullbyte. The linux security guide had a config mod to prevent rubber ducky attack, which locked my keyboard out. and then had me lose an installation. Stay away from them since they have lots of bells and whistles, but they don't deliver it.
 
One of my favorites has been the VimAdventures game/tutorial: https://vim-adventures.com/
i don't really like it, because it doesn't actually help you use vim to your advantage...the main thing it does it teach you how to use hjkl which you can't do in insert mode anyways. I've recently been using vim exclusively because nano doesn't really have a whole lot of navigation options, i think the trick with vim is overall is learning how to hack it to your advantage. For example, you can use some of sed's best features from inside the program:

Code:
:51,60d

That will erase all text from 51 to 60 and put the cursor at 51, doing that in nano is a lot more annoying and cumbersome with the "mark" feature.

You can also execute linux commands from vim's command mode, but that is a whole other can of worms...
 
i don't really like it, because it doesn't actually help you use vim to your advantage...the main thing it does it teach you how to use hjkl which you can't do in insert mode anyways.
Yeah, that's the main point of level 1. If you go beyond that, it's a really thorough introduction to the rest of vim. It doesn't get in to splitting the screen, plugins, or customizing vim with colors or remapping keys, but it does get you pretty competent pretty quickly. Later levels absolutely do get in to deletion, insertion, buffers, search...all kinds of stuff.
 
I am still learning about Fedora Workstation and the install went well, the updates just takes long to install. Reminds me of Windows.
 
I just recently started on this book again, I'm going to go ahead and start learning C because I really want to better understand the lower level stuff as well, but this book here has a really huge amount of information about how to make practical shell scripts, I'm very excited:


that link allows you to order the ebook and the pdf at once, which is ideal. You don't want to end up paying to much for ebooks alone, it's kinda a ripoff.

That's a book for advanced shell scripting though, it's not meant for beginners.
 
Last edited by a moderator:
I believe you'll find the kernel is moving to Rust.

While I fondly remember C, I'm not sure what C's future looks like. Will it end up like FORTRAN or COBOL? I do not know and I don't dare speculate.

By the way, if you can code in either of those (or MUMPS) well enough to maintain legacy code, you can pretty much write your own paycheck.
 
I believe you'll find the kernel is moving to Rust.

While I fondly remember C, I'm not sure what C's future looks like. Will it end up like FORTRAN or COBOL? I do not know and I don't dare speculate.

By the way, if you can code in either of those (or MUMPS) well enough to maintain legacy code, you can pretty much write your own paycheck.
Writing your own paycheck...hmmm!

I mostly want to learn c as a way of better understanding c++, rust, and/or assembly language. The guy who wrote the c for dummies book in 2021 expressed that he thinks c isn't going anywhere (as in, programmers will continue to use it), im not too concerned. What i want to do is write system applications and games, and maybe some prank not-malicous viruses. I think writing android games would be fun, non-contractual way to make a little extra income. Im more of a hobbiest orientation personally, i just think making programs is fun.
 
Last edited by a moderator:
If you are writing C code, than I highly recommend:
C: A Reference Manual, 5th edition by Harbison and Steele

It is a very helpful C language reference to have on hand as you write code.
 
I'm sorry if this is off-topic, but I learned a few things from Jarret on this site. <3

On occasion I get something from Distrowatch. Such as the weekly article they have now about how to use "ffmpeg" in a script to obtain the total running time of music media files. I got a few helpful scripts from "Linux Questions" site; I should really go and offer the link to the topic. :)

On occasion I read the Linux From Scratch book and learned a few more things about "terminal stuff". From there I found out about ~root, in case I needed to clear up the ".bash_history" for the "root" user.

Once on Stack Overflow or one of its associate sites, I got a script that determined how much free disk space there was and then set forth to create a huge file with zeroes. To then back up that whole disk image into a GZ archive. It was very slow and many experts wouldn't recommend it being done "regularly" on removable media. But because it was too slow and because I needed "more precise" ways of working with partitions and disks, I switched to Clonezilla.
 
I'm sorry if this is off-topic,

It's not, Wendy - that's fine. :)

Whenever I have to reinstall a distro, I first save its .bash_history , and if it is one that allows for Root user, also its Root .bash_history, it acts as a good headstart for me.

Gnome Disks also has a good partition imaging function (click the cog icon), and GParted a good partition copying function.

Dr Steven Shiau of University of Taiwan is the man behind Clonezilla, and he is ably assisted by Geza Kovacs (author of Unetbootin).

One of our well-known Members, fellow Aussie @bob466 , makes great use of Foxclone. And of course, there is always my favourite, Timeshift.

Cheers

Wizard
 
Whenever I have to reinstall a distro, I first save its .bash_history
I've never cared about that file but last week a weird problem appeared - something (unclear what) kept changing the permissions of bash history and every time I used the terminal, it would create ~/.bash_history-[number].tmp. These tmp files weren't temporary as their extension suggests. Normally a tmp file should disappear when you close the program that created it but these files didn't disappear and I had to delete them manually. So I put it to a test - changed the permissions back to normal, drove 2500 miles on ETS2 for a few hours and when I closed the game, bash history's permissions were changed again. The game has nothing to do with bash, so I seriously doubt that the game did the change. So I did the only remaining thing I could think of - changed the permissions back to normal and then made the file immutable. After I made it immutable, the terminal no longer saves history of commands (not that I care, anyway) but also the tmp files stopped appearing. :cool:
Once again my linux learning resource was... linux. :D
 
I've never cared about that file but last week a weird problem appeared - something (unclear what) kept changing the permissions of bash history and every time I used the terminal, it would create ~/.bash_history-[number].tmp. These tmp files weren't temporary as their extension suggests. Normally a tmp file should disappear when you close the program that created it but these files didn't disappear and I had to delete them manually. So I put it to a test - changed the permissions back to normal, drove 2500 miles on ETS2 for a few hours and when I closed the game, bash history's permissions were changed again. The game has nothing to do with bash, so I seriously doubt that the game did the change. So I did the only remaining thing I could think of - changed the permissions back to normal and then made the file immutable. After I made it immutable, the terminal no longer saves history of commands (not that I care, anyway) but also the tmp files stopped appearing. :cool:
Once again my linux learning resource was... linux. :D
Those .bash_history-##.tmp files which appeared in the dotfiles of the home directory did eventually stop propagating after upgrading. I can't recall how many upgrades it took for the proliferating to stop, but it did eventually.

Meantime, the way I dealt with the issue was to create a systemd service that deleted the .tmp files, together with a systemd timer script that ran the service each time the machine booted. Each morning when the machine was booted up, the files would be deleted which limited their population.

When the .tmp files were no longer appearing after upgrades, the systemd service was disabled with the job done. I'm happy to share the contents of all the files I used to deal with this issue if you are interested. Of course there are other ways to deal with the issue, such as using cron for example, but the systemd system facilities suited my case, so that was that.
 
I suppose demonizing systemd will do, if you actively use and need bash history. But I've never needed that file bc everything here has an alias and I know the most of them by heart, which makes bash history redundant. "Unset HISTFILE" doesn't work either, so the perfect solution for me was to make the file immutable or as I like to call it - immortal, cuz after that command, nothing but a negative immutability can change the file in question.
 


Top