I’m writing software that needs to ask and tell users about files and their locations, and want to make it completely grammatically proper and clear. But I realize I don’t know many of these basic things as exactly as I wish. In my heart of hearts I know that tiny errors and sloppy nomenclature propagate and eventually make the ground we stand on skeevy everyplace.
So, assume my users are all in Win XP environments, and consider this text file on a network drive someplace:
Q:\Common\Reference\Values.txt
What is the filename, “Values” or “Values.txt” or “Q:\Common\Reference\Values.txt”?
What do you call whichever of these isn’t exactly a filename?
What is the extension, is it “txt” or “.txt”? That is, is the dot part of the extension?
Would you guess that most engineers have their PCs set up to show extensions or hide them?
When referring to the part of this thing that identifies the last level folder, what do you call it?
Which of these is a path, “Q:\Common\Reference\Values.txt” or “Q:\Common\Reference”? That is, does “path” imply that the name of the file itself is included or excluded or either?
Do you write it “Q:\Common\Reference” or “Q:\Common\Reference”? That is, do you include the final backslash?
What’s a fully qualified filename? What is the opposite of one?
Great thanks to anybody either kind enough or fussy enough to be willing to help clarify things for me!
I can’t claim to be an authority on this, but I would say:
Q:\Common\Reference\Values.txt
The filename is Values.txt. Values is the stem name.
The extension is txt. The dot is not part of the extension.
I’d guess most engineers have their machines set up to show extensions, but I’m not sure of that. This may be clouded by the fact that I hate hidden extensions.
The path does not include the file name.
Personally, I prefer to include the trailing slash, but I do not believe this is the standard. In Windows Explorer, the slash is not included.
I happen to have MS Visual FoxPro open, and it has several functions for retrieving parts of a file name:
I had not heard of a stem name before, though I have heard that part of the name called the base name.
Why is using the “Q:” element not best practice? I am guessing that it is because it is based on a local logical mapping of a drive, and so depends on how the particular local PC is set up, and does not depend on how the drive that actually holds the file is set up - is that it? I may use it anyway, because the users will see it that way in their work, but if so, I wonder if there is a proper name for using this element or some other statement that compensates for its weaknesses? I guess I could show both forms (there is another context in which I actually do just that).
I’ve long been confused about whether a path includes the filename. I spent some years going back and forth between DOS/Win and BSD and SVR4 - that must be where it started.
Exactly. On my work PC, I have a drive mapped as S: - S: is not a server name, but rather is just the mapping of a particular server and directory structure. I could just as easily have named it R: or T:. It’s a very handy shortcut, though. The real fully-qualified name for one of my files might otherwise be
Much nicer to be able to give “\servername\california-users\security-groups\my-specific-group\my-name” an alias such as S:! The confusion can come when different users map to different letters. I “grew up” with this server being my group’s Share drive, but a co-worker calls it W for Work files.
What you can do is consistently use fully-qualified names, and parenthetically say that most users probably have this mapped as drive Q: or whatever.
Just because the drive mapping is Q: on one machine doesn’t mean that it’s Q: on another machine. Or for another user on the same machine. Using the UNC name gets around this.
If it’s a corporate machine, that chances are very good that Q:\ and W:\ are standard corporate-wide. With stupid restrictive GPO’s, users can’t change the mappings.
As for engineers, wow, some of the engineers I work with are the stupidest people I’ve ever met. Yeah, really. If it’s not their field of expertise, they don’t know a thing about it. In some respects, I’m like that (dimensional control holds no interest for me, for example). I turn on file extensions if that helps you, but I have enough knowledge to lie and demand special GPO’s that let me do it. I’d think that most of the other engineers just use the corporate load as-is.
Hidden file extensions is very dumb. I can create a virus executable called “ReadMe.txt.exe” and if file extensions are hidden, you see it as “ReadMe.txt”.
I think you are damned if you do/don’t on the UNC vs Drive mapping…
We just had a share moved to a different server at work - any app, shortcut, etc using a UNC stopped working but the drive mapping was fine (because the login script was adjusted site wide when the share was moved). As Balthisar said, if your company lands upon standard drive mappings and those never change, you don’t care about the real server/share or if it ever gets changed.
Microsoft has a DFS logical mapping that eliminates some of these issues.
The damned if you do or don’t thing probably has a good resolution choosing the “Q:” option, for two reasons: 1) Everybody’s training and AFAIK work patterns use the mapping, not the server; and 2) Now that you mention it, they often move things from server to server here, and adjust the login script to automate making this invisible to users. Thus, it is the logical mapping and not the server name that is more reliable.
I am glad to be in the know about computer issues, and share some of your disdains for the uninitiated. That being said, what does “GPO” mean?
This is why each of the over 30 manuals for our product starts with a section explaining the conventions and formatting used in the book. Some people think the path is just the directories while other people think the path includes the filename, so we state up front what we mean by those terms. We also state what it means when something is in bold, or when something is surrounded by square brackets or curly braces.
Good answers, so I won’t repeat them. I just have a few things to add.
With respect to Quartz’s post #3, including the \servername\sharename wording is necessary only if appropriate, and too complex if a network does exist or it isn’t necessary to consider it.
Which kinda leads to my next comment…I think it’s useful to emphasize the differences between absolute (fully qualified) path/filenames and relative ones. This is where I see people get into trouble most often after they get the basic path/file concept under their belt. It’s even more important when many display windows don’t show the full path/filename, but only the filename. In my system, that leaves off vital data, and it results in multiple “My Documents” folders that all look alike. Users often don’t know this, and get frustrated when ther files seem to disappear. “But I know I saved it!”
And the reason I recommend showing file extensions rather than hiding them is they contain valuable information that is not obtainable otherwise, like what kind of file it is. Icons were intended to take this function over, but they do not, for three reasons: 1. Icons can be displayed so tiny that they can’t be interpreted, and 2. If you don’t recognize it, you can’t tell what it means, and 3. The same file type can have a different icon on another computer, since the principle is to associate a file type with a program, not a function or data type. So 10 different computers, each with a different graphics display program installed, will use 10 different icons for JPG files. Stupid.
Ah, I forget that Windows and Mac OS both default to that stupid, ridiculous icon-view. Yeah, you need file extensions to be shown. The first thing I do on any new machine is switch to detail view (column view on the Mac), and make sure that it’s the default for all windows. The benefit is, you always have the actual file type (not the extension) in the type column. No wonder I never get stung by stupid viruses. Of course given all that, I still want to show file extensions on most file types, because without the extension being visible, you lose two things: the file type column is sometimes stupidly generic, and then there’s no easy way to change file extensions.
Those are Windows’ Group Policy Objects. When corporate users are logged on to a Windows domain, the GPO’s take priority over all of the local computer settings. This gives IT the ridiculous power of preventing users from doing massive harm to their computers, such as preventing them from changing the time zone, or installing software that has an installer that check GPO’s. There really are GPO’s that can affect every little, tiny details of how the OS operates, and what can or can’t be done. This applies even if you’re an administrator or owner of the computer! Of course if you sign on to localhost rather than the domain, you have control again, but you lose a lot of the automatic stuff that domain login offers.
>useful to emphasize the differences between absolute (fully qualified) path/filenames and relative ones.
Musicat, maybe I am confused. I thought the difference between absolute and relative was that relative starts in the current folder whereas absolute starts in a root directory. Therefore .\extras\list.txt is a text file named “list” that is in the extras folder in the current directory, a relative path and name. I was less clear what “fully qualified” meant but thought it meant the path was included in the “whole shebang”. Therefore this example would be a fully qualified relative name for the file, having all the qualifications needed to find the file.
Note that having all the qualifications needed to find a file is a different issue than whether the directions for finding it start in the current directory or the root.
I am not sure about this, so, am I mistaking the point? Does “fully qualified” exactly mean “absolute”?
Napier, I could be wrong about this. I don’t use the phrase “fully qualified”, but when hearing it, I assume it means an explicit, complete path&filename that would specify an absolute address compared to a relative one. So see if others agree or not.
However, I think your “.\extras\list.txt” reference might be (in Windows & DOS) missing a period, and should be “…\extras\list.txt”, as “…” means “up one level”, but a single dot starting a path/filename is meaningless. Other OSes might have different interpretations.
Absolute means, to me, that it matters not where you are currently situated, but an absolute address will always get you there. Ignore where you are, just go there. (Might compute from root or network location)
A relative address is computed from your current location to form the final destination. Start from where you are, and navigate somewhere else.
>Absolute means, to me, that it matters not where you are currently situated…
>A relative address is computed from your current location…
Yes, this is what I mean.
Moreover, “fully qualified” means having all the qualifications needed, as opposed to being for example just a filename without an indication of where. But this I’m less sure of.
When I say “.\extras\list.txt”, by the first single dot I mean “the current directory”. A double dot would have been the directory one level up.
Also, I’m using the older word “directory” instead of the newer word “folder”, though AFAIK in Windows they mean the same thing.
Directories used to be more meaningful, at least in Unix. They called it a directory because it was like the phone book. You could access something by looking up its name in a directory. But it isn’t actually in the directory, just like people who own phones aren’t. And, you can be in multiple directories. Just like you can have a directory of New Jersey businesses, and a directory of East Coast Florists, and a directory of members of the Chamber of Commerce, and one company might be listed in all of these. Which is a great way to handle files, too, because you could write something that is Correspondence and is part of January and is aimed at National Flange who is a Vendor, for the Refinery Project. So all of those could be directories, and the thing you wrote is listed in each of them, and not until you remove it from all of them does it disappear. The file is linked into each directory for the purpose of finding it. The Windows idea of a folder that actually contains the file is a good way of chopping this kind of power off at the knees.
I couldn’t agree with you more, but it labels us as old-timers if we use the phrase “directory.”
If “.\extras\list.txt” = “extras\list.txt”, then why use the extraneous “.”? Trying that at DOS level in XP, I get exactly the same display. Why complicate it?
(Novell used to use each extra dot over 2 to mean “one more level up,” so “…\file” actually had some meaning. A good idea, but not used outside of Novell, AFAIK.)
If I remember correctly, some *NIX systems don’t automatically make files in your current directory executable. So if you were in /usr/myprog/ and wanted to run go.sh, typing:
go.sh
might result in a file not found error and not work, whereas
The problem you describe has to do with one’s PATH environment variable, not so much the execution permissions on the file (although that has to be enabled as well). If you do not have the current directory (".") in your PATH, then as you say, the first command in your example won’t work.
There are actually good security reasons to leave the current directory out of your PATH, but in practice many people have it there anyway — precisely because they get annoyed having to type that “./” prefix. If you do include it, it’s best to put it at the end of the list.
Incidentally, there is no Unix feature I know of that will automatically give files execute permission, or act as if it’s there when it isn’t.