i need a online course / interactive website course where i can learn from absolute beginner to advance topics about linux/bsd shell.
i would also like to know , how did you all learned freeBSD or linux from starting to advance? and how could anyone also learn effectively
I had the exact same situation as you when I switched from Windows to Linux distros. I had been doing some software development even on Windows, so I was using Git for Windows and thus got a clue about some very basic UNIX programs like
cd,
ls,
cat, etc... But in general, I knew pretty much nothing about operating the system from the console (got used to GUI). And now, looking back, I can defenitely tell you that the most efficient and effective way to learn it is practice. I don't mean that you should figure everything out yourself and don't ask people who have experience, but you don't need a 'course' or whatnot to follow, really. In fact, there's no course that would cover everything that you would like to know regarding administrating UNIX system, it's experience-based only. The 'course' presumably can only tell you about basic things, if someone really want to have a little bit structured guidance, I would recommend
FreeBSD Handbook that's the best sort of thing that I've seen so far.
I know that there is a confusion in the begining (and not only in the begining) that you don't even know what is possible and what the system can allow you to do (i.e. you don't know that there's a utility that can do this thing and can do this...). The answer is again - practice, but I can suggest to try:
apropos -s 1 . |less - this would list all the manual pages in the section 1 (general commands) and their description, so that you can familiarize yourself with the programs that you can use. See
apropos(1).
basic command line to advance command line
'Basic' programs is essentially a filesystem navigation and operations on files, I guess? As I already mentioned,
FreeBSD Handbook explains it very very good.
There's no such thing as 'Advanced' command line I believe: you just use programs to fit your needs. Perhaps you meant 'sysadmin-specific' instead, i.e. programs that allow you to configure your system? These programs are in the 8 section of
man(1), so you can do the
apropos(1) trick that I mentioned before and see what programs are there.
Well, that's fairly simple: if you want to see the manual page for the utility named X, you just type:
man X. If X has a manual page in multiple sections, say, 1 and 2, in order to get manual from section 1, you type:
man 1 X. So if you see that someone mentions for instance 'sysrc(8)', it means that you can read about this program in secion 8 of man pages, i.e.:
man 8 sysrc.
history of commands and how to use it
That's pretty simple too: every time you execute the command in the shell, it is saved in a special file (for instance, if you use
sh(1), this file is called
.sh_history) and then you can access them with shell keybindings (usually it is Arrow-{Up,Down} keys) and thus repeat recent commands.
file editing from console
Essentially, there are two main UNIX programs to edit text files:
ed(1) and
vi(1). Well, obviously, there is a whole host of different text editors (GUI, TUI), but these two are almost guaranteed to be in every system by default (though recently I noticed that this may not usually be the case for
ed(1)). I'm not very good with
vi(1), so I can't tell very much here, but for
ed(1), I strongly encourage you to give it a try,
I wrote a pretty descriptive post about it, you can read it.
In FreeBSD you also have
ee(1), which is so intuitive and simple you don't even have to learn it. I personally like this one
stdin , stderr etc redirection
I believe that
sh(1) may help here. But if short, every program you execute by default opens 3 files and uses integers (they are named file descriptors) to refer to them: 0 - stdin (from where the input comes), 1 - stdout (where output goes) and 2 - stderr (usually, this is where debug or error messages go, but it's not necessary). So, when you execute your command from terminal in interactive mode, stdin is your keyboard, stdout and stderr is your terminal. That means that everything you type on keyboard program will see as input, and, if program produces some output, you will see it on your screen. But this is by default, and you can change it:
program <file - now
program will read input from file
file.
program >file - now
program will spit output info file
file.
program <file-in >file-out - now
program will read input from file
file-in and spit it in
file-out.
program 2>/dev/null - now
program will not print output of stderr (2 is a file descriptor for stderr, remember?). It works because here we say that output from stderr should be written in file
/dev/null instead of our screen. But
/dev/null is a special file, that just throws out everything that you write in it (see
null(4)).
program1 |program2 - this is a pipe. It means that output from
program1 will be an input for
program2 (i.e. stdin for
program2 will be connected to stdout from
program1).
Well, to summarize, you don't actually need any sort of course. Really. I mean, I did want to have such too, but in fact I found that practice is _way_ more powerful and effective than that. The key is to be curious, to ask questions and try to find answers yourself (how does this command work, what part of the system is responsible for that, what's the internal machinery behind this system behaviour and so on...), to write scripts yourself (to implement programs that already exist yourself). The point is: you should be able to apply your knowledge somehow and this is much easier when you are curious and creative
This just gives you more opportunity to learn new things.
Now, I wrote a big thing and didn't probably give you what you wanted to get (i.e. a link or something). Instead of these, I would highly recommend you to watch
a documentary film about UNIX from 1982.
I was into WoW, started out with server emus on Windows XAMPP, switched to Linux, and kept expanding from there.
but with an interesting balance of security. Seeking performance always gives something to do 
