By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,713 Members | 1,243 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,713 IT Pros & Developers. It's quick & easy.

Methods to handle filename extensions?

P: n/a
I need assistance coming up with a clean way to handle filename
extensions with my application.

While I can come up with several ways of doing so on my own, I felt
perhaps it would be worth asking here to see what more effective or
accepted methods for doing would be presented.

The issue is this. My application accepts files names, intended for
a cross platform unix and windows environment, from the command line.
So the application may get a file name '/home/joe/myExample.ct',
'C:\Work\myExample.ct' or more generically 'myExample.ct' My
application is to convert the data in the .ct file, into something new,
then enter the data into a file in the local directory the application
was executed named 'myExample.out'.

Is their a simplified way to handle this problem?

Tony

Nov 14 '05 #1
Share this Question
Share on Google+
27 Replies


P: n/a


gm********@yahoo.com wrote:
I need assistance coming up with a clean way to handle filename
extensions with my application.

While I can come up with several ways of doing so on my own, I felt
perhaps it would be worth asking here to see what more effective or
accepted methods for doing would be presented.

The issue is this. My application accepts files names, intended for
a cross platform unix and windows environment, from the command line.
So the application may get a file name '/home/joe/myExample.ct',
'C:\Work\myExample.ct' or more generically 'myExample.ct' My
application is to convert the data in the .ct file, into something new,
then enter the data into a file in the local directory the application
was executed named 'myExample.out'.

Is their a simplified way to handle this problem?


The C language and library don't say much about the
syntax of file names. They're represented as strings and
therefore can't contain '\0' characters, there are a few
values like FILENAME_MAX and L_tmpnam, and that's about
all C has to say about filenames. In particular, C has
no built-in facilities for picking apart filenames and
putting them back together again to generate new ones --
well, there's tmpnam(), but that hardly meets your need.

That said, if you happen to know that file names on
the systems you care about look like those above, you can
use straightforward string-bashing to get the job done.
Something like this might work:

const char *old = "/home/joe/myExample.ct";
const char *ext = ".out";
char *new;
char *p, *q;

/* Find rightmost "component" */
p = strrchr(old, '/');
p = (p == NULL) ? old : p + 1;
q = strrchr(p, '\\');
p = (q == NULL) ? p : q + 1;

/* Find start of "extension" */
q = strrchr(p, '.');
p = (q == NULL) ? p + strlen(p) : q;

/* Assemble new name */
new = malloc(p - old + sizeof ext);
if (new == NULL) abort();
memcpy (new, old, p - old);
strcpy (new + (p - old), ext);

This will mis-handle some unusual file names -- for example,
it would botch the valid POSIX file name "myExample.\\", and
its treatment of "/home/joe/.cshrc" is suspect. You might
be able to improve matters with some extra tests and a few
system-specific #ifdef's. In any case, thank your lucky
stars that you aren't dealing with (Open)VMS!

$DISK1:<ROOT.>[HOME.JOE]MYEXAMPLE.CT;3

--
Er*********@sun.com

Nov 14 '05 #2

P: n/a
> Is their a simplified way to handle this problem?

I've used these functions before, without problems. Any suggestions?

#define MAXFNAME 2048 // max length of filenames expected
#define EXTLEN 10 // max extension length expected

char * get_ext (char * fname) // returns the extension from a filename
{
char * ext;
int i, j;
ext = (char *)malloc(sizeof(char) * EXTLEN);

for ( i = strlen(fname)+1; i > 0; i--)
{
if (fname[i] == '.')
{
for (j = i+1; j < strlen(fname)+1; j++)
{
ext[j-i-1] = fname[j];
}
i = 0;
}
}
return ext;
}

char * get_basefilename (char * fname) // returns the filename minus
the extension
{
char * ext;
int i, j;
ext = (char *)malloc(sizeof(char) * MAXFNAME);

for ( i = strlen(fname)+1; i > 0; i--)
{
if (fname[i] == '.')
{
for (j = 0; j < i; j++)
{
ext[j] = fname[j];
}
ext[i] = '\0';
i = 0;
}
}
return ext;
}

Nov 14 '05 #3

P: n/a
gm********@yahoo.com wrote:
I need assistance coming up with a clean way to handle filename
extensions with my application.

While I can come up with several ways of doing so on my own, I felt
perhaps it would be worth asking here to see what more effective or
accepted methods for doing would be presented.

The issue is this. My application accepts files names, intended for
a cross platform unix and windows environment, from the command line.
So the application may get a file name '/home/joe/myExample.ct',
'C:\Work\myExample.ct' or more generically 'myExample.ct' My
application is to convert the data in the .ct file, into something new,
then enter the data into a file in the local directory the application
was executed named 'myExample.out'.

Is their a simplified way to handle this problem?


There is a simple way to generate such names (you have not specified the
problem). The following replaces the extension; I'm sure you can work
out the simple problem of replacing an initial segment. Note that C has
no concept of directories, local or otherwise. From the standpoint of C
you are doing nothing more than trivial manipulation of the character
strings that represent the names associated with the streams.

#include <stdio.h>
#include <string.h>

int main(void)
{
char input_name[] = "/home/joe/myExample.ct", new_extension[] =
".out";
char output_name[FILENAME_MAX], *dot;
strcpy(output_name, input_name);
if ((dot = strrchr(output_name, '.')))
*dot = 0;
strcat(output_name, new_extension);
printf("The input filename was \"%s\"\n"
"The output filename is \"%s\"\n", input_name, output_name);
return 0;
}

The input filename was "/home/joe/myExample.ct"
The output filename is "/home/joe/myExample.out"
Nov 14 '05 #4

P: n/a
On Wed, 15 Jun 2005 09:51:50 -0700, No Such Luck wrote:
Is their a simplified way to handle this problem?


I've used these functions before, without problems. Any suggestions?

#define MAXFNAME 2048 // max length of filenames expected
#define EXTLEN 10 // max extension length expected

char * get_ext (char * fname) // returns the extension from a filename
{
char * ext;
int i, j;
ext = (char *)malloc(sizeof(char) * EXTLEN);

for ( i = strlen(fname)+1; i > 0; i--)
{
if (fname[i] == '.')
{
for (j = i+1; j < strlen(fname)+1; j++)
{
ext[j-i-1] = fname[j];
}
i = 0;
}
}
return ext;
}


You could simplify this by using the standard C library function strrchr()
(note the 2 r's). But consider what it does for pathnames like foo.bar/baz

Lawrence
Nov 14 '05 #5

P: n/a
While I have no direct experience with it, I believe pcre.h would
provide powerful capabilities that the str* functions do not.

This would allow you to deal with files and directories that have
unusual period placement.

Chris

Nov 14 '05 #6

P: n/a
gm********@yahoo.com wrote:

I need assistance coming up with a clean way to handle filename
extensions with my application.

While I can come up with several ways of doing so on my own, I
felt perhaps it would be worth asking here to see what more
effective or accepted methods for doing would be presented.

The issue is this. My application accepts files names, intended
for a cross platform unix and windows environment, from the
command line. So the application may get a file name
'/home/joe/myExample.ct', 'C:\Work\myExample.ct' or more
generically 'myExample.ct' My application is to convert the data
in the .ct file, into something new, then enter the data into a
file in the local directory the application was executed named
'myExample.out'.

Is their a simplified way to handle this problem?


It is up to you to construct a suitable file name from the users
input. Once you have done that, the rest of the work is done by
passing that name to fopen.

The construction is system dependent, and has nothing to do with
the language. If you can come up with exact definitions, and want
help on code to do specific conversions, then this is the place to
ask. The place to ask about the definitions is on newsgroups
dedicated to the systems involved.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #7

P: n/a
CBFalconer wrote:
The construction is system dependent, and has nothing to do with
the language. If you can come up with exact definitions, and want
help on code to do specific conversions, then this is the place to
ask. The place to ask about the definitions is on newsgroups
dedicated to the systems involved.


I know how to open a file, insert data, close it, move the file
pointer around, etc. That stuff I do know. I also understand that
what I'm being passed is a string initaly, and it's up to me to open
the input and output file handles.

What I'm asking about is more related to string manipulation. That
is, I want a way to know what the actual 'filename' without extension
or path, and then create a new file using that filename alone with the
new extension I've created on my own. I've already defined what a .ct
and a .out files are. This isn't about the specifications of a
specific file type, it's how to in a generic C sence, manipulate a
string containing what's expected to be a valid file name.

Ya know, Their has to be a small library for this sort of thing. I
bet someone's got some kind of class or at least a structure and
function library that takes care of all this for me. I should google
some for that idea and see what comes up. Might even support file
access too.

Tony

Nov 14 '05 #8

P: n/a
> What I'm asking about is more related to string manipulation. That
is, I want a way to know what the actual 'filename' without extension
or path, and then create a new file using that filename alone with the
new extension I've created on my own.
A key thing to remember here is that *YOU*, the programmer, are
responsible for all the memory management. You want to copy
something? You find a place to put it. And it's your problem
to make sure there's enough space for it.
I've already defined what a .ct
and a .out files are. This isn't about the specifications of a
specific file type, it's how to in a generic C sence, manipulate a
string containing what's expected to be a valid file name.


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.

In this case, you can copy from the beginning of the file name
up to and including the last period (copy into a buffer that's
big enough for the new file name), then append your own new extension.
Finding the last period is easy with strrchr(). Be sure to deal
with the case where there isn't one.

This has a number of problems. The normal use of the term doesn't
match up with the definition above in a number of cases, such as:

a. /home/bob/.login no extension
b. /usr/bin/diff no extension
c. /home/bob/main. no extension
d. /home/bob.j/main no extension
e. .login no extension

2. The file extension is the part of the file/path name between
the last period and the end of the file name. If there is a directory
separator (/ in UNIX, typically \ in Windows or MS-DOS) between the
last period and the end of the file name, the extension is null.
(takes care of (d)). If there is a directory separator or the
beginning of the file name immediately preceeding the last period,
the extension is null. (takes care of (a) and (e)). If there is
no period in the file name, the extension is null. (takes care of
(b)). If the file name ends with a period, the extension is null.
But be careful not to end up doubling up on the periods. (takes
care of (c)).

You divide the file name into three parts: the prefix, the period,
and the extension. The extension may be null (and does not include
the period). The period may or may not actually be there (see cases
(a), (b), (d), and (e). The prefix is the part of the file name
before the extension and before the immediately preceeding period,
if there is one. If the extension is null, the prefix is the whole
file name, minus a trailing period, if any.

To make a new file name with a different extension, concatenate the
prefix, a period, and the new extension. To make a new file name
without an extension, use the prefix.

I'm sure someone is going to come up with some special cases I've
forgotten. And someone may not like the way I handled case (c)
identically to leaving off the trailing period.

Gordon L. Burditt
Nov 14 '05 #9

P: n/a

Le 15/06/2005 22:58, dans 11*************@corp.supernews.com, «*Gordon
Burditt*» <go***********@burditt.org> a écrit*:
I'm sure someone is going to come up with some special cases I've
forgotten.


More or less in your list, but:
INSTALL.macppc one dot, but not really an extension
patch-2.6.11.12.bz2 many dots
linux-2.6.11.12.tar.gz many dots and extension with 2 dots
(if we consider .tar.gz is the extension)

There is yet another problem: on some architectures, there may be
non-ascii characters, and depending on their coding, things can
get complicated. Not for the extension, but filename length at least,
if multibyte chars are used (e.g. UTF8 on HFS+ partitions).

Nov 14 '05 #10

P: n/a
gm********@yahoo.com wrote:
CBFalconer wrote:
The construction is system dependent, and has nothing to do with
the language. If you can come up with exact definitions, and want
help on code to do specific conversions, then this is the place to
ask. The place to ask about the definitions is on newsgroups
dedicated to the systems involved.


I know how to open a file, insert data, close it, move the file
pointer around, etc. That stuff I do know. I also understand that
what I'm being passed is a string initaly, and it's up to me to open
the input and output file handles.

What I'm asking about is more related to string manipulation. That
is, I want a way to know what the actual 'filename' without extension
or path, and then create a new file using that filename alone with the
new extension I've created on my own. I've already defined what a .ct
and a .out files are. This isn't about the specifications of a
specific file type, it's how to in a generic C sence, manipulate a
string containing what's expected to be a valid file name.


You haven't come up with the definitions. There are string
manipulating routines, such as strcat and strcpy, available. We
haven't the foggiest idea what string can represent a file on your
system. Maybe it needs a 12 digit hexadecimal representation, for
all I know. If you are dealing with MsDos there are some rules,
CP/M has other rules, Unix still others, Windoze others,
UncleBobsEmbeddedMachines has still another set. Not to mention
VMS, OS2, MACs, Burroughs, etc. Some systems have paths and/or
extensions, others do not. So go somewhere where the mouth of the
horse can be seen and heard.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #11

P: n/a
>> I'm sure someone is going to come up with some special cases I've
forgotten.
More or less in your list, but:
INSTALL.macppc one dot, but not really an extension


I think this one really *IS* an extension.
patch-2.6.11.12.bz2 many dots
Here, it works like I think it should: bz2 is the extension.
Although, after you uncompress it, .12 is the extension,
and that doesn't really fit in with the usual use of extensions.
linux-2.6.11.12.tar.gz many dots and extension with 2 dots
(if we consider .tar.gz is the extension)
You have a point here, but I really don't know how to generalize
it. "If the string immediately following an extension commonly
used by a compression program is ".tar.", the "tar." is part of the
extension?" That's a bit wierd. It's also true that since the
LAST extension is .gz, the appropriate thing to feed it to is
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.

There is yet another problem: on some architectures, there may be
non-ascii characters, and depending on their coding, things can
get complicated. Not for the extension, but filename length at least,
if multibyte chars are used (e.g. UTF8 on HFS+ partitions).


If you know what character set your file name is in, you shouldn't
have too much trouble, except for the problem of "what's a period".
of there is more than one character code used for one.

Gordon L. Burditt
Nov 14 '05 #12

P: n/a

Le 16/06/2005 00:33, dans 11*************@corp.supernews.com, «*Gordon
Burditt*» <go****@hammy.burditt.org> a écrit*:
More or less in your list, but:
INSTALL.macppc one dot, but not really an extension


I think this one really *IS* an extension.


Bof... It's the help file for installing OpenBSD on Macintosh.
Only a plain ASCII text file. The extension should be .txt.
I should have clarified this I think.

Sometimes, files have dots, but no extension (I thought
this was a valid example, if not I'm sure you will find some).
I once thought it was possible to cope with that by enforcing
length(ext)<=5 (or any other value), but MacOSX showed up
with some exotic extensions, like "blabla.webarchive".

There is even a strange situation on MacOSX: some folders
are treated like plain files, under unix command line
they are folders, but they should be managed like files.
An example: "blabla.rtfd" would be a folder containing
an RTF file, and some images. An "application" is
merely a unix executable, plus all its resource files,
etc... Not much to do with your problem, but if you
write a program to manage rtfd "files", you need to
be careful with that.

Nov 14 '05 #13

P: n/a
go****@hammy.burditt.org (Gordon Burditt) writes:
[...]
You have a point here, but I really don't know how to generalize
it. "If the string immediately following an extension commonly
used by a compression program is ".tar.", the "tar." is part of the
extension?" That's a bit wierd. It's also true that since the
LAST extension is .gz, the appropriate thing to feed it to is
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>
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".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #14

P: n/a
gm********@yahoo.com writes:
I need assistance coming up with a clean way to handle filename
extensions with my application.

While I can come up with several ways of doing so on my own, I felt
perhaps it would be worth asking here to see what more effective or
accepted methods for doing would be presented.

The issue is this. My application accepts files names, intended for
a cross platform unix and windows environment, from the command line.
So the application may get a file name '/home/joe/myExample.ct',
'C:\Work\myExample.ct' or more generically 'myExample.ct' My
application is to convert the data in the .ct file, into something new,
then enter the data into a file in the local directory the application
was executed named 'myExample.out'.

Is their a simplified way to handle this problem?


You might consider simplifying the problem. When I do this kind of
thing, I generally just append a suffix to the original file name,
without worrying about what the initial suffix is, if any.

For example, "/home/joe/myExample.ct" would be mapped to
"/home/joe/myExample.ct.out".

Whether you can get away with this depends on the requirements, and
possibly on what the OS supports. Some systems (VMS, for example)
don't allow multiple '.' characters in file names, and some may impose
limits on how long a file name can be.

If you really need to replace the extension with a different one,
you're going to have to define exactly what you mean by that before we
can help you. Show us a few more examples, and be prepared to tell us
what you need for any examples we might offer. Consider what to do if
the file name has no extension. On Unix, a '\' is a valid (but
unlikely) character in a file name, so "ab.cd\ef" probably has an
extension of "ef" on Winddows and "cd\ef" on Unix. Or you can reject
anything that's too weird, but then you need to define what "too
weird" means.

Defining the problem precisely is up to you.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #15

P: n/a
On Thu, 16 Jun 2005 05:52:31 +0000, Keith Thompson wrote:

....

On Unix, a '\' is a valid (but
unlikely) character in a file name, so "ab.cd\ef" probably has an
extension of "ef" on Winddows and "cd\ef" on Unix.


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

Lawrence
Nov 14 '05 #16

P: n/a
On 15 Jun 2005 11:06:31 -0700, gm********@yahoo.com
<gm********@yahoo.com> wrote:
What I'm asking about is more related to string manipulation. That
is, I want a way to know what the actual 'filename' without extension
or path, and then create a new file using that filename alone with the
new extension I've created on my own. I've already defined what a .ct
and a .out files are. This isn't about the specifications of a
specific file type, it's how to in a generic C sence, manipulate a
string containing what's expected to be a valid file name.
strchr(), strrchr(), strcpy(), strncpy(), etc.

More than that can't be determined until you know which filename syntax
you are using.
Ya know, Their has to be a small library for this sort of thing. I
bet someone's got some kind of class or at least a structure and
function library that takes care of all this for me. I should google
some for that idea and see what comes up. Might even support file
access too.


I have a function which works for MSDOS/Windows and Unix file syntax.
It doesn't always get things right (as I recall it treats .bashrc as
having no base name and all extension) but works for the files I use it
with. Email me if you want a copy.

Chris C
Nov 14 '05 #17

P: n/a
Keith Thompson wrote:
If you really need to replace the extension with a different one,
you're going to have to define exactly what you mean by that before we
can help you.
Okay, the intended platforms, and only supported platforms are going
to be unix based (Solaris and Linux) and Microsoft based (Windows and
MSDos) only. Here, I'll simplify the whole solution even further.

-- 1) If the file ends with '.ct' everything before that, that is not a
directory definition, will be used as a filename, and have the '.out'
extension appended to it.

-- 2) All other paths+filenames will have the path portion striped off,
and the remaining filename used, with '.out' appended to the end of it.

-- 3) A filename must contain only alpha numeric characters and in
addition may contain a period, dash, underscore and the left and right
brackets []. While the unix enviorment may support more, I'm going to
limit it to this for now. This actually may add complexity to the
code, so excuse me if it does.

So, for example

i) 'myFile.ct' -> 'myFile.out'
ii) '.myfile' -> '.myfile.out'
iii) '/home/myDir/myFile.dat' -> 'myFile.dat.out'
iv) 'C:\home\myDir.ct\myFile' -> 'myFile.out'
v) 'C:\myFile.dat.bak.ct' -> 'myFile.dat.bak.out'
vi) 'my_file[123].' -> 'my_file[123].out'
Defining the problem precisely is up to you.


Well I can only hope that this sufficently resolves the issue but in
general, I'm not exactly sure what more you could use, but ask away.

Tony

Nov 14 '05 #18

P: n/a


gm********@yahoo.com wrote:
Keith Thompson wrote:
If you really need to replace the extension with a different one,
you're going to have to define exactly what you mean by that before we
can help you.

Okay, the intended platforms, and only supported platforms are going
to be unix based (Solaris and Linux) and Microsoft based (Windows and
MSDos) only. Here, I'll simplify the whole solution even further.

-- 1) If the file ends with '.ct' everything before that, that is not a
directory definition, will be used as a filename, and have the '.out'
extension appended to it.

-- 2) All other paths+filenames will have the path portion striped off,
and the remaining filename used, with '.out' appended to the end of it.

-- 3) A filename must contain only alpha numeric characters and in
addition may contain a period, dash, underscore and the left and right
brackets []. While the unix enviorment may support more, I'm going to
limit it to this for now. This actually may add complexity to the
code, so excuse me if it does.

So, for example

i) 'myFile.ct' -> 'myFile.out'
ii) '.myfile' -> '.myfile.out'
iii) '/home/myDir/myFile.dat' -> 'myFile.dat.out'
iv) 'C:\home\myDir.ct\myFile' -> 'myFile.out'
v) 'C:\myFile.dat.bak.ct' -> 'myFile.dat.bak.out'
vi) 'my_file[123].' -> 'my_file[123].out'


Hmmm: Example vi seems to contradict Requirement 2.
I'm going to take Example vi as indicating your true intent.

#define VALID_CHARS "abcdefghijklmnopqrstuvwxyz" \
"ABCDEFGHIJKLMNOPQRSTUVWXYZ" \
"0123456789.-_[]"
#define OLD_EXTENSION ".ct"
#define NEW_EXTENSION ".out"

const char *old = "C:\\home\\myDir.ct\\myFile";
char *new;
const char *p;

/* Skip past directory components */
p = strrchr(old, '/');
if (p != NULL)
old = p + 1;
p = strrchr(old, '\\');
if (p != NULL)
old = p + 1;

/* Check for valid alphabet (Examples iii, iv, and v
* suggest that you don't want this check to be made
* on "the path portion")
*/
if (strspn(old, VALID_CHARS) < strlen(old))
reject_bad_filename();

/* Find extension (if any) and decide whether to
* replace or retain it
*/
p = strrchr(old, '.');
if (p == NULL || strcmp(p, OLD_EXTENSION) != 0)
p = old + strlen(old);

/* Assemble new name */
new = malloc( (p - old) + sizeof NEW_EXTENSION );
if (new == NULL)
die_horribly();
memcpy (new, old, p - old);
strcpy (new + (p - old), NEW_EXTENSION);

Note that there's no special handling for inputs with
a Windows drive designator but no path components: "c:file"
will be rejected as bad because of the colon in what the
code thinks of as "the file name." If that's not what you
want, change it.

--
Er*********@sun.com

Nov 14 '05 #19

P: n/a
gm********@yahoo.com wrote:
.... snip ...
Okay, the intended platforms, and only supported platforms are going
to be unix based (Solaris and Linux) and Microsoft based (Windows and
MSDos) only. Here, I'll simplify the whole solution even further.

-- 1) If the file ends with '.ct' everything before that, that is not a
directory definition, will be used as a filename, and have the '.out'
extension appended to it.

-- 2) All other paths+filenames will have the path portion striped off,
and the remaining filename used, with '.out' appended to the end of it.

-- 3) A filename must contain only alpha numeric characters and in
addition may contain a period, dash, underscore and the left and right
brackets []. While the unix enviorment may support more, I'm going to
limit it to this for now. This actually may add complexity to the
code, so excuse me if it does.

So, for example

i) 'myFile.ct' -> 'myFile.out'
ii) '.myfile' -> '.myfile.out'
iii) '/home/myDir/myFile.dat' -> 'myFile.dat.out'
iv) 'C:\home\myDir.ct\myFile' -> 'myFile.out'
v) 'C:\myFile.dat.bak.ct' -> 'myFile.dat.bak.out'
vi) 'my_file[123].' -> 'my_file[123].out'
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?
Defining the problem precisely is up to you.


Well I can only hope that this sufficently resolves the issue but in
general, I'm not exactly sure what more you could use, but ask away.


This is for us to use? I didn't realize you were expecting to pay
good money for us to do your programming for you. The rate here,
for quickie jobs like this, is USD200 per hour, with a 4 hour
minimum. We can throw in prodding you into defining the job for
free in this case, although that would normally be an additional
charge. We will have to define the gazinta and gazouta for the
supplied module. I suggest a char string for each, with the
gazouta being a malloced string, which will require eventual
freeing. So there will be two routines, with a and b depending on
your naming preference:

char *afromb(char *bstring);

Boy, look at all you are getting for free!

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #20

P: n/a
CBFalconer wrote:
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

Nov 14 '05 #21

P: n/a
In article <11**********************@g14g2000cwa.googlegroups .com>,
<gm********@yahoo.com> wrote:

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.
--
7842++
Nov 14 '05 #22

P: n/a
Lawrence Kirby <lk****@netactive.co.uk> writes:
On Thu, 16 Jun 2005 05:52:31 +0000, Keith Thompson wrote:

...

On Unix, a '\' is a valid (but
unlikely) character in a file name, so "ab.cd\ef" probably has an
extension of "ef" on Winddows and "cd\ef" on Unix.


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


You're right.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #23

P: n/a
an******@example.com (Anonymous 7843) writes:
In article <11**********************@g14g2000cwa.googlegroups .com>,
<gm********@yahoo.com> wrote:

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.


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).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #24

P: n/a
Gordon Burditt wrote:

<snipped>
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
Nov 14 '05 #25

P: n/a
Keith Thompson wrote:

<snipped>
<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
Nov 14 '05 #26

P: n/a
Le 16/06/2005 23:03, dans d8**********@ctb-nnrp2.saix.net, «*goose*»
<ru**@webmail.co.za> a écrit*:
Gordon Burditt wrote:

<snipped>
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.


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.

Nov 14 '05 #27

P: n/a
On Wed, 15 Jun 2005 20:58:54 -0000, in comp.lang.c ,
go***********@burditt.org (Gordon Burditt) wrote:
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...

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 14 '05 #28

This discussion thread is closed

Replies have been disabled for this discussion.