C / C++ / MFC

k505431-Dec-23 17:35

k5054

31-Dec-23 17:35

xterm will only return whether xterm itself failed or not. So for example xterm -e /bin/false returns true (0), since xterm executed successfully.

I'm suspicious about your approach, here though. Can you not run your command directly via QProcess, rather than launching an xterm? I am assuming 2 things here: 1) you need to capture the output of command, at least in part, and 2) QProcess can do that for you, similar to using pipe(), rather than using system() to run a shell command from a program.

"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown

jschell1-Jan-24 2:07

1-Jan-24 2:07

k5054 wrote:
I'm suspicious about your approach

I agree with that.

Message Closed

1-Jan-24 9:51

Salvatore Terress

1-Jan-24 9:51

Message Closed

modified 2-Jan-24 12:45pm.

k50541-Jan-24 13:09

k5054

1-Jan-24 13:09

You can tell sudo to allow certain users the ability to run a given command without having to prompt for a password. For example you might add a file foo to the /etc/sudoers.d directory

# allow user "joe" to use command /usr/sbin/foobar
joe ALL(ALL) NOPASSWD:/usr/sbin/foobar

# allow users in group foo to use command /usr/sbin/frobnicate
%foo ALL(ALL) NOPASSWD:/usr/sbin/frobnicate

Google for sudoers to see what other options you have for the sudoers file.

But you should be aware that any time a user process "needs" sudo access, its something of a smell. That is it should be considered a signal that there may be something fundamentally wrong with the approach to solving the problem. If your app definitely, absolutely, no-question-about-it needs to elevate its permissions to perform some tasks, I would be inclined to write a program that only does that one thing, and use setuid/setgid with appropriate setuid/setgid permissions e.g.

Bash

$ ls /usr/local/bin/foo
---s--x--x 1 root root 12345 Jan 1 08:00 /usr/local/bin/foo

and the code for foo would do something like

C++

std::string build_cmd_str(int argc, char argv)
{
   std::string cmd{"/usr/local/bin/foo"};
   / build up rest of command string here */
   if(bad_things_happened) {
      cmd.erase();
   }
   return cmd;
}

main(int argc, char *argv[])
{

   // create a command string<br />
   std::string cmd{build_cmd_str(argc, argv)}; 

   if(cmd.length() == 0) {
      // send diagnostic to cerr, maybe? 
      return -1;
   } else {
      setuid(0);  // set actual uid to root 
      FILE *p = pipe(cmd.c_str(), "r");
      // process output
      // send to stdout as needed
      pclose(p);
   }

   return 0;
}

This can be as simple or complex as you need, but should only execute one system command. Ideally, if you only need to run something as perhaps the database administrator, the helper program would have setuid as the dba, not root.

"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown

jschell2-Jan-24 6:14

2-Jan-24 6:14

k5054 wrote:
I would be inclined to write a program that only does that one thing, and use setuid/setgid with appropriate setuid/setgid permissions e.g.

That sounds like a really good solution to me.

Richard MacCutchan1-Jan-24 22:13

1-Jan-24 22:13

Salvatore Terress wrote:
Maybe I need to go back to QT forum to resolve this

Definitely yes, as none of this has anything to do with C++. I have looked at the documentationm for QStringList and QProcess, and what you are doing looks correct. But why it fails is impossible to guess.

jschell2-Jan-24 6:26

2-Jan-24 6:26

Salvatore Terress wrote:
I am still stuck at resolving the passing of parameters.

Following is not specific to sudo.

When you execute an OS command in any application the following applies
1. The command to run the executable
2. What happens AFTER the executable starts running.

The first represents the command (binary exe) and the command line options that the command accepts.

What happens with the second depends on the command. But a normal command (non-UI) will be using STDIO (stdin, stdout, stderr.)

The second can NOT be controlled with 'parameters'. Only the first can. The only way you can interact with the second in an application is by accessing the STDIO of the application as it runs.

The second becomes more complicated if the application has a GUI. It can also be more complicated in specific situations depending on exactly what the application does. (There is a way to bypass STDIO.)

For sudo and the first and the way you are executing it with "QP->start" you can only do what the command line options for the command allow. I suspect sudo probably varies by the specific OS. But following is one example.

sudo(8) - Linux manual page[^]

There is no way to change that. Either it is allowed by that or it isn't.

Additionally "start" might have a specific meaning on Windows which can also impact what happens. That doesn't mean is actually applies in this case.

start | Microsoft Learn[^]

Richard MacCutchan28-Dec-23 22:02

28-Dec-23 22:02

The << operator is an overloaded operator used in C++ stream IO. In basic terms it takes whatever object or value is on the right hand side of the operator, converts it to a string (aka char*) and sends that to the stream object on the left hand side. So using the standard ouptut stream (console), you can do:

C++

int number = 23;
double half = 23 / 2;

std::cout << "value = " << number << " halved = " << half;

So assuming the items in your code are:

C++

char* command = " hcitool ";
QString string = " dev ";

the result of:

C++

QP->start("/bin/sh", QStringList() << "-c" << command << "-c" << string );

should be:

"/bin/sh -c hcitool -c dev"

sent to the process handler.

Maybe you should spend some more time studying C++, as well as QT.

jschell29-Dec-23 5:16

29-Dec-23 5:16

Salvatore Terress wrote:
it fails.

Do not post questions with information like that. That can mean anything. What you need to post is the following.
1. What you expected it to do.
2. What it actually did.

From the little you posted I would have no idea what 'fails' means.

Salvatore Terress wrote:
sudo

I suspect the real problem is exactly that.

It is not your code. It is how that gets executed within your code.

Define: A 'shell' is a operating system process that executes command line commands. Windows has the console window and powershell.

First step for debugging OS shell calls is always the print the command line before you call it. (Obviously removing security info if needed.) You do that even when the code works.

Then when there is a problem you use that output to figure out what is wrong.

Second step is to try the exact command in your own shell window. Often this will show the problem and allow you to figure out exactly how you need to modify the command.

Third step is that you need to understand that OS commands that are executed from your application can and problem will have an environment that is inherited from the application. This includes access permissions. (People often have problems with Windows Services because they do not understand this.)

Finally I can only note that with my limited experience I know that 'sudo' has its own oddities. For one, at least at times, I remember it requiring a password all the time. No password and it doesn't work.

Another trick I have used for OS commands in an application is the following.
1. Output the command - as I said above you should always be doing this.
2. Use an OS command to open a shell - NOTHING else. So you would see a OS shell pop on your display
3. Copy the command from the output, exactly as printed, and then run it in the shell that was popped.
4. Debug as normal for problems with that command.

That trick often helps to simulate the environment problem I suggested above.

jeron112-Jan-24 5:04

jeron1

12-Jan-24 5:04

For the removal. Thumbs Down | :thumbsdown:

"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle

Richard MacCutchan12-Jan-24 5:39

12-Jan-24 5:39

Fairly common behaviour from someone who is on their (at least) fourth incarnation here.

Re: deleting from a vector

jeron112-Jan-24 6:16

jeron1

12-Jan-24 6:16

It takes all kinds. Sigh | :sigh:

deleting from a vector

mike741124-Dec-23 20:37

mike7411

24-Dec-23 20:37

I wrote some C++ code to create a vector and then try to delete all occurrences of 3 in it:

C++

vector<int> myVector = { 1, 2, 3, 4, 5, 3, 2 };

	for (auto i = myVector.begin(); i != myVector.end(); i++)
	{
		if (*i == 3) myVector.erase(i);
	}

However, it doesn't work right. It gives this error:

Expression: can't increment invalidated vector iterator

I guess you can't increment the iterator after you erase the element.

Anyone know how to fix this?

Thanks.

Richard MacCutchan24-Dec-23 21:39

Re: deleting from a vector

24-Dec-23 21:39

The problem comes because as soon as you remove an element then all the rest effectively move nearer the beginning, and thus their positions are out of sync with the iterator. You could try a reverse iterator as detailed at std::vector - cppreference.com[^].

Mircea Neacsu25-Dec-23 2:19

Mircea Neacsu

25-Dec-23 2:19

As you guessed, erase invalidates all iterators on the container. Your problem is known as the Erase–remove idiom[^] There are different ways of solving it:
1. The "manual" way:

C++

auto pos = myVector.begin();
size_t i=0;
while (pos != myVector.end())
{
  if (*pos ==3)
  {
    myVector.erase(pos);
    pos = myVector.begin() + i;
  }
  else
  {
    ++i;
    ++pos;
  }
}

2. The "semi-automatic" way:

C++

auto pos = myVector.begin();
while (pos != myVector.end())
{
  if (*pos ==3)
    pos = myVector.erase(pos); //erase returns an iterator pointing to next element
  else
    ++pos;
}

3. The "old fully automatic way":

C++

myVector.erase(std::remove(myVector.begin(), 
                              myVector.end(), 3),
               myVector.end());

4. The "new fully automatic way" (since C++20):

C++

std::erase (myVector, 3);

Disclaimer: I didn't compile any of the code above; some errors may/will exist Smile | :)

Mircea

std::async

utcode23-Dec-23 16:31

utcode

23-Dec-23 16:31

Hi,
Is it OK to call std::async(BYTE *p) from inside a worker thread?.
How would it be possible to make sure async calls gets executed in order of first came , first executed just like calling a function synchronously?

Re: std::async

Richard MacCutchan23-Dec-23 21:32

design question : variadic functions use ? .

23-Dec-23 21:32

If you want things run in order then do not use async. See the example at std::async - cppreference.com[^].

Maximilien19-Dec-23 2:34

19-Dec-23 2:34

(probably a TOmato vs toMAto kind of questions... )

At what point should I use variadic functions vs. keeping it local ?

I have a library that handles SQL queries.

is there a difference between something like :

(overly simplified)

C++

// do the formatting before calling the function.
std::string fullyFormedQuery = sprintf (queryFormat, param1, param2, ... ); 
void DoRequest( std::string fullyFormedQuery){ 
  // call SQL with the fullyFormedQuery
} 

// do the formatting in the function.
void DoRequest( std::string queryFormat, param1, param2, ... ){ 
  std::string fullyFormedQuery= queryFormat(format, param1, param2, ... ); 
  // call SQL ... 
}

CI/CD = Continuous Impediment/Continuous Despair

Mircea Neacsu19-Dec-23 2:42

Mircea Neacsu

19-Dec-23 2:42

As you say it's more of a style question. My preference would be for the first option (pass fully formed string) because:
- there is less documenting to do
- some compilers (MSVC for one), check matching between format strings and parameters in (s)printf functions but don't do that in a user defined variadic function.

Mircea

Maximilien19-Dec-23 2:54

19-Dec-23 2:54

thanks.

CI/CD = Continuous Impediment/Continuous Despair

jschell19-Dec-23 5:08

19-Dec-23 5:08

Just noting that your examples leave out using bind variables.

My understanding, and I just googled to see if that seems to be correct, is that bind variables make optimizations in the database easier.

Not to mention of course that they are a better fit for avoiding SQL injection problems.

Setting up bind variables is rather complex so putting it in the method is going to be better.

Maximilien19-Dec-23 7:36

19-Dec-23 7:36

Thanks.

We already have a complete (decades old) framework for SQL. (seems to be working fine)

maybe I should have left out the SQL reference and make it a more generic question.

CI/CD = Continuous Impediment/Continuous Despair

jschell20-Dec-23 5:31

20-Dec-23 5:31

Maximilien wrote:
complete (decades old) framework for SQL.

Then you should use the same idiom as the existing code. Changing it for some and not others just adds to the confusion. Although if a preference for one is given and there is a large amount of new work (new files not modifying existing code) then maybe go with there.

modified 20-Dec-23 12:00pm.

Maximilien20-Dec-23 6:55