12 Command Line Mistakes New Developers Make (and how to fix them)

Here’s 12 Command Line mistakes that all new developers will make from time to time and how to fix them.

1. Opening a new port rather than killing an old process #

So this first one is something we’ve all probably encountered before.

You’re trying to start up your API or App code and you get a message saying that the port is already in use and whether you want to use a new port number.

But ideally you don’t really want to use a new port as you might have some other local code, like an app or API that’s relying on using that existing port.

If you can find the command prompt where the existing app is running then you can just stop it with CTRL-C or whatever your shell’s keyboard shortcut is and the port should be released.

However, sometimes you might have so many prompts open that you can’t find the window to shut the existing app down or you can get a rogue process with the app still running which holds on to the port number.

In this scenario you have no way to close down the app to release the port so you end up just using the new port offered to you and have to reconfigure an other services that were already setup.

But here’s a way that you can find that elusive running process and close it down it to release the port.

First of all, use the list open files command to find the process that is using the port.

sudo lsof -i :4200

This will give you some output that looks like this:


COMMAND   PID  USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
node    14355 james   44u  IPv6 0xa50818e7ef9a7895      0t0  TCP localhost:4200 (LISTEN)

Then you can just kill that process that’s using it’s PID to release the port.

kill -9 14355

Or if you want to look like a total badass command line ninja, you can get just the PID number from the result of the lsof command and use it directly with the kill command.

kill -9 $(lsof -t -i :3000)

Now we should find we can start our app with our preferred port number!

I don’t want Windows users to feel left out here and there is indeed a similar set of commands that you can use on the regular command prompt in Windows to do the same thing.

On your Windows machine, pull up your command prompt and use the netstat command piped into the findstr command to get the process id.

netstat -aon | findstr 4200

Then it’s just a case of killing the process as we did before.

taskkill /f /pid 1234

You can see there are various different options that we’re passing to these commands and it’s important to know how to find out what these are and what they are all mean.

## 2. Not making the most of man pages

OK so it’s pretty easy nowadays to look stuff up on the Internet but it’s so much quicker to use some of the built in help that’s right there in front of you if you know how to get to it and look at it properly.

For example, let’s take a look at the scp command which is used for transferring files to a remote machine securely.

If you just type the command in the command prompt, it will give you some usage info but as you can see it’s not very helpful - what do all those options mean?

So we can use the manpages tool to get more info about how the scp command works.

man scp

But there’s an even better way to find exactly what you’re looking for.

You can combine the output of manpages with search tools like grep to only return the specific things you’re interested in.

For example if we wanted to know how to recursively copy directories with scp, we can use grep to find the option which lets us do this.

man scp | grep Recursive
-r      Recursively copy entire directories.  Note that scp follows

Pro tip: use the -i option when using grep to make your searches case insensitive to help you avoid missing things that otherwise might not have been picked up.

man scp | grep -i recursive
-r      Recursively copy entire directories.  Note that scp follows

The takeaway here is that you have lots of information right in front of you and you don’t need to always head to Google to look things up.

Of course, manpages doesn’t work on the Windows command line - it just doesn’t have the built in help like other command prompts do so it’s important to be aware of which environment you’re working in and what capabilities it has.

3. Not knowing which command prompt is being used #

So it might seem pretty obvious which command prompt you are using or should be using depending on your Operating System.

If you’re using Windows you’re using command prompt (or Powershell).

If you’re using MacOS or Linux you’re using bash (or zsh, or fish, or dash, or one of these!).

But for new developers, where the command line is still a bit scary, using a command not supported by the prompt you are in and getting an error can be confusing and frustrating.

Bear in mind too that the prompt you are using can change based on what you’re doing like if you’ve connected to a remote server or you are using the Git bash prompt, Ubuntu subsystem on Windows for example.

So to clear up which command prompt you are actually using you can run the following command.

echo $0

This will give you the current shell that you are using and help you diagnose why your previous command didn’t work.

Talking of previous commands, this leads us onto the next mistake new developers make.

4. Not using reverse-i-search #

You should be able to go through the history of your commands that you have previously entered in your command prompt by using the Up/Down arrow keys.

But if you’re looking for a command that you used a while ago then this may take a long time and you need to keep an eye on each command that’s popping up checking each one in turn.

A better approach to this is to use the reverse-i-search tool by using CTRL-R and then searching for the command that you’re looking for.

If you can’t remember exactly what the command was, no problem, just partially type something in and then hit CTRL-R again and you can cycle through any matches until you find what you’re looking for.

Let’s move on and look at using a few different common commands and some things that new developers need to be aware of.

5. Manually looking for large or new files #

You’re probably familar with the ls command to list files in a directory but sometimes you might want to find out which files are taking up the most disk space in your project.

Not too much of a problem if there are only a handful of files in the directory we can just eyeball it but what about if there are hundreds or thousands of files?

Instead of manually searching through the list of files to pick out the large files we can add some options to ls to do this for us.

ls -lhS

The l option is for a long listing, h for ‘human readable’ output (to show things in KB/MB/GB etc) and the captial S option is for sorting by size order.

So now we can see the largest files at the top of the listing output.

We can also reverse this output to find the smallest files first if we want to.

ls -lhSr

We can do the same thing for the most recently modified files by using the t option to sort by the time the file or directory was last updated.

ls -lht`

6. rm -rf Something you didn’t want to #

From experience I know this is something that is a very painful lesson to learn - you basically remove a file or even worse a whole directory of work using the rm command.

The good news is, if you find yourself in this situation, I can save you a lot of time trying to find a solution.

And the solution is, don’t bother wasting your time, because there is no solution.

Once you’ve removed your files with rm or rm -rf then that’s it they’re gone!

So you need to be really careful when using this command and make sure you’re running it in the right place.

You can set an alias up so that the rm command is always run with the interactive option so you have to confirm you are deleting the files you want.

alias rm='rm -i'

But of course that requires setting up in advance and is no good to you if you’ve already done the damage.

This being said, there might be a couple of chances for developers to reclaim your files.

The first is dependant on your IDE which may or may not provide a way for you to restore files from it’s history if you’ve removed them from the command line.

Example

The second is to restore your files from your changes in your Git repository on the assumption that you’ve already commited them.

This should be a case of unstaging the deleted files by checking out the recent changes from your local repository.

This is why it’s definitely a good idea to be using Git with your code and to also make sure you’re committing your files properly.

7. Not configuring Git correctly #

So this is more of a Git problem than a specific command line issue but lots of new developers don’t set up their local Git profile and respository settings in the correct way.

The first thing to make sure you have set is your name and email.

git config --global user.name "<username>"
git config --global user.email "<email>"

And then the next important thing to do is make sure you have ignored things that shouldn’t be committed.

For example you can easily ignore node_modules in your app code by redirecting the output of echo into your .gitignore file.

echo node_modules > .gitignore

Here are some other things you might consider adding to your .gitignore file:

.DS_STORE

If you’re going to use the output redirection operator, make sure you haven’t already got something in your .gitignore as this will overwrite what’s already in there.

8. Knowing the difference between » and > #

Mistake number 8 is a simple one but it’s important to know the difference between the output redirection operators - the single and double greater than symbols on the command line.

One greater-than operator redirects the output of the command on the left-hand side to the file on the right and completely removes anything else in the file whereas the double greater-than operator will append the contents to the file keeping whatever is already in there.

It’s definitely a problem if you end up nuking a whole file like .gitignore with output redirection as it means having to create the whole file again.

Although misusing the output redirection operators can cause an incovenience another Git related problem which is likely to cause huge hair loss for new developers is not being able to exit vi.

9. Not being able to exit vi properly #

This problem is so common it’s become a bit cliche and you’ll probably have seen memes about it when reading various blog posts.

But for a new developer the struggle is real - you’ve done a git commit or merge and you’ve been whisked away from completing your command into some strange environment.

vi is just a text editor though and knowing how to exit it in these situations is just one of things you’ll need to learn.

If you find yourself in this situation, here’s how you exit vi.

Press Esc to enter what is known as ’normal’ mode
Type :q to quit

So now you know how to exit the text editor vi your life is complete and you can sucessfully commit your code and complete your projects.

Of course a much more straightforward text editor is Visual Studio Code and it’s quite handy to open this directly from your command prompt.

10. Not being able to open VS Code from the command line #

As your experience on the command line grows you’ll probably find yourself setting up your projects directly on the command line using mkdir or similar to get started and then you’ll probably want to dive straight into VS Code to start coding.

New developers may not know how to or be able to open VS Code from the command line.

To open the current folder, this should just be a simple command on the command line.

code .

But if you’ve installed a different shell or it’s PATH isn’t configured correctly you might get a ’not found’ error or similar.

To fix this, VS Code actually gives us a way to ensure your environment is set up correctly.

Open the Command Pallete in View -> Command Pallete
Type shell command and select the Shell Command: Install 'code' command in PATH command

You might need to restart your command prompt to see the results but once this is done the above command should work like a charm for you!

11. Not using nvm #

Once you’re starting to work on different projects you’re most likely going to be running Node.js in some way to either build your front-end code or create Node-based APIs.

Whilst a lot of tutorials will recommend installing Node.js directly from their website with one of their release packages, it can quickly become out of date as the release cycle for Node.js is quite frequent.

This isn’t much of a problem if you’re learning to code because you can just install the latest version of Node.js but when you start working professionally you’ll understand that you may have the need to switch back to older versions of Node.js to diagnose problems with older code or work out why a project is building in one environment and not another.

So the solution here is to make sure you can manage your Node.js installations using nvm the Node Version Manager.

This will enable you to get multiple Node.js version installed on your local machine and switch between them easily.

You can get NVM installed by following the instructions on their GitHub repository and Windows users don’t fear, there is an NVM for you too.

Once installed it’s simply a case of installing the version of Node.js you need:

nvm install 18.10.0

You can install as many different versions as you need and you can switch easily at any time by using:

nvm use 18.10.0

Talking about environments, one last mistake new developers make is connecting to their services using the root user all the time.

12. Logging in as root all the time #

First of all if you’re a new developer and you’re running your own private server then absolutely fair play - I have a lot of respect for you!

It’s not that running your own server for your projects is better or in any way sensible but there is so much you can learn from doing this.

From learning how to use the protocols to connect, the tools you need to host your apps and how to continuously update your projects there are so many skills you can pick up which are incredibly useful for your career.

But if you’re going to run your own server you should be mindful of security.

One of the most common mistakes new developers make is to login to their server as the root user all the time.

The problem with this mainly is that you don’t want to be logged in as the root user to your server and accidentally update or delete something you didn’t mean to but also having escalated privileges in your session increases the risk of malicious things from happening to your environment.

The solution to this of course is to create your own user account and use this for access to your server.

This way you can limit the bad stuff other people (and you) can do when remotely logged on.

To create a new user:

useradd -m james

The -m option just makes sure the user has a home directory created when creating the account.

Then set a new password:

passwd james

You’ll also probably want to add the user to the sudo list so they can perform some tasks with elevated privileges:

usermod -aG sudo username

Of course, all of this is only possible if you still have some kind of access to your remote server. So here’s one little extra mistake that new developers who are brave enough to run their own servers can sometimes make; losing root access to their server.

(Bonus) Losing root access #

It can feel a bit final - you can’t login with any of your non-root accounts and for whatever reason, your root password or SSH key is no longer working.

You might be tempted at this point to delete your server and just start again but that of course will mean losing all your data!

But all is not lost!

Before you get to that point, you might want to see if your provider has the option for you to put your server into recovery mode which will enable you to reset your root account and allow you to regain access.

If you want to see detailed instructions on how to do this then check out this next tutorial where i’ll show you how to recover root user access on a Digital Ocean droplet.

But that’s 12 mistakes that new developers make on the command line and how to fix them, thanks very much for watching, and keep on coding.