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

--
___________________________________________________

Mageia 2 for x86_64, Kernel: 3.4.34-desktop-1.mga2
KDE version 4.8.5 Running on an AMD 4-core processor

[Jorgen Grahn]

On Thu, 2013-05-16, Pinnerite wrote:
> 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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Richard Damon]

On 5/16/13 7:36 AM, Pinnerite wrote:
> 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
>

My first advise is that if the existing program is in C, then it is by
far easiest to keep the program in C and not convert/rewrite it to C++,
as conversion could be a significant task. Yes, it would likely be
somewhat easy to get the code to compile and probably run under a C++
compiler, as a few simple mechanical rules can transform most C programs
into "valid" C++ code (renaming variables that conflict with C++ key
words, add explicit casts for C's implicit conversion of void*, etc),
but what you end up with isn't what many would consider "good" C++ code.

The one case where this might be worth it would be if you wanted to add
something that was already available as C++ to the code (since
converting C to C++ is much easier that C++ to C), but this doesn't
sound likely given your stated background.

[Jens Thoms Toerring]

In comp.lang.c Pinnerite <pinn...@gmail.com> wrote:
> 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
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de

[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]

On Thu, 2013-05-16, Pinnerite wrote:

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

[Pinnerite]

Jorgen Grahn wrote:

> On Thu, 2013-05-16, Pinnerite wrote:
>> 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.

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.

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

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



>
> /Jorgen

[Jens Thoms Toerring]

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Thu, 2013-05-16, Pinnerite wrote:
> > 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.

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.:-(

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

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

[Jorgen Grahn]

On Thu, 2013-05-16, Pinnerite wrote:

> Jorgen Grahn wrote:

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

[Christian Gollwitzer]

Am 16.05.13 18:20, schrieb Pinnerite:

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

So you want a GUI to choose the pathnames from.

I second the proposal to make a wrapper approach, much more on Linux.
First, you should change the "C" program (let's call it foo-c) to accept
the output file names as command line args, such that you call it

./foo-c write_to_this.txt and-that.dat

That should be rather straightforward, simply replace the hardcoded file
names by argv[1], argv[2] etc.

Then, create a GUI wrapper using e.g. Tcl/Tk, which is preinstalled in
almost every Linux system. Something as simple as the following should
work, if you put it in the same directory as foo-c:

#!/usr/bin/env wish
#
package require Tk
# compute path to foo-c
set mydir [file dirname [info script]]
set fooc [file join $mydir foo-c]
# ask for file name
set fn [tk_getSaveFile -title "Choose file name" ]
if {$fn!=""} {
# user hit Save, run foo-c
exec $fooc $fn
}
exit


If you put this in a file and give execute permissino, it should work.
Of course, you can make it more fancy by adding a progress bar, multiple
options, better error handling and the like.

The beauty in this approach is, that you can still call the original
thing from the command line, and that crashes from the underlying
utility don't crash the GUI.

Christian