answered as: What is a good tutorial to get the quick commands for a Linux beginner?

Please remember that Linux is just a modern UNIX implementation[1]. Go to the classic text, it will save you many hours of effort and make your life much easier!!! As, I explained in: How much knowledge of Linux is required to become a qualified user of the OS?

when you could do any of the exercises at the end of each chapter in Kernighan and Pike excellent text: “The UNIX Programming Environment” (a.k.a. UPE or ISBN-13: 978-0139376818) without having to look a great deal at the man page/documentation for every command you pretty much know which are which, why a user of the systems might use each.

Also, I highly recommend going through all the chapters. For instance, the chapter on ed(1), the original UNIX line editor may seem a bit trite in today’s world. But you will also learn how to use sed(1) and the power but seemingly strangely named grep(1) command (see Clem Cole's answer to Where did GREP come from?). It will also make learn vi(1)/vim(1) the ‘visual’ command that was added to ed years ago make sense and a great deal easier. I can also see the value in the chapter on document formatting, as it will teach the difference and value between a word processor (like MS-Word) and real “document compiler” such as UNIX’s troff family or systems like LaTex.

Without a doubt, UPE has taught more users how to use the UNIX family of operating systems than any other one. The book is accessible, easy to read and to the point. Basically, when you have completed the exercises, between your fingers and your brain, you should now know that you have the UNIX command system built-in to them. You might not remember 100% of the parameters for every command, and different UNIX implementations sometimes offer new/different switches. But if you can do the set of exercises in UPE, you understand how to use a pretty much any UNIX box there is.

If you don’t have a copy of same “stop, do not pass go”, and borrow / buy / download yourself a copy. As I have said elsewhere, the chances are good your college library has a copy. Plus it is still in print and you can buy it from most large “brick and mortar” here in the USA and Europe, much less online book stores or even download the PDF from Digital Library of Free & Borrowable Books, Movies, Music & Wayback Machine: UNIX Programming Environment: Brian W. Kernighan, Rob Pike: Free Download, Borrow, and Streaming: Internet Archive.

Good Luck.

[1] Again, as I have said in other answers I do not want to get into an argument. Linux is UNIX. It’s just the current reimplementation of it. Trying to say its something different is really not an interesting exercise. As I explained in Clem Cole's answer to What is the difference between Unix and Linux? It is a settled question and the US courts have ruled and have made it clear. The simple fact is that their ruling means that -> Linux is a modern (new) implementation of AT&T UNIX intellectual property.

Navigation :

cd changes directory

Reading:

ls lists what is in the current directory

cat prints the contents of a file to the screen

Writing:

touch creates a file with no contents named whatever you like

mkdir makes a directory

cp copies

rm removes or deletes

And the most important command for a newbie:

man as in manual. Type this before the command you want to know about . As in

man parted

If no man page comes up try --help or -h after the program name. Like

parted -h

In the Linux community we love a puzzle, but hate repeating ourselves. Man pages and Google exist to prevent that and if you ask a simple question do not be surprised to get rtfm as a reply. It means read the fucking manual. Man is a super important command as it will teach you how to figure your problem on your own. For easy access, and some cool tips and tricks there is an android app with tons of man pages called Linux Command Library . I highly recommend it.

Speed aside, the power is what you might call the 'metamagic’ of it (My own nonsense term). So there is this game that I played quite a bit back in the day called magika.

The whole schtick of this game that you could mix basic building block elements and depending on order, type and quantity of each element in your mix you could get a myriad of different spell effects —- sometimes disappointing, sometimes funny, sometimes amazing. In any case even the craziest of spells were built up from a few very basic elements like this.

This is what the Linux command line is. It is chock full of hundreds of one off programs. A simple example is cat which among other things can be used to display a file to console. Where the craziness starts is these programs can be piped and hooked together. Because they are atomic utilities that do something very basic very very well you can string them together and achieve incredibly incredibly powerful effects. You wanna rename a few hundred png files taken on March 22 in a folder of several thousand other images and then copy just those images into a new directory and zip them together? Thats some non trivial number of minutes monkeying around in a gui,.that's a single line and 30 seconds in the terminal. The reason is that because the utilities are atomic and can be strung together like this you are free to express operations practically any way you want.

A few things:

1. The UNIX command line utilities have existed almost unchanged for decades. A script you write will likely still work for quite some time.
2. Piping. You can pass the response from one utility to another which allows you to create some very powerful chains of commands that can get work done in super intricate ways.
3. It’s expressive. You can use && to only move to the next command if the previous command succeeds. || will only move to the next command if the previous failed. A combination of both is like an if/else statement. ; will continue whether or not it fails.
4. Portable. You can run those scripts on Mac and Linux. You can set up a bash profile with your custom commands and aliases and keep that same profile from system to system.
5. Versatile. You can do almost anything with a chain of commands. You can even tell it how to react when the application is exited in certain ways. The trap command can make it so the application exits differently when a user exits the application, or when it is forcibly killed.
6. Which brings me to exiting signals. You there are many different ways to kill an application. SIGINT is the signal you pass to the application by typing CTRL-C, sigkill is what happens when you exit via kill -9. Each have their own very predictable behaviours.
7. User input. You can have your script request user input and pause while it waits. In fact, you can even write a script that automates user input.
8. Exported variables. You can define variables that are scoped to just the current script or export them so that the variables exist in all scripts called by the script.
9. SH scripts. You can create files which are executable and can be run simply by typing their location (or just their name if they are in PATH).
10. Shebang. You can tell Linux what utility to use to run your script. Can run with bash or sh or even node or python if you specify it at the top of your script by starting with #!/utility/path.

The list goes on. Linux scripts have been a productivity godsend for me and I would highly recommend learning how to use them and taking advantage of the infinite possibilities and helpfulness they provide.

As we know, Linux operating system is a crucial part of this modern so being familiar with it commands and other mechanism is very much important.

To be a developer today, its necessary that one should be equipped with the commands as well as the syntax of the command. Since there are several commands in linux it is very much tedious to mug up those commands and use it. It is common that you may forget the commands.

Instead of bihearting the commands I used Gitux application available on Google Play Store. This application is very much useful as it contains all the commands which are used in modern linux environment so one can easily search every command. Once you know which command to search and use, the commands would be always remembered by you. Also this application has GitHub command which is used to push repository and open source projects.

Try this application, it may help you

Don't forget to upvote 👍

1. Thank you!

Link for Gitux application :

One simple reason: power.

There are hundreds, if not thousands of command line tools to do just about anything you want. More, you can string them together like building blocks to do even more tasks. You can build short scripts to do the exact things you need.

Which is better?

1. open internet explorer
2. find your bookmark for the site you want
3. navigate to the download page
4. download the document
5. open Word
6. navigate to the download directory
7. find the file you just downloaded
8. open the file

or

1. wet http://my.site.com/downloads/mydocument.doc; libreoffice mydocument.doc

better still wrap that in a shell script and just do

1. opendoc

Great question. I wish I had a great answer.

I learned from the book “The Bourne Shell.” It ran ~120 pages IIRC and did a good job. I looked at two of the books recommended in other answers and was a bit dismayed to see they each had many more pages. On reflection, though, the “Bourne-again shell” does have many more features and the recommended books were comprehensive.

One of the answers noted that one needs to understand Linux before many shell features are meaningful: the file system, users and groups, read/write/execute permissions, process control, signals, and so forth. Trying to explain them in a bash book is a reach… and there’s the rub: if you know those things, there are too many pages in the bash books; if you don’t, there aren’t enough pages.

In short: look for the PDFs on the topic. I quickly found a few of them and didn’t see too many errors.

First of all Bash and Linux are two separate things.

Linux is a Unix-like, open-source operating system that was made by Linus Torvalds. Opensource means it’s completely free for the most part with a few exceptions like Red hat Linux.

Bash is an interactive shell for the terminal which provides users a way to interact with the terminal. Not only that Bash is also used as a scripting language to automate stuff.

Here is how to check if you are running bash your default shell:

echo $SHELL 

The $SHELL is an environment variable.

Determine something that you currently do repeatedly (that is simple and requires a few steps) and automate it using bash. “Forcing” yourself to learn something is really just another way of saying that you want to find creative ways to put fun or rewarding learning challenges in front of you.

Bash runs pretty much everywhere these days. It’s available on multiple operating systems, so you don’t need to install a full-blown operating system (like a Linux-based one) on a dedicated computer to run it. You don’t even need to run a virtual machine (like VMWare), nor do you need to even run Cygwin (which can emulate a bash shell). You can use Bash on windows now, in it’s native form, by using The Windows Subsystem for Linux. Definitely check that out if you use Windows.

If you’re already using an operating system where it’s the default, like Linux or macOs, and just want to force yourself more into the command line, the best way is really just to create something.

Bash isn’t just an interface to the operating system, it’s a fairly rich language that’s super easy to use for basic things (and far more difficult for not-so-easy things, but powerful), and that’s why I recommend starting by automating something you currently do today. Like any language, it takes hands-on practice. You probably know that since that’s why you want to force yourself to use it.

This brings me to really the first question I would ask anyone wanting to learn bash: Why? That purpose should feed your desire, since generally speaking, you just need to automate things.

You’ll want to reinforce what you learn as you go. I would put a quick reference near you (sticky note, text file, notepad) so that you can more easily develop the basic vocabulary to build on (i.e. an index of basic commands, tips/tricks that you find helpful). You can start with some of these:

ls

pwd

clear

mkdir

touch

mv

rm

Then, build up this list from there. There are infinite places to reference the meaning of unix/linux/bash commands. Anything you want to do, there are at least ten ways to do it. Just pick something and try it out.

I also highly recommend “forcing” yourself to use vi. ‘vi’ is an extremely powerful text editor and exists ‘everywhere’, even where bash doesn’t. It has a steep learning curve initially, because it’s very abstract, esoteric, and you learn it by rote, but it’s extremely efficient so that you can keep your fingers on your keyboard without having to use your mouse just to edit simple text.

I hope this was helpful!

Remove all or most of your GUI, if possible. For example, (under Linux) boot into the shell or use a minimal window manager such as i3wm. Use a multi-pane terminal emulator, like iTerm under macOS or Tilix under Linux. Keep several panes open at all times, and dedicate each to a specific type of use. If you are a programmer, you could run a dev server in one pane, use git/grep/find in another, and run Vim in a third.

Think, and solve problems, in terms of text; this in large part is what the shell does.

Define some simple workflows and begin shell scripting. Even starting with modest scripts may impress you with the shell’s power, possibly increasing your appetite.

Make it a game; the shell can be a lot of geeky fun. However if you don’t come to enjoy it in a reasonable period of time, be kind to yourself and don’t “force” it. There are other ways to work effectively without torturing yourself.

Say you want to save only a certain part of the output of a log file and not the whole thing and set a variable to use in your program. You would then ‘pipe’ through a ‘filter’ so to speak. It saves on creating a temporary file that you want to get rid of later. This next example uses ‘\’ at the end of a line to make it easier to read long lines. It sets a variable ‘IDS’ after extracting information from a web site using lynx, a text based web browser.

IDS=`lynx -accept_all_cookies -dump $SITE\

?s1=0\&t2=\&c1=$CHART\&p1=\&p2=\&p3=\&p4=\&p5=\&p6=\&p7=\&p8=\&s2=0\&L1=0\&t4=\&t7=\&t8=0\&t5=\&t6=\&m1=100\&submit=Search \

|gawk -F= 'BEGIN{OFS="="}/http:/&&$NF==$NF/1{print $NF}'|sort|uniq`

We had started to transition in Windows machines to replace our UNIX machines but the programs we used had the same names but with .exe at the end. Using Cygwin as a UNIX environment within Windows, the users could run the same scripts but based on different locations from UNIX. Cygwin Bash is the same as Linux Bash. I only had to make slight alterations to the scripts to make them work in both platforms.

test ! -z $CSSCRIPTS && . $CSSCRIPTS/scripts.ARCH || . $CSLOCAL/scripts/scripts.ARCH

Cygwin has slightly different program operations from other UNIXes because of the Gnu source files so a one-liner can be used to make a slight change using && if yes and || if no :

ARCH=`uname`; test "$ARCH" = "OSF1" && ECHO="echo " || ECHO="/bin/echo -e "

Lots of other examples can be done to save a lot of fiddling with numerous temporary files.

Hope this helps.

PC

The answers here are all asserting that they are the same and while that’s true at the first level, one should be aware of some caveats.

First, it’s important to understand that “source” is an alias for “.” that is provided on some shells, but not all. POSIX compliant shells must provide the “.” command, but may or may not provide the “source” alias.

Conversely, there are some non-POSIX shells, such as csh that provide “source” but not “.”.

Further, one should be careful to remember that not all “.” have the same meaning.

A “.” by itself, followed by whitespace, invokes the next token (assumed to be a path to a shell source file) in the current shell. The “source” command is an alias for this and none of the following.

A “.” followed by “/” invokes the next token in a separate shell (Example: ./foo.sh) IF it is an executable. This does NOT work for “source” ( Example: source/foo.sh will not work).

A “.” followed immediately by “./” works as “./”, but starting in the parent directory (Example “../foo.sh”). Again, this does NOT work for “source”.

Finally, when the token supplied (after a space) to either “.” or “source” begins with “./” (or “../”), that is treated as the current directory (or parent directory) in a path to a shell source file.

Important: Both “.” and “source” (followed by whitespace) expect the next token to be a path and will then interpret it’s token as source within the current shell. This does NOT require the source file to be executable.

Conversely, “./foo” requires that ‘foo’ be an executable and it may or may not even be a shell source file.

So:

. foo interprets the contents of foo within the current shell.

. ./foo interprets the contents of foo within the current shell (note the space between the dots).

. ../foo interprets the contents of foo (relative to the parent directory) within the current shell (note the space between the first two dots).

source foo interprets the contents of foo within the current shell.

source ./foo interprets the contents of foo within the current shell.

source ../foo interprets the contents of foo (relative to the parent directory) within the current shell.

./foo executes foo in a new shell. REQUIRES foo to be executable.

../foo executes foo (relative to the parent directory) in a new shell (note lack of space between the dots). REQUIRES foo to be executable .

Because of the potential for confusion between “. ./foo” and “../foo”, I tend to prefer using “source” in scripts for clarity.

It’s not essential but, boy, will it save you a lot of time. Luckily you don’t have to learn much shell scripting to get most of the advantage, but learning some is absolutely worth doing.

Being a developer means using a lot of tools that are designed with the shell in mind. Many tools—even those that come with UIs—are best managed from the command line: compilers, build systems, preprocessors, web servers, databases… Moreover, as you get deeper into development, you’ll want to carefully manage your own system and install packages and development libraries, all of which is, again, easier from the command line.

On top of this, chances are you’ll want to do certain operations on large numbers of files or on a schedule. These are often things you could do manually, but why would you want to? Spending time tediously moving files around is not great, especially when a bit of shell scripting would automate the whole thing without much effort.

Spending time up front to learn something that will save you time and effort in the long run is one of the most important skills I’ve seen for helping people succeed and excel as programmers. You shouldn’t look at shell scripting and think of it as an obstacle forced on you or a rite of passage. Instead, you should look at all the work you’d have to do without knowing a bit of shell, recoil in disgust and pick up just enough shell knowledge to avoid it. You’ll be more productive for it and, as a general rule, I’ve found these things pay off faster than you’d expect— a matter of weeks, not years.

At the same time, don’t just sit down with a Bash book and try learning the whole language. It’s old, big, arcane and you won’t use most of it. Instead, learn command line basics from a tutorial (sorry, I don’t know one to recommend) and only learn more as you need it. When you come across something that you should be able to automate but can’t, learn just enough on top of what you know to do that task. You’ll be surprised how far you get without diving into Bash conditionals or loops—and when you do, you’ll be surprised at just how ugly they are. (Hey, nobody said Bash was a great language—but it works at the command line and it gets the job done.)

There is nothing like best Unix tutorial but First tell us, what kind of domain in Unix.

I am considering that you want to start with Linux/Unix, especially using Terminal aka console or command line in Linux/Unix.

There are lots of blogs on Google and Red Hat documents or Ubuntu or Linux documents.

So, just think what you want to learn and then search for it on google and learn it from lots of blogs and practice them in virtual machines.

Or, you can also download some books in like,

• Guide to the Red Hat Exams-RHCSA.RHCE.Cert.Guide.and.Lab
• Linux Bible (This, book is lengthy one)
• Other lots of Red Hat exams practical books
• Red Hat System Administrator guide, Linux fun, etc.

Google blogs and websites like

• nixCraft - Linux Tips, Hacks, Tutorials, And Ideas In Blog (nixCraft - Linux Tips, Hacks, Tutorials, And Ideas In Blog)
• The Geek Stuff* (The Geek Stuff)
• LinOxide - Linux / Opensource HowTos And Tutorials (LinOxide - Linux / Opensource HowTos And Tutorials)
• Tecmint: Linux Howtos, Tutorials & Guides (Tecmint: Linux Howtos, Tutorials & Guides)
• Home | Unixmen (Home | Unixmen)
• Xmodulo - Linux FAQs, tips, and tutorials (Xmodulo - Linux FAQs, tips and tutorials)

And, lots of others like Stack Exchange (Hot Questions - Stack Exchange), have a look at the full stack of websites those are related to Linux and Unix.

Note:

• I love Red Hat based distro, that’s why my answer is more focused on Red Hat documentation and books.
• You can learn anyone and believe me at the end you will know how to operate and configure any Linux/Unix operating system.
• Unix and Linux, both are different families. Like, {BSDs and Fedora/Debian/Arch/Gentoo etc.}

A mixture of theoretical and practical work.

There will be any number of “Beginners Guide to Linux/Bash” articles and books out there. A lot of them will include practical exercises as well for re-enforcement of the stuff you’ve just read about.

Read enough to get to a point where you can install a Linux Distro on a Virtual Machine (VirtualBox would see you right, here); most of the reading material that includes practical exercises will almost certainly have you install Linux as Chapter 1, anyway.

Then do stuff, run the commands that are mentioned in the reading material and exercises; try stuff out, try the “what if I do that instead” things you think of, just to see what happens. This is the advantage of a Virtual Machine, if you trash it, you simply recreate it, perhaps from a judiciously taken initial snapshot or clone, or by starting from scratch again.. practise makes perfect, right?

Task 1 - figure out something you want to do that isn’t too complicated.

Say … grab a key from the keyboard, and for “1” do something, “2” do something else. Like a menu. After finishing the task of the menu, go back and ask for another key. Don’t forget error checking … key not in menu.

And … if you enter “1x”, the “1” can be processed, but “x” is an error. Do you want “12” to do 1 and then 2?

This uses the “read” and various variable editing/changing/selection techniques.

Task 2 - something that executes programs, ‘waits’ for them to complete, and comes back for another. I’m thinking reading arguments for the command, and using variables to grab the arguments, check for quoting (single/double) correct, and not have funny things happen when any of the the following characters are entered:

• < > <<< >>> & { } ( ) [ ] | $ ‘ “ ` ;

and any other special characters that the shell executes/processes itself.

There, while, and maybe for commands, shell weirdness with quotes and special characters.

Task 3 - something that you want to do in a shell script.

Task 4 - alias and functions.

unalias bc 2>>/dev/null >>/dev/null 
bc() 
{ 
  if [ `hostname` = 'm.xiocorp.dom' ] ; then 
    eval /usr/bin/bc -l ~${USER}/bin/bc.default; 
  else 
    eval /usr/bin/bc -l -q ~${USER}/bin/bc.default; 
  fi 
} 

and file bin/bc.default looks like:

scale=5 

As you are changing the function, use “declare -f bc” to see it, and make sure it hasn’t changed due to some shell processing characters. [Hint here for the major time spending debugging bash scripts.]

Task 5 - functions with arguments, combined with arguments to the script.

By this time, you are ready for real tasks!

Ready for next level bash/shell programming? Check the package/command “shellcheck”. Example from a script that I have:

> cat 01.rhel.check.kdump 
#!/bin/bash -e 
echo '-----------------------------------------------------------------------------' 
echo 'Does kernel boot line have crashkernel= parameter set?' 
grep crashkernel /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg || true 
echo '-----------------------------------------------------------------------------' 
echo -n 'crash dumps put: ' 
grep '^path ' /etc/kdump.conf 
echo -n 'core_collector set: ' 
grep '^core_collector ' /etc/kdump.conf 
echo '-----------------------------------------------------------------------------' 
service kdump status 
echo '-----------------------------------------------------------------------------' 
cat /proc/cmdline | grep crashkernel 
echo '-----------------------------------------------------------------------------' 
echo '/var/crash:' 
ls -l /var/crash 
echo '-----------------------------------------------------------------------------' 
exit 0 

Running shellcheck gives:

> shellcheck 01.rhel.check.kdump 
 
In 01.rhel.check.kdump line 13: 
cat /proc/cmdline | grep crashkernel 
    ^-----------^ SC2002 (style): Useless cat. Consider 'cmd < file | ..' or 'cmd file | ..' instead. 
 
For more information: 

https://www.shellcheck.net/wiki/SC2002 -- Useless cat. Consider 'cmd < file...

So, why did I use cat instead of grep? The reading of lines from stdin of grep does not behave the same way as the program cat does. “It doesn’t work.” Yeah, /proc is a strange file system … I like to think of it as an emulation of a file system. :)

A lot depends on your mind-set going in.

Nearly everyone approaching Linux for the first time will have cut their teeth on computing using Windows, although some may have been using Mac OS X/macOS all along. Older people might remember the classic Mac OS, DOS and DOS-based Windows, or even older operating systems like CP/M. I’m almost 46 and have used all of them in my lifetime.

But for the vast majority of people, it’s going to be Windows. And Windows is designed to be super-easy, and it’s gotten even easier as the years have gone along. Microsoft has tried to make Windows 10 so simple that anyone can use it, and basically everything as far as updating is automated—you just sit down and use the machine.

Linux isn’t designed this way. Even in very user-friendly distros such as Ubuntu, Mint, Manjaro, Zorin, and others, there are times when you need to tell Linux what to do, and there are also times when the best, or maybe only, way to do something is to drop back to a command line and type Unix commands into it. This sort of thing has been very rare in Windows for the last 15 years—basically, ever since everyone moved off Windows 98 and onto XP. Win 98 was the last popular DOS-based Windows, where you could open a real MS-DOS prompt inside of Windows and issue DOS commands.

Truthfully, you rarely have to do this in modern Linux, and even after three-plus years using it every day, I don’t know all of the commands, because I haven’t needed them. When I do use it, it’s usually to get a program I want without having to start Synaptic or Mint’s built in software manager. When I needed to burn a DVD last week (first time in about a year), I knew Brasero was what I needed, but it’s not installed by default in the Mint 19 package. So I just opened the command line and typed in “sudo apt-get install brasero”, and then my root password, and it installed Brasero for me.

There are things like that you have to learn, but it’s no harder than picking up Windows for the first time. I had used Linux off and on for a long time before I committed to making it my primary OS in October of 2015, and it didn’t take me two weeks before I stopped missing Windows. Currently, I don’t even have Windows installed on my desktop, and I’m not sure if I will even put it back on there except as a VM. Kay is still on Windows, but doesn’t really like Windows 10, and I’ll probably convert her machine to Linux (with her blessing) sometime this year.

I learned UNIX in one summer, 3 decades ago, and I'll share how I did that.

I treated the shell, all the programs it could run, directories-and-files-and-permissions, and environment-and-shell-variables much like a text-based adventure game.

The "map" in my pocket was the man pages, and the "apropos" program let me search the map.

I explored. Constantly. I made up scenarios, creating test files that I worked with using the various programs, to see what they did with the files, and what they output, and how they worked. To the tune of hundreds of tests or experiments or investigations per day. Soon I was stacking them together, and learning what worked and what didn't work for "pipelines", "scripts", "daemons", "background processes", etc.

I treated Vi like its own little video game, learning the various settings it has, how to use it effectively, and how to get myself out of trouble if I happened to get into trouble. (i.e. if I mangled the content in the editor, how to quit without saving) - and similarly learned the Emacs editor.

I slowly sussed out that there were different kinds of "regular expressions" and what they were: file globbing, basic regexs, and extended regexs are what the three categories are called today.

I treated awk like the insanely awesome power-tool that it is, learning about associative arrays and how awk's pattern scanning can make complex tasks easy. That gave me the foundation I needed - I didn't have the insights to write this way back then, but I knew awk could do stuff like this: Log-dissector by PaulReiber

I treated sed like a power-tool as well, learning how to use it to edit files "from the commandline" - a very powerful mechanism when used carefully.

I undertook to learn as much as I could, as fast as I could, about UNIX. If you undertake this with as much enthusiasm as you can possibly muster, and treat the entire endeavor like a wonderful game where you're finding hidden treasures, "bonuses", and prizes, you'll soon find you've fallen in love with that quirky thing called Linux, and that you've become "adept" with using it.

If you'd like to learn the details of some of the more complex commandlines which I've either built from scratch or adapted from someone else's efforts over the years, give this a read: Awk is Cool

Explore GNU, and specifically GNU coreutils. GNU Coreutils documentation will keep you learning and exploring for weeks if not longer. It's available in a number of forms: GNU coreutils - Core GNU utilities

BONUS: If you've made it this far, congratulations! Reading to the end of answers has benefits. Here's the benefit in this case - a "goto" site with curated content about anything and everything Linux-related: https://linux.zeef.com

You have several options —

• create a script that runs, in any script language available
• create functions that load into the main bash shell and run like a program
• write a program in a compiled language that interacts with bash input and output modes.

The first is fairly simple. A bash script in its own file, when you invoke it on the command line it does its thing. You can process input and get output as you like using the bash script arguments that are entered on the command line. You may do almost anything that a regular programming language does, but are limited to the bash syntax and data storage limitations. For instance, bash does only arithmetic and only on integers. To do floating point math, you need another language, another program.

Bash has limited functions that are packets of bash commands that are given a name. They are not given local scope by default, and you can leverage that. You can specify variables as local only if you want to. The output of a function is a string, always, but that string can be an integer string that you can use by evaluating it.

You may make a file of bash functions and use is as a library of functions. You may use the source command within a bash script to load those functions into the current bash shell environment, or use it from the command line to load them into the base shell environment, (if you use bash as your shell).

After that the constants, variables, and functions are available. But be careful as they are easily overriden and sourcing them twice might have consequences that make them not work like you thought.

Bash is designed to run other programs, and manage processes in a simple way. Any program run from the shell can take input from the keyboard and output to the shell’s input buffer, as long as you know how to do that in the language.

A key concept is the security aspect of bash and its scripts. A script run from the command line gets a complete copy of the shell variables, and launches in an new process. Those variables can be changed, and new ones created, but they all go away when the script ends, and cannot escape, that is why it is called a “shell”. So whatever you set up environment-wise and as functions, etc. disappears when the script ends.
So what is done is to put these things in .bashrc and .bash_profile for each user, and bash loads these things up when a new shell (terminal) is launched, so you have them ready immediately.

A fourth option is to create an alias for a set of bash commands — and that alias is substituted for its code when you call it. For instance the command to take a screenshot is

scrot -c -d 5 -q 100 
  
scrot   -- the program that takes the screenshot 
-c      --  option   display a countdown 
-d n    --  option   delay for (n=5) seconds 
-q 100  --  option   use quality=100 (full pixels, lossless) 

This is fine but you can “standardize” it with an alias

alias sshot='scrot -c -d 5 -q 100' 

and then just type sshot and it is the same thing as if you typed the whole thing.

A bash “wrapper” for intelligent use of other programs makes things much smoother.

For instance I have much occasion to use the MSWindow program mp3tag.exe to work on audio files metatdata to get them filled in. This being a windows program, I need to use wine64 with the proper flags to launch it, and I need to translate linux file paths into windows equivalents, etc.

So I wrap the commands (rather overbuilt, but ok) in a bash script, then make the script executable and put it my $HOME/bin folder.

#!/bin/bash 
 
DEBUG= 
WINE=$(which wine) 
MP3TAG="C:\Program Files\mp3tag\mp3tag.exe" 
MP3TAG_FILE="/home/chris/.wine/drive_c/Program Files/Mp3tag/Mp3tag.exe" 
 
# checks 
[[ ! $WINE ]] &&  echo "ERROR Can't locate wine" >&2 && exit 
[[ ! $MP3TAG_FILE ]] &&  echo "ERROR Can't locate mp3tag binary" >&2 && exit 
 
# paths 
RD=$(realpath "${PWD}" ) 
[[ $DEBUG ]] && echo "real dir path: %s\n" "${RD}" >&2 
 
WP=$(winepath -w "${RD}") 
[[ $DEBUG ]] && echo "wine path ${WP}" >&2 
 
# main driver 
main () 
{ 
 
    if [ $# -eq 0 ] || [ -z "${1}" ] ; then         
        ${WINE}  "${MP3TAG}"  "/fp:${WP}" 2>&1 
 
    elif [ -d "${1}" ] ; then 
        ${WINE} "${MP3TAG}" "/fp:${WP}" 2>&1 
 
    elif [ -f "${1}" ] ; then 
        ${WINE}  "${MP3TAG}" "${WP}\\${1}" 2>&1 
 
    else 
        echo "Can't find file or dir ${1}" >&2 
        [[ $DEBUG ]] && echo "\$1 = ${1}"  >&2 
    fi 
} # main 
 
#call main with command a line arg  
main "${1}"   
 
# end 

Some conventions I “invented” (probably read somewhere)

[[ $DEBUG ]] && echo "real dir path: %s\n" "${RD}" >&2 

If DEBUG is defined for the script do the rest, other wise skip the line.
>&2 sends output to standard error instead of stdout. This keeps any other program that reads stdin from getting the debug input

main "${1}" 

I use the ${X} convention instead of just $X because I want to see visually that I am using a variable defined previously, and it prevents mistakes of forgetting the $ sometimes on a bare word.

By putting the functions in the main function and calling it at the end with args, you are ensured that any destructive commands that may have typos will not execute, until the entire script is read. Typos get caught before anything else happens.

File checks are optional, but I put them in because if I copy the script to another machine, and it does not have all the requirements, I want it to fail and tell me before anything else, or I wonder why it doesn’t work. This has saved me a lot of time in the past.

1. Bash Guide for Beginners

This book contains a total of 12 chapters spread over 165 pages. This book is written by Machtelt Garrels. This book is must for anyone working on UNIX and like environment. If you are a System Administrator and want to make your life easier this resource is for you. If you are experienced Linux User, this book aims at giving you an insight of the System. The documents are very encouraging and it will help you writing your own scripts. Detailed and wide list of topics covered in easy to understand language is another plus point of this guide.

Download – Bash Guide for Beginners

2. Advanced Bash-Scripting Guide

This book contains 38 chapters and spread over 901 pages. Having detailed description of everything you may need to learn yet in language that is easy to understand. This book is written by Mendel Cooper and it contains plenty of practical examples. The tutorial in the book assumes that you don’t have any previous knowledge of scripting and Programming but progress rapidly to intermediate and advanced level of Instruction. The detailed description in the book makes it a self study guide.

Download – Advanced Bash-Scripting Guide

3. Shell Scripting: Expert Recipes for Linux

This book is written by Steve Parker. Though you can not download this book completely for free, the first 40 pages are free. It is sufficient to know what the book contains. Personally I am an admirer of Steve for this wonderful piece of guide. His skills and writing style is awesome. Plenty of practical examples, easy to understand theory and his style of presenting adds to the list. The original book is voluminous. You may download the 40 page guide to learn and see if you are going to get around scripting.

Download – Shell Scripting: Expert Recipes for Linux

4. Linux Shell Scripting Cookbook, Second Edition

This book contains a total of 9 chapters spread over 40 pages. This book is written by Shantanu Tusharwho is a GNU/Linux user since his early days. This guide contains a balanced combination of theory and practical. I don’t want you to loose your interest for this 40 page guide which may be life Saviour for you. Download and see how this is useful for you.

Download – Linux Shell Scripting Cookbook, Second Edition

source : Tecmint: Linux Howtos, Tutorials & Guides

Learning BASH can give you an excellent understanding of programming ‘flow’ - What processes should come before other processes - as well as finding commands, learning commands, understanding commands, and using them interactively with each other and when needed, interactively with the user.

Remember that ‘man <command>’ is your best friend in BASH.

man curl

can tell you if curl is installed, what curl can do and how to use it.

compgen -b

will show you all the BASH builtin commands

compgen -c

will show you every command on your system including program names

I’ll teach you one caveat; Never - Not ever - Under no conditions - Not even on a dare - type in any command you’re shown or told until you’ve researched it to make sure you understand EXACTLY what it does. A smart arse could tell you to type something in that could destroy all or part of your system. Don’t type an unfamiliar command in even if you THINK you know what it does.

Now, for a homework assignment, open a terminal and type in ‘man compgen’ and explain why you see this result; ‘No manual entry for compgen’. compgen is a builtin BASH command after all.

Don’t be afraid to learn my friend, but always strive to understand as well. Wait … aren’t they the same thing? Usually, but not always! Understand?

The best advice I can give is you should learn where to look for information when you get stuck. Nobody knows by heart all the commands, options, and other intricacies.

Let’s say you want to unzip a file via command line but have no clue how to do it.

1. Pick up the habit of reading through the manual pages. They are the best/ultimate source you got. Eg: man unzip
2. Use --help flag to know more about the command and it’s options. unnzip --help sudipbhandari@sysadm-Latitude-5480

UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Usage: unzip [-Z] [-opts[modifiers]] file[.zip] [list] [-x xlist] [-d exdir]

Default action is to extract files in list, except those in xlist, to exdir;

file[.zip] may be a wildcard. -Z => ZipInfo mode ("unzip -Z" for usage).

-p extract files to pipe, no messages -l list files (short format)

-f freshen existing files, create none -t test compressed archive data

-u update files, create if necessary -z display archive comment only

-v list verbosely/show version info -T timestamp archive to latest

-x exclude files that follow (in xlist) -d extract files into exdir

3. If you don’t know what the command would be, try searching man pages for keyword (man -k) or apropos

man -k unzip                                                                                              sudipbhandari@sysadm-Latitude-5480 
bunzip2 (1)          - a block-sorting file compressor, v1.0.6 
funzip (1)           - filter for extracting from a ZIP archive in a pipe 
gunzip (1)           - compress or expand files 
lz (1)               - gunzips and shows a listing of a gzip'd tar'd archive 
PerlIO::gzip (3pm)   - Perl extension to provide a PerlIO layer to gzip/gunzip 
preunzip (1)         - prefix delta compressor for Aspell 
unzip (1)            - list, test and extract compressed files in a ZIP archive 
unzipsfx (1)         - self-extracting stub for prepending to ZIP archives 
uz (1)               - gunzips and extracts a gzip'd tar'd archive 
------------------------------------------------------------ 
~/.ssh » apropos unzip                                                                                             sudipbhandari@sysadm-Latitude-5480 
bunzip2 (1)          - a block-sorting file compressor, v1.0.6 
funzip (1)           - filter for extracting from a ZIP archive in a pipe 
gunzip (1)           - compress or expand files 
lz (1)               - gunzips and shows a listing of a gzip'd tar'd archive 
PerlIO::gzip (3pm)   - Perl extension to provide a PerlIO layer to gzip/gunzip 
preunzip (1)         - prefix delta compressor for Aspell 
unzip (1)            - list, test and extract compressed files in a ZIP archive 
unzipsfx (1)         - self-extracting stub for prepending to ZIP archives 
uz (1)               - gunzips and extracts a gzip'd tar'd archive