Community

I searched the forum before posting this, but if this has already been posted, I apologize, please let me know.

I found a simple little formatting problem. If a file name has an ampersand in it, that character shows as a percent symbol in the file's Tab. It shows correctly in the Document Selector, Title Bar and Recent File List.

I am using TextPad 4.7.2 on Windows XP. Does anyone else get this?

I can reproduce the problem - but never have come upon it before as I would never use an ampersand in a file name (except for testing right now - the file in question is already deleted again)...
I stick to letters a-z, digits 0-9, underscore and dot. (dot mostly for use between name and extensions, rarely otherwise).

All other characters will give problems sooner or later.

Blanks will never be in one of my file names - although there are some files/folders on my system containing blanks (mostly from Windows, some from thirdparty software).

Well, I wasn't advocating using ampersands in file names, I was just pointing out a small formatting bug in the program. Regardless of whether or not it is a good idea to use the character in file names, since it is a valid character, the tab should show it.

MudGuard wrote:I can reproduce the problem - but never have come upon it before as I would never use an ampersand in a file name (except for testing right now - the file in question is already deleted again)...
I stick to letters a-z, digits 0-9, underscore and dot. (dot mostly for use between name and extensions, rarely otherwise).

All other characters will give problems sooner or later.

Blanks will never be in one of my file names - although there are some files/folders on my system containing blanks (mostly from Windows, some from thirdparty software).

Mudguard, would the world be a perfect place if everyone followed your rules of life ? Do you think that people are beneath you if they use the ampersand in a filename ? Personally, I *don't* think you are beneath me for choosing your rules for filenaming in a very old-fashioned unix-ite way. I've got nothing agains the fact that you decide to impose such rules upon yourself and sneer at others who use ampersands in filenames. Really I think that is up to you. I do think that this geek-like attitude doesn't help in IT and slows up constructive discussion though. Your comment did not help at all, as it was simply a criticism and nothing more (everyones a critic huh ... world would be a better place without critics I often think ...).

Anyway, I do use ampersand's. As I said in another post and as the original thread pointed out, it's not a major issue, but it is worthy of adult discussion instead of blatant pointless criticism and me-me-me comments. It doesn't bother me that the & displays wrongly, but bringing this up for the designers is useful, don't u think Mudguard ? Hopefully such a simple thing will be patched in 4.7.3. Of course, since Mudguard has told everyone how to live their lives, I will from now on tell everyone at work off for using spaces and ampersands in file names. Maybe I should try and implement a company policy to fire such people or to openly insult them ? what do you think Mudguard ? I wish that I could be as perfect a geek as you are ! I am just a geek wannabe !

What was that for?

Mudguard proposed no rules. He made no comments about others. He didn't criticise anyone; he didn't sneer at anyone; he didn't tell anyone what to do. And this matter is nothing to do with unix (where almost any character - even control characters - can be in a file name).

I agree completely with ben_josephs's observations.

Thanks MudGuard for sharing your work habits with us. We all work differently, but I think we also admit we don't have all the answers. This is a great place to learn from one another.

I for one appreciate your valuable inputs. And thanks for taking the effort to confirm the anomaly*.

By the way, I have the same work habit, only use letters and numbers, no punction/spaces. But I do also include the underscore. In addition I usually InitializeFileNames like this. Works for me, and minimizes problems when trying to interface with multiple applications with unknown rules.

Back to the issue: MudGuard's original message was that he confirms the anomaly* can be duplicated. It may not be a problem for some, but I think it is the consistency of expectations that caused dsunde to bring this up. A good observation on his/her part. And I agree with dsunde's last comment:

Regardless of whether or not it is a good idea to use the character in file names, since it is a valid character, the tab should show it.

--------------------------------------------
*anomaly:
A deviation from the common rule.
Something different, abnormal, peculiar, or not easily classified.

Sure, Mudguard confirmed the problem, but also: "All other characters will give problems sooner or later."

I didn't see what that was for. Kind of *instructional* to others on how they should do things. I never had a problem with other characters, but you are right, *I* was the one being sneery, and I'm sorry to Mudguard for that, as I totally have no problem with any naming conventions that anyone has, that's up to them, but I basically think that Mudguard's quote above is 100% wrong, and 100% unsupportable. I hope that the TextPad designer's fix this little problem when they get the chance, for those of us that use & all the time in filenames it will avoid a little confusion. But again, sorry Mudguard for being over the top in my comment ! All the best,

Roy.

@Bob: if you read my previous post again, you will see that the underscore IS included in my list.


@RoySubs:
"All other characters will give problems sooner or later."

This is my experience collected over many years of sharing files across various software and operating systems.

If your experience is different, that's nice. I have no problem with that.
But one sign that these characters will cause problems is this thread.

I never said you (or anyone else) should stick to my rules.
But consider the following:

Space, colon, semicolon and comma give problems when a list of file names is used (depending on the software, each of these characters might be used as separator).
% sign gives problems when the file name becomes part of an URL (as % starts an URL-escaped character) or with DOS commands (where % starts an environment variable name)
All characters with codes below 32 or above 127 give problems when moved to ASCII-based systems.
* and ? conflict with wildcard characters.
" and ' conflict with shell command quotes.
/ and \ conflict with folder separators.
| is the pipe symbol in unix-like command line interpreters
> and < conflict with the standard input/standard output redirection symbols in various command line interpreters
= might be misinterpreted as assignment operator in command line interpreters

and so on...

Yes, in most of the given cases there are workarounds like escaping the problematic characters, but the need for escaping is easily forgotten...
For me, these possible problems with characters in file names are reason enough to avoid them.

>> This is my experience collected over many years of sharing files across various software and operating systems.

I knew it ! As I said I thought your argument was for Unix reasons, and although 2 people said there was nothing Unix-like about your comment you make it clear with this and the stuff about shell commands comment ! Clearly a Unix related comment. Mudguard, totally, u use Unix a lot and that's great, I don't/can't be bothered with it when all my work is on Windows. I mean I do have Linux boxes in my network at home, but never ever had a need for a workaround or anything. I would also have found humour if you had said "I never use anything other than 8.3 format for compatibility with older systems. All other filename formats will give problems sooner or later" !!! Come on

About the characters that you mention below :

>>> Space, colon, semicolon and comma give problems when a list of file names is used (depending on the software, each of these characters might be used as separator).

Out of every program I use in Windows this is a virtual impossibility. i.e. unless you are using some unsupported 4+ year old versions of programs, all of all programs that I have ever used in the past 2 years has upgraded to the point where they use standard naming conventions.

All of the other characters that you mention except for %, ', and = are already restricted characters ! so are impossible to use.

Look, I have NOTHING against people who name all of their files with cryptic naming conventions such as RFPD8404.DOC rather than "Report For Project Deadlines 2004-04-08". Man, I'm *done* with all that rubbish, and yes, it really has increased and streamlined my life so much to have meaninglfull names including spaces etc. Before you say that you are not advocating 8.3 filenames (as you are a Unix user as is clear from the characters that you mentioned), that's cool, but still, I do NOT advocate that you use my long meaningfull name way of file folder naming. I know everyone likes to be an individual, but basically, I've blown away 90% of your character arguments (most are restricted characters in Windows as I point out and for spaces causing problems, I'd love to know a modern Windows program that is subject to this one !). Yes, your way is *safer*, maybe one time in 10,000 I might hit a minor problem, but hey, long filenames have probably saved me tens or hundreds of hours of head scratching over the years so that's a good trade-off ! (ok, ok, I work for big corporates such as Shell, Nestle, Abn Amro exclusively so I see Windows only in these massive companies, but for your Unix environements, your experience is good!). I guess it's like rock climbing and sky diving are more fun than the *safety* of staying at home and watching tv right ?? (but sorry for finding Unix-naming convention advocacy amusing ! no offence intended ! maybe we should go back to just using 0-9 for naming files 0013, 1049, 9843, and a text file index 0000 that describes the contents of each file ... hmm, this is a pretty good system i've got here, wonder if i can patent it ! :d) Sorry for the funning Mudguard, in all seriousness, more power to you and your Linux/Unix environments mate !

All the best,

Roy.

At the moment, I am using Windows mostly.

Command line interpreters are not limited to Unix, they exist under windows as well. (cmd.exe for example)

And % or = or ' are not forbidden by Windows - I just created a folder with %=' as name and a textfile %='.txt.

um ... i think you will see in my post above that I point out that %=' ARE allowed. I said that the others are not.

Anyway man, it's just a different viewpoint. I totally respect that you like to work that way. I do thousands of CMD scripts and VBS scripts and it's never really a problem. I totally know what you mean, it's a minor annoyance. Personally, I think you misunderstand me a little. I would love rigorous ways of enforcing things like this so that filenames and folder names could be totally unambiguous, but there isn't a standard here and never will be really. Standards are good, but ... longfilenames with spaces have enriched my documenting and organisation greatly. Maybe it's like Adam's Apple ... go on Mudguard ... try it ! you know how sometimes the first time you hear a new song you can think "that's rubbish!", but then after 3 or 4 listenings it starts to get under yer skin and you think "hmm, actually, there is something cool about this ...". The naming convention you've chosen is cool though. My way is to a always try the new things and to be totally honest, in the 5-10 years that I've done eveything with spaces in names, after the initial changeover period until programs understood long filenames, it's never really been a problem at all, and ... in fact, it has been a very useful tool. my opinion though ! if you stick to no spaces in any of your filenames for the next billion years then you will be perfectly justified in doing so !

um ... i think you will see in my post above that I point out that %=' ARE allowed. I said that the others are not.

Sorry, you are right in this case.
(might be easier for me if this discussion were in my native language...)