This is the third in our six or seven part series on how to use Linux if you are a regular smart person who needs a functioning computer but is not a geek. Today, a few items to know about files.
All computer systems keep your data and stuff in file, and you probably know that "programs" (applications) can be files (or sets of files) and that there are configuration files, etc. There are a few things about the Linux system, regarding files, that you should probably know, or at least, have a place to look up in case you need to. This is more of a list than a coherent story, so here's the list:
1) File names in Linux do not use "extensions" but many applications in Linux understand and will make use of them.
2) Although there are no limits that you need to know about regarding how long file names can be, there are limits (in all computer systems) as to what characters they can include. However, what you may not realize is that the limits that apply to Linux actually apply to all systems, because the Linux limits are the default Unix/Linux/BSD limits, and these are the systems that run the internet. So you would be foolish to ignore certain guidelines. Which are:
- Don't use spaces in file names. There are no systems that can tolerate spaces. There are only systems that pretend to tolerate spaces. But they are faking it. They usually do a good job at faking it, but spaces in file names can cause unexpected problems. Use underscores ("_") for spaces.
- Only use letters, numbers, the underscore, the dash, and the period. There are other characters you can use, technically. But don't.
- Do not use a dash (-) as the beginning of a file name.
- Don't listen to any of those people down in the comments about how it's OK to use spaces.
- In Linux, file names are case sensitive.
3) A Linux file is connected to a set of "permissions" and "ownerships." This can get complicated. A file can be tagged as "executable" or not, and it can be tagged as viewable or usable by a certain owner or not. This is complicated and hard (and also true for Windows and the Mac, by the way, but it is mostly hidden from you). Just know that "permissions" and "ownership" are issues and you may at some point need to work out a problem with these issues. But learning in advance what to do just in case is not a good idea.
4) You, as a specific user on your Linux sytem, own and have access to a subdirectory (folder) called home. It is abbreviated a s "~". Allmost all of the files you generate that are what you would think of as your stuff are in the home directory. In fact, all of it except some configuration stuff. Any software that puts your private data and stuff anywhere else is bad.
Organize your files within the home directory. Desktop is one of the subdirectories already there, and that represents the files and folders visible on your Gnome desktop.
5) Within the home directory are files that are "hidden." For the most part, files that begin with a dot (called "dot-files") are hidden. You can see them by telling the system you want to see them. They are not really "hidden" as in secret. They are just the sorts of things you don't normally want to see.
6) If you copy every single thing, including hidden files, from your home directory onto an external hard drive, you are doing a good enough job of backing up your stuff.
7) You can see your files by looking in folders that are on your desktop or using the Nautilus file manager or some other file manager.
Have I missed anything?
For a list of all the posts in this series, CLICK HERE.
- Log in to post comments
Regarding your third point, it's not that hard to figure out rights and permissions. It's sort of a 2 dimensional matrix. I do em' in Octal all the time since I know the representations for RWX (421).
As to your fifth point, that's why you do ls -la
The usual explanation of '~' is as an alias for $HOME .
Links, both hard and symbolic, was missed, but that may be for a future lesson. Also, I think you went overboard on the use of spaces in file names.
Todd: This is supposed to be very basic. I don't think links are appropriate at this point. But eventually, yes, it might be a good idea.
I'm not wrong about the filenames. Don't put spaces in your filenames.
Here's a document on the shared drive about it, you can reference it by clicking the link
http://datahouse.wau.edu/users/moi/How To Name Files.doc
In that document, which you can't acces because I used space in the filename, I might talk about the time no one (but eventually me) could fix a major access database becuase someone used a LEGAL character other than [a-zA-Z0-9_-] in a fieldname, a character used to define macros. What a fuckup that was! that was a field name and not a file name, but bad things can happen in a similar way.
I had another file on my external drive but it is hard to access it from some computers because the external drive came with the name "my book" and I've not gotten rid of the space yet.
No boys and girls, just avoid spaces in filenames. Just. Avoid. Them. Please.
Ah yes, symlinks. I've never had to do a hard link but I've done plenty of symlinks. ln -s
You mean http://datahouse.wau.edu/users/moi/How%20To%20Name%20Files.doc . :-P My browser handled the URL encoding for me automatically, so I didn't even have to know how to encode it for spaces.
So why recommend limiting themselves when it comes to filenames? Is it so they can interact with Windows filesystems without problems (in that case, make sure they dont use "con", "aux", and a billion other restricted names)? The only two characters not permitted on Linux, as far as I know, is / and nul.
I think spaces in filenames have their place. Putting spaces in important system paths is a ridiculous idea, and one of the many obvious mistakes MS has made over the years. But I like my media files (audio/video) to have spaces instead of underscores. The software I use to interact with these files handles spaces just fine. Even accessing them from the command line, my shell escapes everything for me.
The only time spaces have been a real problem for me is when compiling software. Those configure scripts reasonably assume your current working path has no spaces in them, since escaping all that stuff would be a complicated mess. Since Windows insisted on "Documents and Settings" (WTF?!) as the only directory I could write to on some systems, building software in Cygwin became impossible thanks to the spaces.
Mmm ... people who put spaces in filenames. Exterminate! Exterminate!
Actually, there was a pretty good essay on Linux filenames and what to avoid. Though it admits it's "Probably too late for an outright ban on spaces in filenames".
http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html
(He does offer some mitigating factors. At the very least, don't allow spaces at the beginning or end of a filename, for example.)
Skeeto: As an end user, no, I meant "how to name file" because my IT expert person told me I could use spaces no problem. Yes, a system or browser can in theory add the %20s in there. But, not in Microsoft Outlook accessing an on line shared drive, for instance. Better to not trust that every piece of software will do this for you. It's like driving through stop signs and assuming everybody will get out of your way. (Although the chances that software/system will screw up the spaces is smaller than that you will get hit by a car, it is not zero).
The only time spaces have been a real problem for me is when compiling software.
The examples I cites are real! The shared drive one is a great example. An entire college set up this shared drive, and eveyrone was told to use it, and everyone had the "spaces are OK" thing going, and everyone used the spaces, and then when people started "sharing" files by passing around the URL's it never worked and no one knew why (because no one asked).
That would be an example of a real problem! Your point of "documents and setting" is a good one. "My files" or "my pictures" etc. in another one. Spaces in 'paths' (as you say) is even worse!
But in Linux, the file/directory distinction is different than in windows.
Don't uses anything but a-zA-Z dot, dash and underscore in your filenames.
Ray: It is perhaps too late for an outright ban, but it is not too late to advice people to not make that mistake. Then those who don't make the mistake will be happier.
Regarding outlook:
file://h:\path%20with%20spaces\foo.doc
Greg, I would add that no filename should ever begin with a dash, although dashes are okay after the beginning.