{"id":23455,"date":"2022-12-14T17:55:19","date_gmt":"2022-12-14T17:55:19","guid":{"rendered":"https:\/\/mailinvest.blog\/index.php\/2022\/12\/14\/how-to-deal-with-spaces-in-filenames-on-linux\/"},"modified":"2022-12-14T17:55:19","modified_gmt":"2022-12-14T17:55:19","slug":"how-to-deal-with-spaces-in-filenames-on-linux","status":"publish","type":"post","link":"https:\/\/mailinvest.blog\/index.php\/2022\/12\/14\/how-to-deal-with-spaces-in-filenames-on-linux\/","title":{"rendered":"How to Deal With Spaces in Filenames on Linux"},"content":{"rendered":"

<\/a>\n<\/p>\n

\n
\"Linux
fatmawati achmad zaenuri\/Shutterstock.com<\/a><\/span><\/figcaption><\/figure>\n

If you have a filename with spaces on a Linux system, wrapping your filename in quote marks lets Bash treat it correctly. Tab completion makes entering filenames on the command line easy, even if they contain spaces.<\/p>\n

Like most operating systems, Linux supports filenames with spaces in them. But using these filenames on the command line isn\u2019t always straightforward. Here are several ways you can handle filenames containing spaces.<\/p>\n

The Humble Filename<\/h2>\n

Everything stored on your computer\u2019s hard drive<\/a> needs to have a name. Without a name, no files would exist. All of the applications and daemons that are launched when your computer boots up, and all of the software that you use, has to be identified and stored in a file system.\u00a0That identification is the name of the file.\u2019<\/p>\n

The same thing applies to the files that you create or install. All your documents, images, and music need filenames. Without filenames, none of your digital assets could exist.\u00a0Because filenames are so important, Linux tries hard to impose as few rules about their composition as it can.<\/p>\n

On Linux, a filename may contain any character apart from the forward slash \u201c\/<\/code>\u201d and the null character, 0x00<\/code>. The null character is used to mark the end of a string, so it can\u2019t be present in the string itself, or Linux would truncate the filename at the position of the null character. The \u201c\/<\/code>\u201d forward slash is used as the separator in directory paths.<\/p>\n

Filenames are case-sensitive,\u00a0and can be up to 255 bytes long<\/a>, including the null character. Directory paths can be up to 4096 bytes long, including the null character. Note that this is their length in\u00a0bytes<\/em>, which might not equate directly to characters<\/em>. 16-bit Unicode characters, for example, take two bytes each.<\/p>\n

Retro-computing enthusiasts and those with long memories will know that in the early days of personal computers, Microsoft\u2019s Disk Operating System<\/a>, DOS, was case-insensitive and had a filename limit of eight characters, plus a three-character extension<\/a>.<\/p>\n

You had to be very thoughtful and sometimes creative when you named files. By comparison, the freedom we have today means we can name files whatever we want, with little thought to anything other than the description we\u2019re creating for that file.<\/p>\n

But with filenames, what trips us up most often isn\u2019t the characters we type, it\u2019s the spaces between them.<\/p>\n

Why Spaces in Linux File Names Are a Pain<\/h2>\n

Shells such as Bash will interpret a space-separated string of words as individual command arguments, not a single argument. Here\u2019s an example, using touch<\/code> to create a new file<\/a> called \u201cmy new file.txt.\u201d<\/p>\n

touch my new file.txt<\/pre>\n
ls<\/pre>\n
\"Trying<\/p>\n
As we can see, ls<\/code> shows us that there are three files created, one called \u201cmy\u201d, another called \u201cnew\u201d, and one more called \u201cfile.txt.\u201d<\/p>\n
Note that touch<\/code> didn\u2019t complain or throw an error. It carries out what it thinks we\u2019re asking it to do. So it silently returns us to the command line. If we\u2019re not motivated to check, we won\u2019t know things haven\u2019t gone according to plan.<\/p>\n
To create the file we wanted, we\u2019ve got to quote or escape.<\/p>\n
How to Quote and Escape Spaces<\/h2>\n
If we quote the entire filename, touch<\/code> knows it needs to treat the quoted text as a single argument.<\/p>\n
touch 'my new file.txt'<\/pre>\n
ls<\/pre>\n
\"Using<\/p>\n
This time we get the single file that we expect.<\/p>\n
We can get the same result if we use the backslash character \u201c\\<\/code>\u201d to escape the spaces. By \u201cescaping\u201d the spaces they\u2019re not treated as special characters\u2014that is, argument separators\u2014they\u2019re considered to be plain old spaces.<\/p>\n
touch my\\ second\\ new\\ file.txt<\/pre>\n
ls<\/pre>\n
\"Using<\/p>\n
That works, but escaping spaces makes typing filenames slower and error-prone. Things can get really ugly if you have directory names with spaces in them too.<\/p>\n
cp dir\u00a0one\/my\\ text\\ file.txt dir\\ two\/my\\ text\u00a0file.bak<\/pre>\n
ls<\/pre>\n
\"Using<\/p>\n
That command copies a single text file from a directory called \u201cdir one\u201d to a directory called \u201cdir two\u201d, and saves the copy as a BAK file. And it\u2019s a fairly simple example.<\/p>\n
How to Fix the Space Problem at Its Source<\/h2>\n
If they\u2019re your own files, you could take the policy decision to never use spaces, and create (or bulk rename<\/a>) filenames like this.<\/p>\n
mynewtextfile.txt<\/pre>\n
Admittedly, that\u2019s a robust solution but it\u2019s still ugly. There are better options, such as using dashes \u201c-<\/code>\u201d or underscores \u201c_<\/code>\u201d to separate your words.<\/p>\n
my-new-text-file.txt<\/pre>\n
my_new_text_file.txt<\/pre>\n
Both of these will sidestep the problem, and they\u2019re readable. If you don\u2019t want to add extra characters to your filenames, you can use CamelCase<\/a> to make your filenames readable, like this:<\/p>\n
MyNewTextFile.txt<\/pre>\n
Tab Expansion Makes Dealing With Spaces Easy<\/h2>\n
Of course, adopting a naming convention and sticking to it will only help when you\u2019re dealing with your own files. Files that come from anywhere else are unlikely to follow your adopted naming convention.<\/p>\n
You can use tab expansion to help you accurately \u201cfill out\u201d filenames for us. Lets say we want to delete<\/a> the BAK file we created in \u201cdir two\u201d, using rm<\/code>.<\/p>\n
We start by typing \u201crm dir\u201d because we\u2019re using the rm<\/code> command and we know the directory name starts with \u201cdir.\u201d<\/p>\n
rm dir<\/pre>\n
\"Typing<\/p>\n
Pressing the \u201cTab\u201d key causes Bash to scan for matches in the current directory.<\/p>\n
\"Pressing<\/p>\n
There are two directories that start with \u201cdir\u201d, and in both cases the next character is a space. So Bash adds the backslash character \u201c\\<\/code>\u201d and a space. Bash then waits for us to provide the next character. It needs the next character to differentiate between the two possible matches in this directory.<\/p>\n
We\u2019ll type a \u201ct\u201d, for \u201ctwo\u201d, and then press \u201cTab\u201d once more.<\/p>\n
\"The<\/p>\n
Bash completes the directory name for us and waits for us to type the start of the filename.<\/p>\n
We only have one file in this directory, so typing the first letter of the filename, \u201cm\u201d, is enough to let Bash know which file we want to use. Typing \u201cm\u201d and pressing \u201cTab\u201d completes the filename for us, and \u201cEnter\u201d executes the entire command.<\/p>\n
\"The<\/p>\n
Tab expansion makes it easy to ensure you get filenames right, and it also speeds up navigating and typing on the command line in general.<\/p>\n
RELATED:<\/strong> Use Tab Completion to Type Commands Faster on Any Operating System<\/em><\/strong><\/a><\/p>\n
How to Use Filenames With Spaces in Bash Scripts<\/h2>\n
It\u2019s no surprise that scripts<\/a> have exactly the same issues with spaces in filenames as the command line does. If you are passing a filename as a variable make sure you quote the variable name.<\/p>\n
This little script checks the current directory for files that match the file pattern \u201c*.txt\u201d, and stores them in a variable called file_list<\/code>. A for<\/code> loop<\/a> is used to perform a simple action on each one.<\/p>\n
#!\/bin\/bash
\n
\nfile_list=*.txt
\n
\nfor file in $file_list
\ndo
\n\u00a0 ls -hl $file
\ndone<\/pre>\n
Copy this text into an editor and save it to a file called \u201cfiles.sh.\u201d Then use the chmod<\/code> command<\/a>\u00a0to make it executable.<\/p>\n
chmod +x files.sh<\/pre>\n
\"Using<\/p>\n
We\u2019ve got some files in this directory. One has a simple file name, and the other two use underscores \u201c_<\/code>\u201d or dashes \u201c-<\/code>\u201d instead of spaces. This is what we see when we run the script.<\/p>\n
.\/files.sh<\/pre>\n
\"Running<\/p>\n
That seems to work nicely. But let\u2019s change the files in the directory for files that contain spaces in their names.<\/p>\n
.\/files.sh<\/pre>\n
\"Running<\/p>\n
Every word in each filename is handled as though it was a filename on its own, and so the script fails. But all we need to do to make the script handle spaces in filenames is to quote the $file<\/code> variable inside the for<\/code> loop.<\/p>\n
#!\/bin\/bash
\n
\nfile_list=*.txt
\n
\nfor file in $file_list
\ndo
\nls -hl \"$file\"
\ndone<\/pre>\n
Note that the dollar sign \u201c$<\/code>\u201d is inside the quotes. We made that change and saved it to the \u201cfiles.sh\u201d script file. This time, the filenames are handled correctly.<\/p>\n
.\/files.sh<\/pre>\n
\"The<\/p>\n
RELATED:<\/strong> How to Process a File Line by Line in a Linux Bash Script<\/em><\/strong><\/a><\/p>\n
Spaced Out, But Not Flaky<\/h2>\n
Avoiding spaces in your own filenames will only take you so far. It\u2019s inevitable that you\u2019ll encounter files from other sources with names that contain spaces. Thankfully, if you need to handle those files on the command line or in scripts, there are easy ways to do so.<\/p>\n<\/div>\n