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

system command

P: n/a
Hello,

I am writing a script which is using the system() command. In the
script the system command invokes an encryption with system("gpg -f
file.txt").

The problem comes when the script is required to perform this
operation on different files which the user selects via another
function. The name of the filename is stored in a variable as a
string and I can't get the variable substituted into the ststem
command. I have tried to concatenate the whole command inside the
quotes into one string variable and enter it into the system command
but this brings up the error that the system command requires a const
char and not strings. Can anyone help me out with getting this system
command to work.

I have had the thought of looking into tcreating a pointer to the
string and putting this in the command, would this be on the right
track?

any help you can give would be greatly appreciated.

Thanks and regards

John
Jul 23 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
Sokar wrote:
I am writing a script which is using the system() command. In the
script the system command invokes an encryption with system("gpg -f
file.txt").

The problem comes when the script is required to perform this
operation on different files which the user selects via another
function. The name of the filename is stored in a variable as a
string and I can't get the variable substituted into the ststem
command. I have tried to concatenate the whole command inside the
quotes into one string variable and enter it into the system command
but this brings up the error that the system command requires a const
char and not strings. Can anyone help me out with getting this system
command to work.

I have had the thought of looking into tcreating a pointer to the
string and putting this in the command, would this be on the right
track?


...
std::string onepart("gpg -f ");
std::string twopart;
// obtain twopart somehow ...
twopart = "file.txt";
system((onepart+twopart).c_str());

V
Jul 23 '05 #2

P: n/a
>>this brings up the error that the system command requires a const
char and not strings.
Use std::string::c_str();
I have had the thought of looking into tcreating a pointer to the
string and putting this in the command, would this be on the right
track?


No, because then you would be passing it a std::string * and not a
const char *

Jul 23 '05 #3

P: n/a
The STL 'string' class has a '.c_str()' method that "Returns a pointer
to a null-terminated array of characters representing the string's
contents."
#include <string>
#include <cstdlib>
int
main()
{
std::string quine("perl -e 'while(<>) { print; }' quine.cpp");
||||
++++---+++
// not a real quine, |||
// since it doesn't print all
// of it's source code.

std::system( quine.c_str() );
}

Jul 23 '05 #4

P: n/a
On 5 Apr 2005 06:02:37 -0700, Sokar <jm**********@hotmail.com> wrote:
Hello,

I am writing a script which is using the system() command. In the
script the system command invokes an encryption with system("gpg -f
file.txt").

The problem comes when the script is required to perform this
operation on different files which the user selects via another
function. The name of the filename is stored in a variable as a
string and I can't get the variable substituted into the ststem
command. I have tried to concatenate the whole command inside the
quotes into one string variable and enter it into the system command
but this brings up the error that the system command requires a const
char and not strings. Can anyone help me out with getting this system
command to work.

I have had the thought of looking into tcreating a pointer to the
string and putting this in the command, would this be on the right
track?


not exactly.

string::c_str() gives you a pointer to a zero-terminated char - sequence
usually you can write:

void fun(char* c);
....
string s = "ssss";
fun(s.c_str())

i hope i understood your problem correctly.

- ulrich
Jul 23 '05 #5

P: n/a
> system((onepart+twopart).c_str());
Is this safe? I guess the temporary string will be destructed and the
pointer returned by c_str will no longer be vaild.

Andre Caldas.
Jul 23 '05 #6

P: n/a
Andre wrote:
system((onepart+twopart).c_str());

Is this safe? I guess the temporary string will be destructed and the
pointer returned by c_str will no longer be vaild.


Yep.
But the temporary will be destroyed at the end of the statement.
That is, when the system() call has already returned. Thus
it is safe.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 23 '05 #7

P: n/a

Andre Caldas wrote:
Karl Heinz Buchegger wrote:
system((onepart+twopart).c_str());

Is this safe? I guess the temporary string will be destructed and thepointer returned by c_str will no longer be vaild.
But the temporary will be destroyed at the end of the statement.
That is, when the system() call has already returned. Thus
it is safe.


I think it will be destructed after c_str() returns. This is before

the system call is returned.


That would make it pretty useless. What could you do with it? I mean,
you'd have a member function that returns a pointer that is always
invalid.

Brian

Jul 23 '05 #8

P: n/a
> The temporary (onepart+twopart) is passed to c_str()...

The temporary is created in system's scope, and then a pointer or
constant reference to the temporary is passed to string::c_str().

Jul 23 '05 #9

P: n/a
> #include <iostream>

class CTest
{
public:
CTest() { std::cout << "Ctor called" << std::endl; }
~CTest() { std::cout << "Dtor called" << std::endl; }

const char* c_str() { return "Test"; }
};

void foo( const char* Arg )
{
std::cout << Arg << std::endl;
}

int main()
{
foo( CTest().c_str() );
}

Output:
Ctor called
Test
Dtor called

The temporary is destroyed after the call has returned.


That is really new to me! I am really surprised.
Thanks for the example :-)
Jul 23 '05 #10

P: n/a
> The temporary is created in system's scope, and then a pointer or
constant reference to the temporary is passed to string::c_str().


That makes a lot of sense. ("scope" is much better then "end of the
statement")

Thank you.
Andre Caldas.
Jul 23 '05 #11

P: n/a
Andre Caldas wrote:
Karl Heinz Buchegger wrote:
system((onepart+twopart).c_str());

Is this safe? I guess the temporary string will be destructed
and the pointer returned by c_str will no longer be vaild.


But the temporary will be destroyed at the end of the statement.
That is, when the system() call has already returned. Thus
it is safe.


I think it will be destructed after c_str() returns. This is
before the system call is returned.


Temporaries live until the end of the full-expression in which
they were created (at least). "full-expression" roughly means a
statement, or the controlling expression in a loop.

Jul 23 '05 #12

P: n/a
> Temporaries live until the end of the full-expression in which
they were created (at least). "full-expression" roughly means a
statement, or the controlling expression in a loop.


Sorry, but "full-expression" means nothing to me. Is it on some standard?

I guess my "rough" understanding of "full-expression" was different from
everybody else's. Now I understand how it works. It is much better then
the way I thought it was.

But by the way, I don't belive that the destruction of the temporary
would make things like "a(temporary().d())" - as long as temporary::d()
does not return a reference to any thing that would be destructed as well.

Andre Caldas.
Jul 23 '05 #13

P: n/a
Correction:
would make things like "a(temporary().d())" - as long as temporary::d()


would make things like "a(temporary().d())" useless - as long as
temporary::d()
Jul 23 '05 #14

P: n/a
Andre Caldas wrote:
Temporaries live until the end of the full-expression in which
they were created (at least). "full-expression" roughly means a
statement, or the controlling expression in a loop.
Sorry, but "full-expression" means nothing to me.


That's why I explained it..
Is it on some standard?
Yes -- the C and C++ standards
I guess my "rough" understanding of "full-expression" was
different from everybody else's. Now I understand how it
works. It is much better then the way I thought it was.
That's good :)
But by the way, I don't belive that the destruction of
the temporary would make things like "a(temporary().d())"
useless - as long as temporary::d() does not return a
reference to any thing that would be destructed as well.


That expression is perfectly fine. However I'm not sure if
this is a great example; you could still call a() just fine
even if the temporary were destroyed immediately after the
call to d(). A better example might be:

struct foo {
std::string s;
std::string &d() { return s; }
};
printf("%s\n", foo().d().c_str());

which is fine because the temporary foo is not destroyed
until after the printf statement has finished executing.

Jul 23 '05 #15

P: n/a
Old Wolf wrote:
Temporaries live until the end of the full-expression in which
they were created (at least). "full-expression" roughly means a
statement, or the controlling expression in a loop.


Sorry, but "full-expression" means nothing to me.


That's why I explained it..


I just wanted to say that I don't know the formal defition of
"full-expression", and I don't think that if it is not "well-defined"
you cannot use it to argue. (but since you tell me that
'full-expression' is defined on the standards... then it's OK)

But by the way, I don't belive that the destruction of
the temporary would make things like "a(temporary().d())"
useless - as long as temporary::d() does not return a
reference to any thing that would be destructed as well.

That expression is perfectly fine. However I'm not sure if
this is a great example; you could still call a() just fine
even if the temporary were destroyed immediately after the
call to d(). A better example might be:

struct foo {
std::string s;
std::string &d() { return s; }
};
printf("%s\n", foo().d().c_str());

which is fine because the temporary foo is not destroyed
until after the printf statement has finished executing.


This example does not conform to the hipotetical situation where *foo*
would infact be destroyed.

Andre Caldas.
Jul 23 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.