Advice on an approach to a problem

[Pinnerite]

I make great use of a 'C' program written by someone else. It works
invisibly but creates files named by itself. I would like to grant the user
the option to create their own filenames and the paths for the created
files.

My question is in which environment to tackle this: C or C++?
I have not programmed for some time but keep up to date as best I can. I
have a limited experience in using OO languages but I do not want to devote
myself into becoming an expert in either language just getting to grips with
the bits that I need for this exercise.

I should add that this is a Linux exercise.

Any suggestions? TIA

 

[Jorgen Grahn]

I make great use of a 'C' program written by someone else. It works
invisibly but creates files named by itself. I would like to grant the user
the option to create their own filenames and the paths for the created
files.

Careful with the terminology. "path" and "filename" are almost
synonyms.

Programs (in Unix) which hardcode the output paths do indeed suck.
There are a few better design choices, assuming the program needs to
generate more than one file:

% foo # creates files in current directory
% foo --src bar.c --hdr bar.h
# the number of files is small and known
% foo --dest /tmp/bar/
# create /tmp/bar/ if needed and leave any files there
% foo --prefix /tmp/bar
# files are called bar.01, bar.02, ...

And others. You don't say what the program does, and it's hard to guess.

My question is in which environment to tackle this: C or C++?

C, of course. Why would you add an extra work load by porting it to
C++? It's not as if C cannot write to files.

Followup set.

I have not programmed for some time but keep up to date as best I can. I
have a limited experience in using OO languages but I do not want to devote
myself into becoming an expert in either language just getting to grips with
the bits that I need for this exercise.

You don't need to learn OO for this.

I should add that this is a Linux exercise.

/Jorgen

 

[Jens Thoms Toerring]

I make great use of a 'C' program written by someone else. It works
invisibly but creates files named by itself. I would like to grant the user
the option to create their own filenames and the paths for the created
files.

My question is in which environment to tackle this: C or C++?
I have not programmed for some time but keep up to date as best I can. I
have a limited experience in using OO languages but I do not want to devote
myself into becoming an expert in either language just getting to grips with
the bits that I need for this exercise.

If the program is already written in C and you just want to
modify it a bit then it would seem to me that using C for that
would make most sense - why add another language to the mix?

On the other hand, if all you want is to allow the user to
specify some file name(s) to be used instead of the one(s)
used by the program per default for its output a much simpler
solution might be to write a small wrapper script that accepts
the user defined file name(s), runs the original program and
then renames the file(s) produced by the program to what the
user prefers. While that could be done using C or C++ a simple
scripting language would be perfectly suitable to get such a
rather trivial job done with a few lines of code.

Regards, Jens

 

[Pinnerite]

Pinnerite wrote:

It appears that I was not clear as to what I want to do.

At the point where the output file is prepared, I want both a data entry box
for the user to enter or even edit a prototype filename and a dropdown
directory listbox enabling the user to browse it in order to select their
desired destination. I cannot remember the correct terminology for the
widgets, sorry.

Accepting that 'C' is appropriate, I guess it boils down to which library
and IDE would serve me best.

Regards

 

[Jorgen Grahn]

Pinnerite wrote:

It appears that I was not clear as to what I want to do.

At the point where the output file is prepared, I want both a data entry box
for the user to enter or even edit a prototype filename and a dropdown
directory listbox enabling the user to browse it in order to select their
desired destination. I cannot remember the correct terminology for the
widgets, sorry.

Be careful to check that the users actually want this. You're on Unix
and you want to convert a non-interactive tool to be interactive (and
presumably have a GUI). Lots of Unix users (but not all) would
dislike such a change, e.g. if they don't use a GUI or if they need
the tool to run attended.

Today I lost half my working day to such a needlessly-interactive
tool, so I'm in that camp.

Accepting that 'C' is appropriate, I guess it boils down to which library
and IDE would serve me best.

The wrapper script approach someone else mentioned suddenly sounds
even better. Tcl/Tk is a decent choice -- or perhaps simply a shell
script which calls some prompt-the-user-for-a-filename utility.

/Jorgen

 

[Pinnerite]

Be careful to check that the users actually want this. You're on Unix
and you want to convert a non-interactive tool to be interactive (and
presumably have a GUI). Lots of Unix users (but not all) would
dislike such a change, e.g. if they don't use a GUI or if they need
the tool to run attended.

I am not intending to force the result on anyone else, although if it proved
successful I would of course make it available.

Today I lost half my working day to such a needlessly-interactive
tool, so I'm in that camp.

I get the point but the utility only runs each time it is called and
virtually impossible for anyone but the user to do so.

The wrapper script approach someone else mentioned suddenly sounds
even better. Tcl/Tk is a decent choice -- or perhaps simply a shell
script which calls some prompt-the-user-for-a-filename utility.

I may be shallow but if a shell script is invoked, the output would be fed
back to original utility anyway. Hardly more secure. I have to draw the line
between security and paranoia. Still I could insist on a warning message on
the packaging <G>.

 

[Jens Thoms Toerring]

Be careful to check that the users actually want this. You're on Unix
and you want to convert a non-interactive tool to be interactive (and
presumably have a GUI). Lots of Unix users (but not all) would
dislike such a change, e.g. if they don't use a GUI or if they need
the tool to run attended.
s/attended/unattended/

Today I lost half my working day to such a needlessly-interactive
tool, so I'm in that camp.

I'd completely support this advice - there's hardly anything more
annoying than a program insisting on using a GUI which isn't strict-
ly needed! You can't run it on a fast machine that has no X-server
running, you can't reasonably run it from a script or another pro-
gram etc.:-(

The wrapper script approach someone else mentioned suddenly sounds
even better. Tcl/Tk is a decent choice -- or perhaps simply a shell
script which calls some prompt-the-user-for-a-filename utility.

You actually could have two wrappers - one that does the job
without a GUI and another one that has a GUI for selecting
file names with a graphical interface and then calls the non-
GUI wrapper script with those file names. For the GUI-wrapper
besides Tcl/Tk you could use e.g. Python with PyQt/PySide or
Perl with perlTk and probably many others (but which I don't
have experience with). If you use C your choices of a graphics
toolkit may prove to be rather limited, to my knowledge you
can only use either GTK or XForms with C. All others I'm aware
of are C++.
Regards, Jens

 

[Jorgen Grahn]

Jorgen Grahn wrote:

I may be shallow but if a shell script is invoked, the output would be fed
back to original utility anyway. Hardly more secure.

I don't know what you're referring to but yes, there are problems with
leaving the original utility as it is and trying to patch it up bny
wrapping. If the original e.g. leaves its files in /tmp:

- you can't be sure noone has replaced them maliciously
- you can't be sure noone has replaced them by simply running the
utility at the same time
- the utility may have failed, and your script copies old, outdated
files
- you may have problems finding the right files to move

/Jorgen