{"id":3737,"date":"2024-01-26T02:15:00","date_gmt":"2024-01-26T07:15:00","guid":{"rendered":"https:\/\/www.both.org\/?p=3737"},"modified":"2024-01-22T09:38:20","modified_gmt":"2024-01-22T14:38:20","slug":"top-5-mistakes-every-new-linux-terminal-user-makes","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=3737","title":{"rendered":"Top 5 mistakes every new Linux terminal user makes"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n 1 <\/span>\r\n<\/div><\/div>\n

Learning to use the terminal is an important step in becoming a true power user of Linux, but it’s easy (and normal) to make mistakes along the way. Here are the top 5 mistakes new terminal users make, and what you can learn from them.<\/p>\n\n\n\n

1. Current working directory<\/h2>\n\n\n\n

When you first open a terminal, your current working directory is your home folder. You have access to all those directories you see in your home directory every time you open a file manager (Desktop<\/code>, Documents<\/code>, Downloads<\/code>, Music<\/code>, Pictures<\/code>, and Videos<\/code>). You can verify your location with the pwd<\/code> command:<\/p>\n\n\n\n

$ pwd\n\/home\/seth<\/code><\/pre>\n\n\n\n
You can list the files and folders within your current directory with the ls<\/code> or dir<\/code> or tree<\/code> commands:<\/p>\n\n\n\n
$ ls\nDesktop  Documents  Downloads\nMusic    Pictures   Videos<\/code><\/pre>\n\n\n\n
But you don’t usually stay in one place while using the terminal. You frequently move from folder to folder so you can open or modify or edit files. It’s easy to get lost, forgetting what directory you’re in and what files are around you.<\/p>\n\n\n\n
Lesson learned:<\/strong> When working in the terminal, it’s important to regularly verify your current working directory with pwd<\/code> so you don’t accidentally issue a command you intended to run in a different location.<\/p>\n\n\n\n
2. Use interactive options when using wildcards<\/h2>\n\n\n\n
Wildcards are great shorthand to make command entry faster, and to perform bulk actions on lots of files. However, they can be dangerous when you get them wrong.
It’s easy to process hundreds of the wrong files by using a wildcard in the wrong directory, or by using a wildcard that’s too broad.<\/p>\n\n\n\n
For example, suppose you want to run a sed<\/code> command on all HTML files in a directory, so you run this:<\/p>\n\n\n\n
$ sed --in-place 's\/day\/night\/g' *ml<\/code><\/pre>\n\n\n\n
Job done, until you find out that you accidentally ran that command on all your XML files, too.<\/p>\n\n\n\n
Lesson learned:<\/strong> Run a safe test command on the wildcard you think<\/em> you want to target before making a change. Some commands have a literal --dry-run<\/code> option. Others have an --interactive<\/code> option that forces the command to prompt you to confirm that you want to carry out the action. Sometimes the logic is reversed: a command refuses to make a major change unless you use a command (for example, sed<\/code> doesn’t write changes to a file without the --in-place<\/code> option or redirection).<\/p>\n\n\n\n
When in doubt, improvise. You can always “expand” a wildcard using the echo<\/code> command:<\/p>\n\n\n\n
$ echo .\/*ml\n.\/four.html .\/one.xml .\/three.html .\/two.xml\n$ echo .\/*tml\n.\/four.html .\/three.html<\/code><\/pre>\n\n\n\n
3. File paths<\/h2>\n\n\n\n
Many new terminal users don’t understand where files are located within the file system. It’s not a common mistake to make on the desktop because there are visual reminders there. You wouldn’t try to double-click on a document to open it if there was no icon to double-click. It’s easy to assume that the terminal application contains all your files all at once, but the terminal is, by design, limited in scope. Were the terminal to have access to every file everywhere on your system all at once, you’d end up accidentally renaming and moving and copying a lot more files than intended. Specificity is a super power, and it’s defined by the file path<\/em>.<\/p>\n\n\n\n
A file path describes where a file exists in a file system. A full (or “absolute”) file path always starts from the single folder at the start of your operating system, indicated by just a \/<\/code>, and then lists each folder within that folder until it traces the path to a specific file. For example, I have a file called IMG_0001.JPG<\/code> in my Pictures<\/code> directory. You probably have a mental image of where that file is and how you’d get there on the desktop. But for the terminal to understand how to find it, the location must be expressed as \/home\/seth\/Pictures\/IMG_0001.JPG<\/code>.<\/p>\n\n\n\n
An absolute file path is definitive. The terminal always understands an absolute file path, no matter what your current working directory is.<\/p>\n\n\n\n
The absolute path to a file can be unwieldy, though. Once you understand absolute paths, you can abbreviate any path to a relative<\/em> file path.<\/p>\n\n\n\n
A relative file path is based on your current location in the terminal. As long as you’re in the Pictures<\/code> folder, the full path \/home\/seth\/Pictures\/IMG_0001.JPG<\/code> can be shortened to just IMG_0001.JPG<\/code>, or .\/IMG_0001.JPG<\/code> for added clarity (the .<\/code> indicates no movement from your current location, and the \/<\/code> is a directory separator as usual).<\/p>\n\n\n\n
But suppose your current working directory was your home directory. Your Pictures<\/code> folder is located in your home directory, so to get to IMG_0001.JPG<\/code> you have to enter Pictures<\/code> first. The relative path in that case is .\/Pictures\/IMG_0001.JPG<\/code> or just Pictures\/IMG_0001.JPG<\/code>.<\/p>\n\n\n\n
Lesson learned:<\/strong> An absolute file path always starts from the start of a file system. A relative file path changes based on your location. The terminal understands both. For new users, the absolute file path is the most explicit and exact way to reference a file, so practice using them until you’re comfortable with the concept of file paths.<\/p>\n\n\n\n
4. Executable permissions<\/h2>\n\n\n\n
By default, most files aren’t executable. You can’t run them like an application, because most files are meant to be opened in<\/em> an application. That’s not true for shell scripts, though.<\/p>\n\n\n\n
Shell scripts are text files containing a list of commands, and they’re meant to be run like an application. They’re a powerful way to string existing commands together to form a new custom command. However, because a shell script starts out as a regular text file, it’s not seen by your terminal as an executable entity.<\/p>\n\n\n\n
To execute a file as an application, you can grant it executable permission with the chmod<\/code> command:<\/p>\n\n\n\n
$ chmod +x .\/example.sh<\/code><\/pre>\n\n\n\n
Alternatively, you can run the file in a sub-shell:<\/p>\n\n\n\n
$ bash .\/example.sh<\/code><\/pre>\n\n\n\n
Notice that in these examples, I use the .\/<\/code> notation as if the example.sh<\/code> shell script exists in my current directory.<\/p>\n\n\n\n
5. Typing errors<\/h2>\n\n\n\n
It sometimes feels like the more you type, the more you’re getting done. In a terminal, though, typing too much is one of the best ways to introduce mistakes.<\/p>\n\n\n\n
When you try to type a long and complex command, you’re liable to spell something wrong or use the wrong option. When you try to type a filename or a file path, you might forget to escape special characters (like spaces). The errors aren’t usually catastrophic, but they’re frustrating and time consuming.<\/p>\n\n\n\n
Lesson learned:<\/strong> There are several ways to ensure you’re entering the correct commands into your terminal:<\/p>\n\n\n\n
    \n
  • Copy and paste:<\/strong> If you’re using a command you found on a trusted website, copy it in your browser and then paste it into your terminal using Ctrl<\/strong>+Shift<\/strong>+V<\/strong> or right-click and select Paste<\/strong>.<\/li>\n\n\n\n
  • TAB:<\/strong> You can type part of a command or file path, and then press the TAB<\/strong> key on your keyboard for either auto-completion or for suggested completions. Use it even when you don’t think you need it. It’ll save you errors every single time<\/em>, even when it appears to not work (hint: it’s not working because you’re trying to auto-complete something that’s not where you think it is).<\/li>\n\n\n\n
  • Drag-and-drop:<\/strong> It’s the 21st century! You can drag a file or folder from anywhere on your computer, and drop it into your terminal. It gets replaced by its absolute path automatically.<\/li>\n<\/ul>\n\n\n\n
    Practice makes perfect<\/h2>\n\n\n\n
    To get good in the terminal, you have to use it as often as you can. You don’t have to use it for “serious” work at first, and you arguably shouldn’t, but you can and should do simple exercises in the terminal. Understand file paths, get used to wildcards, learn shortcuts, use the TAB<\/strong> key. The biggest mistake you can make when learning the terminal is to not use the terminal, so open it up every day, do your exercise, and you’ll be an expert in the terminal in no time.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Avoid these comman mistakes, and find out how to become an expert in the terminal.<\/p>\n","protected":false},"author":31,"featured_media":3522,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[5],"tags":[151,91,97],"class_list":["post-3737","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","tag-bash","tag-linux","tag-sysadmin"],"modified_by":"David Both","_links":{"self":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/3737","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/users\/31"}],"replies":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3737"}],"version-history":[{"count":3,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/3737\/revisions"}],"predecessor-version":[{"id":3796,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/3737\/revisions\/3796"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/media\/3522"}],"wp:attachment":[{"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}