Black Screen! You opened some program out of curiosity (possibly named Terminal or Console or Shell or Prompt) and it greeted you with a black screen. With nothing but a blinking cursor.
This is followed by a feeling of helplessness that makes you think “What do I do with this now?”. You fumble with a few words but then eventually give up and close that window.
Fast forward to some call at work. Someone asks a question (that you understand). You see an engineer effortlessly open that black screen, confidently (and furiously) type away something into it and presses the ‘Enter’ key with a loud click that everyone in the call can hear.
A second later, to your amazement, some result comes back and the engineer reports the output in a human-understandable language to everyone on the call.
This brings back the painful memories of you fumbling with the black screen terminals, and you think “I am not that technical, you know?”. This slightly damages your self-confidence and yet you smile, outwardly 🙂
Well, if you think I am telling your story here, you are not alone. Many people are with you. Many people have the black-screen phobia.
In this blog post, we will discuss the black-screen phobia, its reasons and some tips to conquer it.
What are these black screens called?
These black screens are called using different names like console, terminal, prompt, shell, etc. However, the general name for them seems to be Command Line Interface, shortly CLI.
They are named so because the user interface is primarily command-based, where the user enters a command and the program responds with some response. Here, the user is expected to know the commands.
The opposite of CLI is a GUI (Graphical User Interface) where a user can use the program without memorizing commands, just by pointing and clicking using a mouse.
Why do people fear or hate the CLI?
- It feels like a test. It is like that person who keeps testing your memory power. Also, there is an implied expectation of you knowing the commands beforehand.
- It is boring. This is more of a reason for hating the CLI. No icons, no visual effects, just a boring dumb black screen.
- It feels like there are no safety nets. There is this fear of “What if I give a wrong command and it breaks something?”. Since CLI programs are powerful and yet don’t give any warnings (as much as the GUI programs do), we believe we might break something if we give a wrong command.
- It is associated with the image of ‘nerdy’ personalities. Any hacker in a movie uses black screens. So, people think they need to be a nerd to use the CLI.
What actually are these CLI programs?
You may have seen or heard at least one of the following. It is OK if you haven’t seen 🙂
- Windows Command Prompt
- Powershell
- Linux/Unix Shell (like Bash)
These CLI softwares are programs designed to run in the above command-line environments.
For example, AWS gives you a CLI based software called aws-cli. This is supposed to be used by typing the command aws in any of the above CLI environments. Of course, you need to install the AWS CLI in your computer before you can run it.
Some other applications that you can use from command line are:
- Git (we de-jargonized this term for our subscribers here)
- Node.js
- Java
Why we shouldn’t fear the CLI programs?
Reason #1 - Most of them are user-friendly
The CLI can feel like that quiz master who looks at you expectantly for your answer. In reality, almost 99% of these CLI programs are user-friendly 😀 Yes, they are user-friendly! Want more proof? Here it comes.
-
They come pre-packaged with a way to ask for help. In fact, most of these CLI programs have a startup message that tells you how to get help. This is how Powershell does it 👇
-
Most of the CLI programs have an option
--helpwhich gives you the necessary help to get started.
-
Some modern CLI programs even give you intelligent error messages like “You typed X but instead the correct command is Y” when you type something wrong.
Reason #2 - They have similar usage patterns
There are a lot of repeatable patterns. Often, once you learn some ways of using some CLI-based programs, you could intuitively use others also in the same way.
For example, you might use java --version to see which version of java you are on. The AWS CLI gives you similar syntax aws --version and even Node.js responds to node --version in the same way.
Reason #3 - They empower you to automate
CLI programs were not designed to torture their users. The primary purpose of a CLI program is automatability.
By providing a CLI option, these programs enable you to automate running that program from something else, like Jenkins or your scheduled jobs.
In principle, if you can run an application as a single command n a terminal, you can put that in your CI/CD pipeline or your scheduled jobs, etc.
Reason #4 - They allow you to quickly integrate different programs
CLI is boring if you have to run only one command. However, it gets interesting when you could integrate two totally different software by passing the output of one into another program using a single command.
This can serve as a quick proof-of-concept for complex integrations between two applications.
Combining two commands can be done by operator | in most CLIs.
Consider the following command that works in a Powershell or Unix CLI environment.
git status | more
The | symbol routes the output of the git status command to the input of more command. Don’t know what more is? Try typing more --help in the prompt 🙂
Reason #5 - All CLI commands have the same anatomy
Any command that you type on the CLI has the same parts. Once you recognize this, you can make sense of the command rather than panicking.
Any CLI command has the following parts.
Part 1 - What to invoke?
What program is invoked? Git? Java? AWS? This is ALWAYS the first word in the command. For example, when someone types git status, the first word is git. Hence, you know that they are invoking Git software. So, just look at the first word to get a context of what software they are calling from the command.
Part 2 - Inputs
Part 2 is nothing but any inputs to the program invoked in the part 1.
This can be of two types
- Non-flag inputs
- Flag inputs
Taking the same example of git status, the second-word status is an input to git that tells it what to do. In this case, we are looking for git to print the current status.
Now there can be any number of inputs to the same command. For example, when you type the git status --short command, it gives the current status in a short version, not a verbose one. Now, both status and --short are inputs to git.
Notice that --short is just a flag. If it exists in the command, the output will be short. Else it will be of normal size. Hence --short is a flag input.
There can be some non-flag inputs too, where you pass a string as input. For example, in the command cp abc.txt target/xyz.txt, the program to be called is cp - copy. There are two other inputs namely, the source file and the destination file. This command copies the file abc.txt into target/xyz.txt file. Note that there are no flags here.
Exercises
Once you understand the structure, you can try to guess (with some decent success rate) what any CLI command does. Let’s try guessing what these commands do.
mv abc.txt xyz.txtjava -jar myFile.jargit config user.email "abc@example.com"node -e 4+3 -p(Tip: Refer tonode --helpto understand this)
Conclusion
Black screen CLI programs may look scary but you can learn not to get scared by them. These CLI programs are an essential thing for automation and integration POCs. Once we understand that these are user-friendly (mostly) and that there is a anatomy of CLI commands, the fear of CLI can be greatly reduced with intentional practice and reading. That’s all for now 🙂
PS: If you found this article useful, chances are that you will find our events and exercises in Tech Coach Circle useful as well. You can consider becoming our ‘paid’ subscriber.
If you just want to get notified of our public blogs and events, you could fill and submit the form at the end of this page.
Hey 👋 liked the stuff here?
Subscribe to updates from Tech Coach Circle here.