Linux space in file path

How to Read a Filename with Spaces in Linux

It’s not very common in Linux to handle filename with spaces but sometimes files copied or mounted from windows would end up with spaces.

While it is not recommended to have file names with spaces, let discuss how to manage filename with spaces in a Linux system.

We will cover how to create, read and copy a file which has spaces in their filename.

1) Creating file names with spaces

To create files with spaces in file names, run the command as shown

For example, to create a file called ‘linoxide docs‘ use the syntax below

Output

If you want to view such a file with space in the file name, use the same principle of enclosing the file names inside the quotation marks.

2) Read a File with spaces in filename

You can use ‘cat’ command or open the document using your preferred text editor such as vim, nano or gedit.

Alternatively, you can use the syntax below

Let’s add some text to the ‘linoxide docs’ file

To view the file execute the command below

Output

3) Creating directory names with spaces

To create directory names with space in between use the syntax below

Please note the space after the backslash

For example, to create a directory called ‘linoxide files‘ run

Output

4) Navigating to a directory with spaces in the directory name

To navigate to a directory with spaces in its directory name, use the syntax below

To navigate to the directory ‘linoxide files’ execute the command below

5) Copying a directory with spaces in the directory name

To copy a directory with spaces in its directory name to a different location use the syntax below

For example to copy ‘linoxide files’ to /home/james path execute

Hope this article explained well on how to manage filename with spaces. Thanks for taking the time to read this article and please leave your comments.

Источник

How To Deal With Spaces in Paths on Mac and Linux

Sep 14, 2018 · 7 min read

If you’ve ever had to use paths with spaces on the macOS or Linux command line, you might wonder why it’s such a hassle, and what’s the best way to fix it. This article explains the problem, why we’re still dealing with it, and the best ways to fix it.

The Problem of Spaces On the Command Line

In the macOS Terminal or any Linux/Unix shell, a common command line might look like:-

When you specify a path after a com m and like this, the path part is called a command line argument. It has nothing to do with arguing, it’s simply a mathematical term that harks back to the days when most computer programs were written by mathematicians. An argument just means a bit of information you want to pass to the command.

Command line arguments are separated from the command, and from each other, by spaces. When you press return the shell starts parsing the command line and one of the first things it does is to split up the command line at each space. Then it considers the first unbroken string of characters to be the command, and every subsequent string to be an argument to the command, like this:-

That’s a simplified general form of the command line. (For the purposes of this discussion I’m going to ignore command line options.)

Perhaps you can already see the problem. What if the path contains spaces? It’s not a hypothetical situation: on macOS, there’s a directory in home called Library , and inside that there are quite a few subdirectories with spaces in their names. For example, you might want to list the contents of the Application Support subdirectory:-

If you try this you’ll get, not one, but two error messages!

Can you see what’s happening here? The error messages both originate from the ls command and they are saying it can’t find either the Library/Applications or the Support paths.

That’s because the shell interpreted the space in the path as a separator, and it therefore assumed there were two arguments, Library/Application and Support , which it duly sent to the ls command. And ls of course tried to list the contents of both directories.

There are two ways to alleviate this problem.

Method 1: Removing Spaces With Quotes

The first is to use single or double quotes:-

These work because the whole path is enclosed in a quoted string which tells the shell not to split it up. When the shell sees a string of characters enclosed in quotes, it ignores any spaces or other special characters inside it and treats it as a single argument. And then, internally, it removes the quotes so they are not part of the argument, leaving only the characters between the quotes.

The shell is surprisingly lenient about where you can place the quotes. The following all work:-

Obviously some of these are more readable than others. The first form is the most sensible because it quotes only the part of the path that has an embedded space. But the other examples do demonstrate quite well that the quotes are completely stripped out and you can’t split a path with a quote.

If you’re wondering about the difference between single and double quotes, it’s to do with the the way the shell interprets special characters inside the quotes. Double quotes are “weaker” than single quotes and allow certain characters to keep their special meaning. The only special character that has any relevance to this article is the backslash, which is the subject of the next section.

Method 2: Escaping Spaces With Backslash

A second, more “hardcore” method to ignore spaces uses what are called escape characters. Escape characters change the meaning of other special characters.

In the context of command line arguments, a space is considered a special character because it separates the arguments. When an escape character appears in front of a space, it removes its special meaning and makes it appear to the shell just like any normal character ( a, b, c, etc). When the shell sees an escaped space it no longer treats it as a separator and doesn’t split the command line input around it.

The character you use to escape spaces in the shell is the backslash. So this command:-

might look a bit weird at first, like someone’s got confused about whether they’re on Unix or Windows. But if you look closely you can see the backslash immediately precedes the space, so it’s telling the shell to treat the space like a normal character.

This has exactly the same effect as wrapping the path in quotes, but it’s an older method dating from the earlier days of Unix shells. For a single space, it can be quicker to escape it than quote the entire path. On the downside, if there are lots of spaces in a path, you have to escape all of them individually, so it makes more sense to enclose it in quotes.

Sometimes if you copy a path from elsewhere in macOS to the Terminal you’ll see the spaces have been automatically escaped in this way.

If this is confusing, don’t worry about it: you can use quotes instead. But now if you see a backslash character in a path like this, you’ll at least know what it is, even if you can’t remember the details.

Don’t Mix Escapes and Quotes

It’s best to decide on a single way of removing spaces from your paths and stick with it. If you start mixing backslash escapes with quotes you’re likely to get confusing results.

For example, accidentally putting an escape backslash inside single or double quotes will cause the backslash character to lose its special meaning and be taken literally:-

But Why Didn’t They Think Of This?

This entire topic might seem like a bug in the shell, and a pretty obvious one at that: how could a command like ls not be able to deal with something as commonplace as a space in a path?

The answer, of course, is history. Unix is almost half a century old and has been successful beyond even the wildest, psychedelic dreams of its late 1960s creators. OK, that’s maybe stretching things a bit. The creators, Ken Thompson and Dennis Ritchie (pictured below), were legends but they didn’t exactly look like party animals…

But seriously, in the early days of Unix (and every other operating system), file and directory names were short strings of alphanumeric characters. If you look at the root-level system directories on any Mac or Linux machine you’ll see may of them have names like var , usr , dev and so on.

In fact, for the first couple of decades of Unix’s history, most systems used the 7-bit ASCII character set, often uppercase only and sometimes with a maximum filename length of 12 characters — including the dot! (Windows had this restriction until the mid 1990s.) There was no Unicode, no emojis… and no spaces. The underscore character was very standard in programming languages as a non-breaking space, and since most folks who worked with early operating systems were also programmers, the tradition naturally carried over to filenames.

In fact, Unix itself was considered very forgiving in that it allowed lower-case characters in file names. Technically, it actually did allow spaces and other non-alphanumeric characters. But in reality, no systems programmer would normally use a space, so it was never really a problem when using the shell. If for some reason they ever did need to reference a path containing a space, they’d know how to escape it. Unix was not a consumer operating system, so it was not an issue.

Summary

This article has discussed the problem of spaces in the Unix command line. Spaces are interpreted by the shell as special characters that separate command line arguments, so paths containing spaces are split into multiple parts when parsed by the shell. This prevents them from being interpreted correctly by the receiving command.

The solutions are to use quotes or the backslash escape character. The escape character is more convenient for single spaces, and quotes are better when there are multiple spaces in a path. You should not mix escaping and quotes.

The reason this is even a problem is historical. In the early days of Unix no-one used spaces in filenames so it was not a problem. More recently spaces have become commonplace, but the Unix shell behaviour remains the same so people encounter the problem often.

This post is adapted from a series of articles on the macOS command line, for a forthcoming eBook by Lee Dowthwaite. Keep up to date by visiting my website .

Источник

Dealing With Spaces in File Names in Command-line (GNU/Linux)

Most people that use the GNU/Linux operating system do not like to deal with the command-line at all, though having a basic understanding of it (such as memorizing commands for mounting devices and copying files for instance) can come in real handy sometimes.

That said however, when dealing with files under command-line, say that you had to use it to backup your data because the desktop session was not working anymore, it is pretty common that one should come across files that contain spaces in their names. And unless you are aware of this simple trick, it can be quite frustrating, because for each space you have to add a backslash ( \ ) when using the command-line.

For example, let us assume that I have a file called Data backup 2.tar on my Home folder, and that I need to copy it to /media/pen location using the ‘cp’ command. If I enter the below command then I will receive an error saying that there exists no such file/directory.

sudo cp Data backup 2.tar /media/pen

Note: I am running ‘cp’ with ‘sudo’ (administrative) privileges.

In fact, if you carefully look at the output, you can see that command-line has treated the file name as three different files due to the three spaces that are present in the file name. So how can we overcome this ?

Well, you can add backslashes as mentioned before and below is the correct command using that.

sudo cp Data\ backup\ 2.tar /media/pen

But as you can see, not only it is time consuming, but since we are not that used to seeing backslashes on file names, it can be really confusing as well. So instead, you can put the file name that contains spaces, between two apostrophes. For this example, I will use the below command and the copying will be carried on without errors.

sudo cp ‘Data backup 2.tar’ /media/pen

As you see, once you add the first apostrophe, then you can type the file name freely, and when done entering the name, make sure to add another apostrophe (this is very important). That is all there is to it.

If a path contains two or more file names with spaces …

You can do the same. You can add apostrophes separately to each name, or you can put that particular path which contains names with spaces, between two apostrophes, as a whole, which is much easier. Coming back to the above example, let us say the Data backup 2.tar file is inside a folder called untitled folder that is located on my Home folder, then I will use the below command for copying it to the same destination.

sudo cp ‘untitled folder/Data backup 2.tar’ /media/pen

If both file paths (source and destination) contain such names (or even a mix — a file path that contains names with spaces and names without them), then you can add apostrophe pairs to each path, separately. Let us take the same example and say that this time we need to copy it over to /media/pen 2/new folder (as you can see this path contains two names with spaces in their names and one without).

For that I will use the below command.

sudo cp ‘ untitled folder/Data backup 2.tar ‘ ‘ /media/pen 2/new folder ‘

(Again, please remember that I have used ‘sudo’ with ‘cp’ because I am copying files to a location which requires administrative privileges. Here I have also colored the apostrophe pairs differently so it is easy to understand).

But the rule is, no matter what you do, you should treat the two paths (file source and the destination) individually. In other words, you cannot put the whole command (two file paths) inside two apostrophes, if you do so, then ‘cp’ will treat it as a the file source and will give an error saying the destination is missing.

sudo cp ‘untitled folder/Data backup 2.tar /media/pen 2/new folder’

To finish, not just with ‘cp’, you can use this trick with almost any command that requires you to deal with a file name that contain spaces under the command-line in GNU/Linux. Good luck.

Источник