Operating system file name restrictions? Where?
Karsten Wutzke
Up-front:
Sorry for posting in so many newsgroups, but I didn't know where to ask,
especially with the Mac...
I'm writing a Java (hooray) application where I'm generating plain ASCII
files and I want the user to be able to choose whether s/he wants a
Unix, Windows Joliet, MS-DOS or Mac file to be generated (it will also
run on any of these platforms). It's not only about the carriage
returns, but also about which characters are forbidden in file names AND
how many characters long a file name and its extension can be at
maximum, e.g. for DOS it's 8.3. Luckily Windows tells me that when
creating an absolutely invalid filename, like /ง&%(ง%&)", the characters
\ / : * ? " < > and | are forbidden, but what's the maximum filename
length...? What about Linux or Unix in general? Don't they have
different file naming systems? What were they based on...Minix file
system? Don't remember... What about the Mac?
Can anyone explain WHY some characters are prohibited?
Thanks for your help! It is highly appreciated!
Karsten
--
Anti SPAM:
Remove 123 from email address to reply.
Entferne 123 von der Emailadresse, um zu antworten.
Dances With Crows
>files and I want the user to be able to choose whether s/he wants a
>Unix, Windows Joliet, MS-DOS or Mac file to be generated (it will also
>run on any of these platforms). It's not only about the carriage
>returns, but also about which characters are forbidden in file names AND
>how many characters long a file name and its extension can be at
>maximum, e.g. for DOS it's 8.3. Luckily Windows tells me that when
>creating an absolutely invalid filename, like /ง&%(ง%&)", the characters
>\ / : * ? " < > and | are forbidden, but what's the maximum filename
>length...? What about Linux or Unix in general? Don't they have
>different file naming systems? What were they based on...Minix file
>system? Don't remember... What about the Mac?
Unix filename conventions were created long before Minix existed. The
only character that's forbidden is "/" since that character is used as a
directory separator. Most Unices these days have a 255-character limit
on filenames. The pre-OS X Mac has a 32-character limit, and the
forbidden character is ":", again because it's a directory separator.
>Can anyone explain WHY some characters are prohibited?
Back around... oh, 1983, in Horribly Ancient Times</SARCASM>, people
interacted with their computers through the command line. Naturally,
they had to have some way of specifying "the file 'bar' in the directory
'foo' " on the command line. The Unix designers chose to use "foo/bar",
Apple chose to use "foo:bar", and Microsoft chose "foo\bar". Naturally,
you can't have a file named "b/ar" on a Unix machine, as a pathname like
"/me/b/ar" looks like "file ar in directory b in directory me" instead
of "file b/ar in directory me." They could have used a control
character as a directory separator, but those are harder to type and
most have no printable representation, making command-line editing more
difficult.
--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin / Those who do not understand Unix are
http://www.brainbench.com / condemned to reinvent it, poorly.
-----------------------------/ --Henry Spencer
Thomas Reed
Crows <mhgr...@umich.edu> wrote:
> The pre-OS X Mac has a 32-character limit, and the
> forbidden character is ":", again because it's a directory separator.
'.' is also discouraged on the Mac as the first character of filenames,
primarily (from what I understand) for historic reasons. There may or
may not still be reasons for this, but it's something to consider.
Claude
at
http://www.mactech.com/macintosh-c/classic-chap14-2.html
What's missing ??
if (!(EdiTextHandle = GetNewControl (128,window)))
ErrorHandler(kErrorStrNoCNTL) ;
ShowControl(EdiTextHandle);
SetControlData(EdiTextHandle,kControlNoPart,kControlEditTextTextTag,
initialAddr[0],(Ptr) &initialAddr[1]);
selectionRec.selStart = 0;
selectionRec.selEnd = 32767;
SetControlData(EdiTextHandle,kControlNoPart,kControlEditTextSelectionTag,
sizeof(selectionRec),(Ptr) &selectionRec);
In my EventLoop I have
IdleControls (window) ; Does IdleControls replace TEIdle ?
The box appears , the initialAddr string appears .
But no way to enter anything , or edit or nothing .
Not even the blinking insertion point caret ...
Thanks in adavance,
claudej
Karl B
> \ / : * ? " < > and | are forbidden,
> Can anyone explain WHY some characters are prohibited?
\ - Because DOS uses it as a "command" char.
/ - Because DOS uses it as a directiory seperator.
: - Because... because... ah, I give up.
* - Because DOS uses it as a wildcard
? - Because DOS uses it as a wildcard.
| - Because DOs uses it as a pipe command.
.... you get the idea...
--
Please don't cc or reply via email! (My news service works fine!)
See message headers for Geek Code.
<-- Guvf fcnpr sbe erag --> | ASCII White Ribbon (x)
http://welcome.to/KalleBoo/ | Campaign / \
Mark T
<karsten...@starconcept.com> wrote:
Newsgroups were trimmed to the relevent Macintosh groups.
[snip]
Asking about what are the restrictions on Macintosh filenames.
> What about the Mac?
Karsten, you have to read a couple of documents. Try
http://developer.apple.com/techpubs/mac/Files/Files-86.html#HEADING86-0
and
http://developer.apple.com/technotes/tn/tn1041.html
These URL's list all of the naming restrictions in the Mac file system.
HTH,
-mark
--
--
-mark
Eric Albert
mhgr...@umich.edu wrote:
> Unix filename conventions were created long before Minix existed. The
> only character that's forbidden is "/" since that character is used as a
> directory separator. Most Unices these days have a 255-character limit
> on filenames. The pre-OS X Mac has a 32-character limit, and the
> forbidden character is ":", again because it's a directory separator.
It's actually a 31-character limit, except on HFS+ volumes under Mac OS
9 and later, where you get a 255-character limit if you use new APIs to
write those files. Java automatically supports those APIs for you if
you're using MRJ 2.2 or later.
-Eric
--
Eric Albert ejal...@stanford.edu
http://www.stanford.edu/~ejalbert/
Johan Kullstam
> On Wed, 23 Aug 2000 15:11:23 +0200, Karsten Wutzke wrote:
> >files and I want the user to be able to choose whether s/he wants a
> >Unix, Windows Joliet, MS-DOS or Mac file to be generated (it will also
> >run on any of these platforms). It's not only about the carriage
> >returns, but also about which characters are forbidden in file names AND
> >how many characters long a file name and its extension can be at
> >maximum, e.g. for DOS it's 8.3. Luckily Windows tells me that when
> >creating an absolutely invalid filename, like /ง&%(ง%&)", the characters
> >\ / : * ? " < > and | are forbidden, but what's the maximum filename
> >length...? What about Linux or Unix in general? Don't they have
> >different file naming systems? What were they based on...Minix file
> >system? Don't remember... What about the Mac?
>
> Unix filename conventions were created long before Minix existed. The
> only character that's forbidden is "/" since that character is used as a
> directory separator.
\0 is also forbidden since that's end of string and would cause no end
of trouble in its handling under unix. everything else, even control
chars, is ok (but can cause some weird interactions with your display,
various userland programs &c).
unix used to have a 14 char limit. this might be important if you
have to deal with stuff over ten years old.
> Most Unices these days have a 255-character limit
> on filenames. The pre-OS X Mac has a 32-character limit, and the
> forbidden character is ":", again because it's a directory
> separator.
while it's not forbidden, : can give problems in unix too since it's
commonly used as a name separator. e.g., in bash
$ PATH=/bin:/usr/bin
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
sysengr
Karsten Wutzke
Karl B wrote:
> Karsten Wutzke <123karst...@starconcept.com> wrote:
>
> > \ / : * ? " < > and | are forbidden,
> > Can anyone explain WHY some characters are prohibited?
>
> \ - Because DOS uses it as a "command" char.
> / - Because DOS uses it as a directiory seperator.
You mean the other way around...
What's a command... character?
What about < and >, the smaller than and greater than characters?
Greg Weston
<thoma...@earthlink.net> wrote:
> In article <slrn8q7ptt....@fleabag.nullhouse.org>, Dances With
> Crows <mhgr...@umich.edu> wrote:
>
> > The pre-OS X Mac has a 32-character limit, and the
> > forbidden character is ":", again because it's a directory separator.
>
> '.' is also discouraged on the Mac as the first character of filenames,
> primarily (from what I understand) for historic reasons. There may or
> may not still be reasons for this, but it's something to consider.
It's because that's the convention for driver names. Naming a file with
a period at the start isn't inherently a problem. Naming a file ".Sony"
is (or at least was) a recipe for disaster.
G
Thomas Reed
the "To," "Cc," and "Newsgroups" headers for details. ]]
In article <b7So5.6067$SH3.1...@wagner.videotron.net>, Claude
<cla...@videotron.ca> wrote:
> But no way to enter anything , or edit or nothing .
>
> Not even the blinking insertion point caret ...
Well, you're going to have to manage a lot of things that dialogs do
for you. For example, if a field is "active" (ie, there's a flashing
cursor in it) your event loop must watch for key presses and insert the
character in that field. You'll also have to have some way to track
which field is active and what the tab order is (not to mention
implementing tabbing yourself). You'll probably have to make the caret
blink yourself by calling TEIdle for the appropriate field.
If you can do it with a dialog, do so. You can make a dialog behave a
lot like a window by making it movable and non-modal, but by using a
combo of IsDialogEvent and DialogSelect in your event loop where
appropriate, you get all this stuff handled for you. Believe me, it's
much easier that way if you can possibly do that.
Karl B
> > The pre-OS X Mac has a 32-character limit, and the
> > forbidden character is ":", again because it's a directory separator.
>
> '.' is also discouraged on the Mac as the first character of filenames,
> primarily (from what I understand) for historic reasons. There may or
> may not still be reasons for this, but it's something to consider.
The drivers internal names are (for example) ".Sony" for the floppy
drive.
You can get a complete list of them using the "drvr" MacsBug command.
Karl B
> > > Can anyone explain WHY some characters are prohibited?
> >
> > \ - Because DOS uses it as a "command" char.
> > / - Because DOS uses it as a directiory seperator.
>
> You mean the other way around...
>
> What's a command... character?
>
> What about < and >, the smaller than and greater than characters?
Actually I'm a Mac person, so I'm not so completely secure with DOS and
PCs.
Actually, with "command" char, I really ment "argument" char.
George Jefferson
:while it's not forbidden, : can give problems in unix too since it's
:commonly used as a name separator. e.g., in bash
:$ PATH=/bin:/usr/bin
theres the rub with unix, you can put all kinds of funky stuff
on the file system, but you will break all kinds of applications
with strange characters, including very basic stuff like mv,rm,ls.
I'd stick with printable ascii and prohibit all those same wildcards
as makes DOS choke, plus a few more like space~?[]{}()'"`|
--
george jefferson : geo...@sol1.lrsm.upenn.edu
to reply simply press "r"
-- I hate editing addresses more than I hate the spam!
George Jefferson
:What about < and >, the smaller than and greater than characters?
> is output redirection, (DOS and most unix), as in "TYPE FILE > PRN"
the left < redirects input similarly under unix, but i dont know about DOS.
David C.
>
> I'm writing a Java (hooray) application where I'm generating plain
> wants a Unix, Windows Joliet, MS-DOS or Mac file to be generated (it
> will also run on any of these platforms). It's not only about the
> carriage returns, but also about which characters are forbidden in
> file names AND how many characters long a file name and its extension
> can be at maximum, e.g. for DOS it's 8.3.
Yep. Even with cross-platform tools, like Java, your application still
must know things about the target operating systems. True universal
portability will probably never happen (unless everybody ends up using
the same OS, which also will never happen.)
> Luckily Windows tells me that when creating an absolutely invalid
> filename, like /ง&%(ง%&)", the characters \ / : * ? " < > and | are
> forbidden, but what's the maximum filename length...?
If your disk volume is formatted FAT (pre-Win95 standard), then your
filenames are limited to 8.3 (8 character name, plus three character
extension). All characters are stored as upper-case only.
If your disk volume is vFAT (the Win9x extension on FAT), then your
filenames can be any length up to 255 characters. But there's a catch.
The full path from root to the filename (like C:\DIR\DIR\DIR\FILE.EXT)
can't be longer than 255 characters either. So, as you descend lower
into directories, your actual filename limit becomes greater.
Also note that vFAT is not very efficient when it stores long names. In
order to remain compatible with FAT, it doesn't change the directory
entry structure. It stores long names by using up multiple adjacent 8.3
directory entries (setting a bit so that older operating systems will
ignore them). Since the root directory of a vFAT volume has a fixed
number of entries, a small number of files with very long names can fill
it. IMO, It is best to keep filenames in the root directory as short as
possible.
As for the reserved characters:
\ and / are directory-separator characters. (Yes, I know that
only "\" works from the command line, but both work if
you pass them to system calls.)
: is used to delimit device names. Like disk drives (C:) or
other devices (like LPT1:)
* and ? are wildcard characters. Programs can actually use
these in filenames, but they really shouldn't. The
resulting names are difficult or impossible to access
from the command-line, because they get interpreted as
wildcard characters.
<, > and | are I/O redirection characters. Again, you can use
them in system calls, but you shouldn't use them,
because it will cause confusion at the command line.
> What about Linux or Unix in general? Don't they have different file
> naming systems? What were they based on...Minix file system?
UNIX systems can have many different kinds of file systems. Some
systems impose stricter limits than others. (For instance, if you mount
a FAT volume, you have the MS-DOS 8.3 limit, and you get the Win9x limit
if you mount a vFAT volume.)
Older UNIX file systems have a 15-character filename limit. Newer
systems have a 255-character limit. Some even have a 64K limit
(although why anyone would need a filename longer than 255 characters is
beyond me.)
On UNIX systems, the only character that's actually forbidden is the /
(forward slash) character. It is a directory separator. While other
characters are used by the shell (command-line) for various purposes
(like wildcards and redirection), they can always be "escaped" (prefixed
with a backslash char) or "quoted" (surrounded by single-quotes) to
prevent the shell from interpreting them - thus passing them on to a
program, which may use it as a filename. Still, using characters like
these ( \ ? [ ] | < > * & ! ( ) $ # and space ) may confuse some users,
who may be unaware of how to type them in properly.
Also note that on UNIX, filenames beginning with a dot are "hidden".
They don't show up in directory listings unless the user explicitly asks
for them
Finally, note that case is sensitive on UNIX file systems. That is
"file" and "FILE" (and even "fILe" and "filE" and "fiLe") all refer to
different files. Other operating systems (including DOS, Windows, OS/2
and MacOS) do not act this way - for them, two names that differ only in
case will refer to the same file.
> Don't remember... What about the Mac?
MacOS filenames have a 35-char limit on the original HFS file system.
The newer HFS+ file system has a much lager limit (255 chars, I think),
but not all applications can handle this, so keeping the names short may
be a good idea for now.
The colon (:) is a reserved char - used as a directory separator when
text representations of path names are generated.
Names shouldn't be start with a period (.) either - for reasons that
Greg already posted. They will conflict with device names.
-- David
David C.
>
>: while it's not forbidden, : can give problems in unix too since it's
>: commonly used as a name separator. e.g., in bash
>: $ PATH=/bin:/usr/bin
>
> theres the rub with unix, you can put all kinds of funky stuff on the
> file system, but you will break all kinds of applications with strange
> characters, including very basic stuff like mv,rm,ls. I'd stick with
> printable ascii and prohibit all those same wildcards as makes DOS
> choke, plus a few more like space~?[]{}()'"`|
On UNIX, you can use anything but the directory separator (/) in a
filename. But many of those characters are interpreted by the shell, or
by application programs. Which may cause unexpected problems. Still,
most well-written programs (like most of the shells) do provide a means
to get around this - usually by quoting or escaping the special
characters.
For instance, the filename:
foo<>bar
would be typed in as either:
'foo<>bar'
or foo\<\>bar
etc.
-- David
Johan Kullstam
> geo...@sol1.lrsm.upenn.edu ( George Jefferson ) writes:
> >
> >: while it's not forbidden, : can give problems in unix too since it's
> >: commonly used as a name separator. e.g., in bash
> >: $ PATH=/bin:/usr/bin
> >
> > theres the rub with unix, you can put all kinds of funky stuff on the
> > file system, but you will break all kinds of applications with strange
> > characters, including very basic stuff like mv,rm,ls. I'd stick with
> > printable ascii and prohibit all those same wildcards as makes DOS
> > choke, plus a few more like space~?[]{}()'"`|
>
> On UNIX, you can use anything but the directory separator (/)
you cannot use the null char \0 either. i just got done saying that
but someone chopped it out. that makes *two* chars you can't have in
a filename -- / and \0.
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
Greg Weston
<123karst...@starconcept.com> wrote:
> Karl B wrote:
>
> What about < and >, the smaller than and greater than characters?
< and > ("suck" and "blow" are my favorite names for them) are the
stream redirection characters.
The command
C:\> somecmd < input.txt > output.txt
will process the contents input.txt with somecmd and spit the results
to output.txt, and the only requirements on somecmd.exe are that it
read from stdin/cin and writes to stdout/cout.
G
Greg Weston
the "To," "Cc," and "Newsgroups" headers for details. ]]
Hi, Dave.
In article <uk8d7b...@qqqq.invalid>, David C. <sham...@usa.net>
wrote:
> Older UNIX file systems have a 15-character filename limit. Newer
> systems have a 255-character limit. Some even have a 64K limit
> (although why anyone would need a filename longer than 255 characters is
> beyond me.)
Aw, rats. The IIgs had 8k filenames and I thought that was the winner.
> MacOS filenames have a 35-char limit on the original HFS file system.
31, actually, with a 27-character limit for volume names.
G
David C.
>>
>> On UNIX, you can use anything but the directory separator (/)
>
> you cannot use the null char \0 either. i just got done saying that
> but someone chopped it out. that makes *two* chars you can't have in
> a filename -- / and \0.
Well, yes.
I didn't think I had to be that pedantic. Do you know of anybody who
wanted to try and create a file with a NULL in the name?
BTW, the directory-entry structure (struct dirent) used on most UNIX
platforms uses a counted-string (not a NULL-terminated one). So the
file system can handle such a name. Of course, 99.999% of software for
UNIX, including the OS itself, uses NULL-terminated strings for
filenames, so you'd never be able to access such a file if you could
manage to put one on the disk.
-- David
Johan Kullstam
> Johan Kullstam <kull...@ne.mediaone.net> writes:
> >>
> >> On UNIX, you can use anything but the directory separator (/)
> >
> > you cannot use the null char \0 either. i just got done saying that
> > but someone chopped it out. that makes *two* chars you can't have in
> > a filename -- / and \0.
>
> Well, yes.
>
> I didn't think I had to be that pedantic. Do you know of anybody who
> wanted to try and create a file with a NULL in the name?
i dunno, the same idiot who would name his file backspace "\8"?
> BTW, the directory-entry structure (struct dirent) used on most UNIX
> platforms uses a counted-string (not a NULL-terminated one).
and they used to be in a fixed 14 char field which for shorter
filenames was terminated early by \0. furthermore, there has never
been a reason for excluding / in the directory entries themselves
except that nothing would work properly. this is the same argument
against \0.
> So the
> file system can handle such a name.
modern ones, yes.
> Of course, 99.999% of software for
> UNIX, including the OS itself, uses NULL-terminated strings for
> filenames, so you'd never be able to access such a file if you could
> manage to put one on the disk.
i think open(2) pretty much requires null terminated strings.
Mark Day
<gwesto...@CAPShome.com> wrote:
> In article <uk8d7b...@qqqq.invalid>, David C. <sham...@usa.net>
> wrote:
>
> > Older UNIX file systems have a 15-character filename limit. Newer
> > systems have a 255-character limit. Some even have a 64K limit
> > (although why anyone would need a filename longer than 255 characters is
> > beyond me.)
>
> Aw, rats. The IIgs had 8k filenames and I thought that was the winner.
That limit was for *path* names. ProDOS, the primary volume format,
had a limit of 15 characters, starting with an uppercase letter,
containing uppercase letters, digits and dots. Later updates used
separate bits to allow letters to be displayed as lower case and the
dot to be displayed as a space.
> > MacOS filenames have a 35-char limit on the original HFS file system.
>
> 31, actually, with a 27-character limit for volume names.
For the truly anal retentive, those are *byte*, not character limits.
Many script systems use two bytes per character, so the limit becomes
15 and 13 *characters*, respectively.
In article <uk8d7b...@qqqq.invalid>, David C. <sham...@usa.net>
wrote:
> The newer HFS+ file system has a much lager limit (255 chars, I think),
Correct. And this time, it's 255 16-bit Unicode characters (for a
total of 512 bytes if you include the 16-bit length field used on
disk).
> but not all applications can handle this, so keeping the names short may
> be a good idea for now.
Applications using the HFS Plus APIs introduced in Mac OS 9.0 can
certainly handle the long names.
Applications using the older APIs (eg., PBGetCatInfo) get back what we
call a "mangled" name that has been truncated in a special way. That
"mangled" name can be passed back into the File Manager to use the
file. So using longer names is more of a user interface issue (since
Finder displays the shorter "mangled" names). Using longer names won't
cause crashes.
> The colon (:) is a reserved char - used as a directory separator when
> text representations of path names are generated.
Not if you're using the HFS Plus APIs; any valid Unicode 2.0 character
is acceptable. Though Mac OS 8.1 has a bug that will prevent you from
accessing the file if it's name contains a colon.
> Do you know of anybody who
> wanted to try and create a file with a NULL in the name?
A prominent Mac software developer does...
-Mark
John Thompson
> I'm writing a Java (hooray) application where I'm generating plain ASCII
> files and I want the user to be able to choose whether s/he wants a
> Unix, Windows Joliet, MS-DOS or Mac file to be generated (it will also
> run on any of these platforms). It's not only about the carriage
> returns, but also about which characters are forbidden in file names AND
> how many characters long a file name and its extension can be at
> maximum, e.g. for DOS it's 8.3. Luckily Windows tells me that when
> creating an absolutely invalid filename, like /§&%(§%&)", the characters
> \ / : * ? " < > and | are forbidden, but what's the maximum filename
> length...? What about Linux or Unix in general? Don't they have
> different file naming systems? What were they based on...Minix file
> system? Don't remember... What about the Mac?
>
> Can anyone explain WHY some characters are prohibited?
Some characters should not be used in filesnames because they may
have a more general meaning as directory or command separators,
piping directives, or even terminal control characters.
--
-John (John.T...@attglobal.net)
Karsten Wutzke
another "let's see if someone knows this and takes the time to tell me
something about it" mail. I was wrong... GOOD! I cannot say how much I thank
you... I'll use this new-won knowledge for my code generator which will
appear at www.glexport.de hopefully at the end of the year, so you guys know
this had a REAL purpose...
Again: Thanks to y'all! And keep on...
Karsten
PS: Braindead, I have to work through all this... :-)
Steven Yap
> Karsten Wutzke <123karst...@starconcept.com> wrote:
>
> > \ / : * ? " < > and | are forbidden,
> > Can anyone explain WHY some characters are prohibited?
>
> : - Because... because... ah, I give up.
DOS use the : character as part of the special names like PRN:, LPT1:,
and COM1:. In NT and W2K, the : character is also used to indicate
the stream to read/write from. For example, "type bar:foo" would
print out the contents of the stream named foo in the file bar.
--
Steven
Villy Kruse
Johan Kullstam <kull...@ne.mediaone.net> wrote:
>
>and they used to be in a fixed 14 char field which for shorter
>filenames was terminated early by \0. furthermore, there has never
>been a reason for excluding / in the directory entries themselves
>except that nothing would work properly. this is the same argument
>against \0.
>
Also, remember that the file name passed to the open system call is
terminated by \0. This in itself makes it impossible to have a \0
character in the middle of a file path name; or if you could you would
not be able to open it, and that is not much fun.
Villy
Lord Apollyon
> '.' is also discouraged on the Mac as the first character of filenames,
> primarily (from what I understand) for historic reasons. There may or
> may not still be reasons for this, but it's something to consider.
Drivers are named thusly. The old Open() behaviour would try to Open a
driver named that name and if you were horribly unlucky to have a file
named after a ROM-based driver like, oh, say, .Sony, etc.... you'd
definitely get interesting results.
:)
Hence why the recommendation to use OpenDF() etc. That call will never
use the DriverOpen() code.
=R=
--
The reply-to-address is *REAL* and will expire on 0:01 1-October-2000.
Spammers: You will lose your network access. Guaranteed.
134 domains, 439 web-accounts, and 687 dialup ISP accounts flushed.
George Jefferson
:
:touch somecmd\ \<\ input.txt\ \>\ output.txt
:
:It might actually create a file called:
: "somecmd < input.txt > output.txt"
then post a note to alt.unix asking how to get rid of it <g>
China Black & Blue
/ :
/ :touch somecmd\ \<\ input.txt\ \>\ output.txt
/ :
/ :It might actually create a file called:
/ : "somecmd < input.txt > output.txt"
/
/ then post a note to alt.unix asking how to get rid of it <g>
rm "./somecmd*"
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Sign up for WASHINGTON MUTUAL BANK's special
We Rob You While You Sleep Service TODAY!
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
CACS: Collective Against Consensual Sanity v0.123
Now a text site map http://www.tsoft.com/~wyrmwif/cacs/
pretty? http://www.geocities.com/SoHo/Studios/5079/
:)-free zone. Elect LUM World Dictator!
Garry Knight
>the left < redirects input similarly under unix, but i dont know about DOS.
It does the same thing in DOS.
--
Garry Knight
garry...@bigfoot.com
Michael Thibault
>For the truly anal retentive
That should be "anally retentive", of course. ;)
nospam...@ualberta.ca
Or perhaps "true anal retentive"
or should it be "more true anal retentive"?
Lew Pitcher
>
> In article <230820001820295772%gwesto...@CAPShome.com>, Greg
> Weston <gwesto...@CAPShome.com> wrote:
>
> > > What about < and >, the smaller than and greater than characters?
> >
> > < and > ("suck" and "blow" are my favorite names for them) are the
> > stream redirection characters.
> >
> > The command
> >
> > C:\> somecmd < input.txt > output.txt
>
>
> touch somecmd\ \<\ input.txt\ \>\ output.txt
>
~/temp $ ls -la
total 3
drwxr-xr-x 2 lpitcher users 1024 Aug 24 14:25 .
drwxr-xr-x 34 lpitcher users 2048 Aug 24 14:24 ..
~/temp $ touch "somecommand <input >output"
~/temp $ ls -la
total 3
drwxr-xr-x 2 lpitcher users 1024 Aug 24 14:25 .
drwxr-xr-x 34 lpitcher users 2048 Aug 24 14:24 ..
-rw-r--r-- 1 lpitcher users 0 Aug 24 14:25 somecommand
<input >output
~/temp $
> --
> Help! I'm being held in a .sig factory.
--
Lew Pitcher
Master Codewright and JOAT-in-training
Garry Knight
>Karsten Wutzke wrote:
>
>> Can anyone explain WHY some characters are prohibited?
>
>have a more general meaning as directory or command separators,
>piping directives, or even terminal control characters.
That doesn't stop some software using them. For example, the krn
news client, names spooled articles ready for upload with names
like <0008250026...@me.here>
--
Garry Knight
garry...@bigfoot.com
Karl B
> Also, remember that the file name passed to the open system call is
> terminated by \0. This in itself makes it impossible to have a \0
> character in the middle of a file path name; or if you could you would
> not be able to open it, and that is not much fun.
The most annyoying thing ofcourse is the file I renamed to an empty
string. Thus, the file has no name.
David C.
>
> well, try:
>
> touch somecmd\ \<\ input.txt\ \>\ output.txt
>
> It might actually create a file called:
> "somecmd < input.txt > output.txt"
On UNIX, it definitely will work. And when your shell performs wildcard
expansion, and that name gets matched, all hell will break loose.
For example, if you would then type:
cat some*
the actual command line processed would be:
cat somecmd < input.txt > output.txt
It would fail to find the files somecmd and input.txt (unless they also
exist), and would write to output.txt.
There are some much worse things you can do with filenames, but I won't
post them here, in case someone decides to try it out and accidentally
wipes out his entire home directory trying to figure out how to delete
the file he just created.
-- David
David C.
>>
>> Of course, 99.999% of software for UNIX, including the OS itself,
>> uses NULL-terminated strings for filenames, so you'd never be able to
>> access such a file if you could manage to put one on the disk.
>
> i think open(2) pretty much requires null terminated strings.
So does creat(2).
However, directories are just files on UNIX.
You can open a directory as a file, read its contents, change them, and
write it back out. If you do this, you can rename any file to anything.
And possibly make that file completely inaccessible as well.
UNIX is definitely the system of "give the user enough rope for him to
hang himself."
-- David
Jon Guyer
wrote:
> UNIX is definitely the system of "give the user enough rope for him to
> hang himself."
... and put it around his neck and cinch it up real tight in case he
doesn't know how to do it himself...
--
Jonathan E. Guyer
NF Stevens
>Keep it to Usenet please <idontre...@hotmail.com> writes:
>>
>> well, try:
>>
>> touch somecmd\ \<\ input.txt\ \>\ output.txt
>>
>> It might actually create a file called:
>> "somecmd < input.txt > output.txt"
>
>On UNIX, it definitely will work. And when your shell performs wildcard
>expansion, and that name gets matched, all hell will break loose.
>
>For example, if you would then type:
>
> cat some*
>
>the actual command line processed would be:
>
> cat somecmd < input.txt > output.txt
>
>It would fail to find the files somecmd and input.txt (unless they also
>exist), and would write to output.txt.
Since the shell interprets redirections before
expanding wildcards what happens is that cat
gets executed with one parameter, the string
"somecmd < input.txt > output.txt" which it
attemps to process.
Norman
Eric Albert
wrote:
> In article <ejalbert-901B84...@nntp.stanford.edu>, Eric
> Albert <ejal...@stanford.edu> wrote:
>
> > It's actually a 31-character limit, except on HFS+ volumes under Mac OS
> > 9 and later, where you get a 255-character limit if you use new APIs to
> > write those files. Java automatically supports those APIs for you if
> > you're using MRJ 2.2 or later.
> The MacOS Doens't so they need to be in a .jar file... I believe..
Not quite. As I said, on HFS+-formatted volumes, on Mac OS 9 and later,
you can create and access files using 255-character names *if* you use a
new API. See
<http://developer.apple.com/techpubs/macos8/pdf/FileManger.pdf> for
details.
Java applications run under MRJ 2.2 or later automatically use the new
API. Few other applications have adopted the new API to date, the most
noticeable one which hasn't being the Finder.
-Eric
--
Eric Albert ejal...@stanford.edu
http://www.stanford.edu/~ejalbert/
Andrew
<123karst...@starconcept.com> wrote:
> I'm writing a Java (hooray) application where I'm generating plain ASCII
> files and I want the user to be able to choose whether s/he wants a
> Unix, Windows Joliet, MS-DOS or Mac file to be generated (it will also
> run on any of these platforms). It's not only about the carriage
> returns, but also about which characters are forbidden in file names AND
> how many characters long a file name and its extension can be at
> maximum, e.g. for DOS it's 8.3. Luckily Windows tells me that when
> creating an absolutely invalid filename, like /ง&%(ง%&)", the characters
> \ / : * ? " < > and | are forbidden, but what's the maximum filename
> length...? What about Linux or Unix in general? Don't they have
> different file naming systems? What were they based on...Minix file
> system? Don't remember... What about the Mac?
>
> Can anyone explain WHY some characters are prohibited?
Windows I think nit's 255..
mac it's 31 and the only thing you can't use is the ':'.. of course, if
you do use the ':' the Mac will convert it to a '-' without even an
error message.
The : is used as a path seperator on the mac instead of say the '/'..
although in Mac experience wiht Mac Java you can alsu use the '/' to
dilimanate paths.. it makes dealing with files that have '/' in their
names really confusing..
Andrew
> > The pre-OS X Mac has a 32-character limit, and the
> > forbidden character is ":", again because it's a directory separator.
>
> '.' is also discouraged on the Mac as the first character of filenames,
> primarily (from what I understand) for historic reasons. There may or
> may not still be reasons for this, but it's something to consider.
'.' as the FIRST CHARTACTER in a name.. like .foo is not a great idea..
The ONLY reasone to do this is because in UNIX, files that begin with .
are special files.. Programs ported from unix to the mac might have
problems.. also earlu (really early) version of the mac sometimes had
special files that sarted with a "." like the .sony floppy disk driver.
I've only seen two program in my life that had problems with
.filenames.. one was Zterm, the other I can't recall.. But It was a
really crappy piece of shareware...
Andrew
> It's actually a 31-character limit, except on HFS+ volumes under Mac OS
> 9 and later, where you get a 255-character limit if you use new APIs to
> write those files. Java automatically supports those APIs for you if
> you're using MRJ 2.2 or later.
The MacOS Doens't so they need to be in a .jar file... I believe...
Dances With Crows
Add "MS-DOS, and Win9x/NT" to that list of programs that have problems
with filenames that start with a ".". At least if you mount a Unix home
directory via Samba, all the files that begin with . will show up in
directory listings, but attempting to open them in Notepad/Wordpad/
whatever coughs up an error. Haven't tried this under 2K.
--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin / Those who do not understand Unix are
http://www.brainbench.com / condemned to reinvent it, poorly.
-----------------------------/ --Henry Spencer
M. Uli Kusterer
>In article <39A3CD7B...@starconcept.com>, Karsten Wutzke
><123karst...@starconcept.com> wrote:
>
>> I'm writing a Java (hooray) application where I'm generating plain ASCII
>> files and I want the user to be able to choose whether s/he wants a
>> Unix, Windows Joliet, MS-DOS or Mac file to be generated (it will also
>> run on any of these platforms). It's not only about the carriage
>> returns, but also about which characters are forbidden in file names AND
>> how many characters long a file name and its extension can be at
>> maximum, e.g. for DOS it's 8.3. Luckily Windows tells me that when
>> creating an absolutely invalid filename, like /ง&%(ง%&)", the characters
>> \ / : * ? " < > and | are forbidden, but what's the maximum filename
>> length...? What about Linux or Unix in general? Don't they have
>> different file naming systems? What were they based on...Minix file
>> system? Don't remember... What about the Mac?
>>
>> Can anyone explain WHY some characters are prohibited?
Hi,
the limit on the Mac is 31 characters for HFS volumes, and 255 for HFS+
volumes, but you need to use the new FSRef stuff to access files then (not
sure how that is done in Java, maybe it happens automatically with newer
runtimes, maybe not). Since the Mac uses the colon (":") to delimit path
names, you also can't use these characters or they will be interpreted as
a file path or partial pathname. If you start your filename with a period
("."), you can get into trouble on older MacOSs, as there the call to open
files used a period at a file name's beginning to indicate you wanted to
open a driver, not a file. The newer API calls don't have this problem,
though.
--
Cheers,
M. Uli Kusterer
----------------------------------------------------------------------
'The Witnesses of TeachText are everywhere...'
http://www.weblayout.com/witness
I do not wish to receive any bulk or unsolicited e-mail.
Claude
myStart = 0x7fffffff ;
tmt.tmWakeUp = 0L ;
tmt.tmReserved = 0L ;
tmt.tmAddr = 0L ;
InsXTime((QElem *)&tmt) ;
PrimeTime((QElem *)&tmt, -myStart) ; // Start the clock
>> Time-consuming process to be mesured
RmvTime((QElem *)&tmt) ; // Stop the clock
*wait_time = myStart + tmt.tmCount ;
If the process >= 1 millisecond perfect
If the process < 1 millisecond when I call RmvTime the tmt.tmCount
is at 0 (Zero) !! Why ?
Thanks ,
claudej