Please recommend me a good free online course to learn linux or bsd console.

hi , i know how to tinker with terminal do this and that a bit , but never ever actually officially learned properly so i need…
for example that course should contain:
file editing from console
Oh, here's something important that nobody bothers mention in any tutorial: ⚠️ the single most important thing when learning *any* file editor ⚠️ is to learn the various ways to quit, escape, undo (and did I say quit?) from the editor, before you try to use it.

The first time you accidentally open an entire directory in vi or emacs and you don't know how to back out, you'll remember this tip. 🤣
 
Oh, here's something important that nobody bothers mention in any tutorial: ⚠️ the single most important thing when learning *any* file editor ⚠️ is to learn the various ways to quit, escape, undo (and did I say quit?) from the editor, before you try to use it.
I still rely on a Type :qa and press <Enter> to exit Vim prompt if sudo -e doesn't go to nano (I'm not sure on differences but some OSs and editors don't have that prompt with Ctrl + C leading to an online search how to exit what's assumed vim)

But learning how to do that proper is a good idea :p
 
All of the things listed above and more can be found in the O'Reilly book Classic Shell Scripting by Robbins & Beebe. It doesn't just cover shell scripting but also sed, awk, regexes, manual pages, processes etc.
I second this.

The OP's question can be summarized as "How I get into Unix[like]?"
As this thread shows: there are several points about it, and several ways.

It's boring, pointless, and above all impossible to first study everything of what's it all about in theory, and then start working with it. You better just start working with it. Pick the tasks you need to do with your machine(s) (first could be to realize a backup-plan), learn how to realize them, realize them, and then rate what you learned into the categories of the "jigsaw puzzle 'Unix'" which gains you the meta-knowledge what makes Unix so powerful, way above solving single tasks.

Those categories may be named as:

1. Shell. You already figured that out. You need to get used to shell usage. Unix means using the shell. GUI is an optional extra to the shell, not vice versa. The shell is where the power lies. And where most of the work is done. At least the work on and with the system.
Which shell is secondary. But I recommend to focus on sh, not bash.
At least for the start on FreeBSD.
You may add or change to (an)other shell(s) anytime later - or not. You better learn the internals first, before getting lost in the shell's features. The (important) internals are the same. What differs are the features (and some other things; but don't get us lost in details.)

Command line using will become computer usage by muscle memory, which means keyboard, not mouse shoving. That can only be trained by using it over, and over again.

Plus: Dig a bit into the shell internals (ls, cp, mv, rm, cd, mkdir, ln, ...), some core basic unix tools (cat, grep, find, wc, cut, paste, head, tail, awk,...) and an editor, of course. When combined you'll be amazed what you all can do with those! (For years I don't have no filemanager installed anymore. Don't need one.)

Plus: Dig a bit into shell scripting. This is not just the more sophisticated glue to make single commands, filters, and programs work together, but it's first choice to automate individual tasks on your machine(s).
That's what a computer is all about: automation.
Learning computering means to learn how to automate. Using computers means to automate jobs.
Anything else is consumption.

2. Unix Philosophy. Find also other texts about it. Try to understand the ideas behind it.
For example: Name and compare downsides and benefits of either having many small, combinable modules to one large monolithic "jack-of-all-trades", while considering at each: learning effort and work efficiency short- vs. long-term, flexibility, adaptability, conformability, suitability, universality, maintainability.
See every unix[like] comes by its very nature as a software development platform. It may be very basic, but it's there. It's not for to write steam's next bestseller, but to close the gap of what the other tools may lack.
"All a dwarf needs is an axe." [Terry Pratchett]

3. A hunch of C. This maybe is already advanced, and maybe not really unavoidable necessary, but sooner or later you will stumble over certain issues you better have at least an idea of the underlying programming of the system.
C is Unix. And as long as most parts are written in it: Unix is C.
You don't need to master C. You don't even have to program in it, especially not your daily production. Though some things I rather and quicker do with a small C-source than in a shell script, while for many other things using C was a madness. They better be done with a few lines in a shell-script (See: Master Foo and the Ten Thousand Lines), or in another language. Finding out yourself, which tools there are, what is used best for what, and above all what suits you best, is part of the adventure.
But IMO kind of a slightly advanced beginner's class knowledge of C, a bit more than just "hello world" is very valuable not only to better understand Unix, but when you deal with things not only at the very surface, but start to dig a bit into system's details, even into shallow waters.
But, as I said: C is not top priority. Shell and Unix Philosophy first.

The book fraxamo mentioned is a very good recommendation to get anybody from zero into advanced Unix usage on a very solid base, because it contains all the real important things.
Additionally I like to recommend Kochan, Wood, Shell Programming in Unix, Linux and OS X, Addison-Wesley
It can be used as a prelude to the first book. It does not cover that many topics, does not dive as deep into them, and does not bring you as advanced, but therefore it gets you quicker into the basics.
 
I can do this guys , thank you all for all these resources,books,guidance,motivation and most important the philosophy.

my dream is to become a hacker.

and a hacker needs to understand things better than the average user or the maker herself/himself.
 
I can do this guys , thank you all for all these resources,books,guidance,motivation and most important the philosophy.

my dream is to become a hacker.

and a hacker needs to understand things better than the average user or the maker herself/himself.
Heh, I took the case off a computer in an AutoCAD course in high school, reset the BIOS with jumper (to allow boot selection), booted a Rainbow password cracker CD, and got the local admin pass of every computer in a few mins :p

All I wanted to do was update the NVIDIA driver for better FPS in AutoCAD rendering :cool:
 
Heh, I took the case off a computer in an AutoCAD course in high school, reset the BIOS with jumper (to allow boot selection), booted a Rainbow password cracker CD, and got the local admin pass of every computer in a few mins :p

All I wanted to do was update the NVIDIA driver for better FPS in AutoCAD rendering :cool:
😄 wow impressive resetting the BIOS with jumper. crazy.

you must be the coolest hacker in the school.
 
Save your money.
OJT. On the job training. Learn by doing.
Just look-up something when you don't understand. Don't be afraid to wreck your system. Its FREE. Just copy your important config files to USB for backup.
Oh, here's something important that nobody bothers mention in any tutorial: ⚠️ the single most important thing when learning *any* file editor ⚠️ is to learn the various ways to quit, escape, undo (and did I say quit?) from the editor, before you try to use it.

The first time you accidentally open an entire directory in vi or emacs
I really think any new user should veer away from the old tools.
ee = Easy Editor is in base and for a new user or Linux Nano user it is the easiest to understand in my opinion.

I know for veterans this is blasphemy but the editor is your #1 command line tool and easy is better.
If you have to guess how to close a program it has failed.
 
Some one mentioned built-ins and I think it is very important part and not documented as well as they should be..

"Built-In" means your "User Shell" has its own set of built in commands.

Your shell History Command is one such "built-in". Because it is a built-in command the documentation is found under your shell documentation.

So man history shows you all built-in commands. Not helpful. Because history is a built-in command every user shell has its own manpage..
man csh for the stock FreeBSD user shell. History command is found in there but it is not an easy read.. Starts at "History Substitution".

Is this a good time to mention /bin/tcsh is symbolically linked to /bin/csh? It acts different due to its settings file.
 
Many of us grew up in the "old" days -- when you bought an expensive PC or Laptop -- turned it on, booted it up for the very first time and what you saw was:


... and... that's it ! :cool:

You either knew what do next or you stared at that prompt forever. I remember spending a wad of cash in the late 1980s when I was buying my first 8088 laptop computer, booting it up and that is exactly what I saw. So ya ! - those were the days of DOS (aka Disk Operating Systems).

UNIX/*BSD/Minix/Linux/etc was a "step above" the DOS prompt back in those days. With (any UNIX) then as in (now/today) -- you could immediately have 1-to-many actual "Users" all simultaneously connected to the same computer/PC/whatever all at the same time and all running their own programs and doing whatever they wanted all at the same time ... and they may not even be aware of each other. And the computer easily managed multiple sessions and everything "works"! All of these users shared modems, network cards, printers, disk space, pretty much everything all at the same time.

We also played multi-player games at "the terminal" - a popular multiplayer terminal game at the time was hunt(6) -- but I also played a lot of Peter Langston's Empire - Scroll down his page to "Empire". Hours and hours of wasted time !
 
Back
Top