Methods to handle filename extensions?

[gmtonyhoyt]

Now you are getting somewhere. Does the char set apply to paths,
and what constitutes a path? Does the presense of a '\' or '/'
define the system and thus the path portions? How, if at all, is a
MsDos disk identifier to be translated to or from?

The character set requirements do not apply towards paths. What is
path is dependant on the operating enviorment. For unix
(solaris/linux) it's everything before the last / if one exists. In
the MS standard (windows/dos) it's everything before the last \ if one
exists. All else, it's the complete length of the string. Now, how
exactly you define what is a unix enviorment, and what's a ms standard
one, is not always easy to determine. So I'm kind of purposefully
leaving it vauge here since I myself am not sure how best to interpret
this.

Now MsDos, as mentioned before and if correct, may normaly allow file
specifications such as "A:myFile.ct". Well that's fine but I think for
now, I want to enforce that the \ has to exist. Hence, the above will
be suitablely declared an invalid path in my application, only because
it's not a necessary detail that may add additional complexity to
what's intended to be a simple application.

As for example vi breaking my second requirement, I should then add
an additional note to rule two and that is, "if the file ends
exclusively in a period, that period will be striped before the final
'.out' extension is applied." or something that explains my intention
really. Any file that does not end with '.ct' plainly just gets '.out'
tacked on the end, while files ending with a '.' also get it replaced
with '.out' as if it where a '.ct' instead. A filename consisting of
just a '.' are not valid. And no wild card characters, but I think
that's covered in the third rule.

Sorry for the snotty last statement, I just didn't realize how
complicated this really needed to be. Again, all I was asking was, is
there really a way to just change a filenames extension in a unix/dos
enviorment. It didn't need to be complex, I wasn't sure if it wasn't
something obvious and done before and I just needed pointing to in the
right direction.

Tony

 

[Anonymous 7843]

The character set requirements do not apply towards paths. What is
path is dependant on the operating enviorment. For unix
(solaris/linux) it's everything before the last / if one exists.

Some unixes allow extra slashes. "/usr/bin/vi/ .profile///"
behaves oddly but doesn't really fail on my solaris 9 box.
Whoever wrote that part of vi has made the same incorrect
assumption you did.

 

[Keith Thompson]

On Thu, 16 Jun 2005 05:52:31 +0000, Keith Thompson wrote:

...



Under Windows I would expect it to have a base filename of ef with no
extension.

You're right.

 

[Keith Thompson]

Some unixes allow extra slashes. "/usr/bin/vi/ .profile///"
behaves oddly but doesn't really fail on my solaris 9 box.
Whoever wrote that part of vi has made the same incorrect
assumption you did.

Right. On Solaris, for some reason, any file name can have one or
more '/' characters appended to it (and of course any internal '/' can
be replaced with multiple '/'s, but that probably doesn't affect what
you're doing). On Linux, '/'s can be appended to a directory name but
not to a file name (which IMHO makes a lot more sense).

 

[goose]

Gordon Burditt wrote:

gunzip, or you could feed it to tar with the z option. On the
other hand, .tar.bz2 should be fed to bunzip2, and as far as I
know, there is *NO* option to tar to directly unpack a .tar.bz2
file.

<OT>
-j with the GNU tar works for me

<snipped>

Slightly less off-topic, the OP might be better off
/guessing/ the file; most files are guessable from the
first dozen or so bytes. Just about every application
signs the binary output files so that they can determine
the version.

later,
goose

 

[goose]

Keith Thompson wrote:

<OT>
Yes, there is (at least in recent versions of GNU tar).
</OT>

To add to the confusion, compressed tar files are common called
"foo.tgz" rather than "foo.tar.gz".

<OT>
This is, IIRC, because slackware uses an installation method
which uses gzipped-compressed tar archives; the slackware
files are then .tgz, with a .txt (or perhaps .asc?) file
that the installation program processes.

I've no idea when the convention of .tgz became more, uhh,
conventional than .tar.gz

goose

 

[Jean-Claude Arbaut]

Le 16/06/2005 23:03, dans [email protected], « goose »

Gordon Burditt wrote:



<OT>
-j with the GNU tar works for me

<snipped>

Slightly less off-topic, the OP might be better off
/guessing/ the file; most files are guessable from the
first dozen or so bytes. Just about every application
signs the binary output files so that they can determine
the version.

It's a good method, but can lead to strange behaviour:
write "GIF89ablablabla" to a file, then the "file" command
yields "GIF image data, version 89a, 27746 x 25185".
I would not *trust* this approach, even though it's very
unlikely to cause problems in practice.

 

[Mark McIntyre]

On Wed, 15 Jun 2005 20:58:54 -0000, in comp.lang.c ,

First, you need to define what a file extension is.
This isn't necessarily easy. First try at it:

1. The file extension is the part of the file/path name between
the last period and the end of the file name.

so on VMS, does that include the file version?
dra0:[0000.bar.foo]foo.bar;37

I'm sure someone is going to come up with some special cases I've
forgotten.

I suspect mainframes will be special cases too...