|
I don't think it does. The QProcess::start method just starts the program: in this case a shell. The started program will process the information passed in via the QStringList , and then (probably) terminate. I don't use QT so I have no way of testing this. But I do not think you can call sudo or su in this way as the elevated process will be the started shell, and not your application. As I suggested in reply to your other question, you need to get the elevated privilege before starting your application.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Take a look at https://people.csail.mit.edu/albert/bluez-intro/c404.html[^]* which is a simple implementation. But to do it without the bluetooth libraries would mean writing all the actual bluetooth handling that goes on top of the sockets.
*in fact it would appear to be a complete tutorial on bluetooth usage.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Member 14968771 wrote: if you pay attenti0on to the title - I asked for help with using "socket".
Well this is what you actually asked:
Member 14968771 wrote: I am , rater naively, looking for (C/C++ no command scripts , please ) documented / commented example on how to implement Bluetooth in Linux, preferably skipping "bluez".
And that was the best example Google found for me. I have not been able to test it for you as I don't have the bluez library. But if you want to know how to use sockets directly then Google will find plenty of sample code that shows a client server implementation, e.g socket c programming - Google Search[^]. But you will still need to have a good understanding of the bluetooth transport protocol to implement it; that is why people use ready made libraries.
|
|
|
|
|
"Bluez" is the "official Linux Bluetooth stack". Your resistance to it simply means you will continue to flail about indefinitely.
https://www.researchgate.net/publication/345032366_Bluetooth_Stack_and_how_Linux_OS_handles_it#pf1f
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
modified 3-Apr-23 12:18pm.
|
|
|
|
|
Member 14968771 wrote: Linux, preferably skipping "bluez"
Even if you don't want to use it you can still look at it to see how they do it.
The license it has means you can do anything you want with it.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Member 14968771 wrote: How do I implement "Linux socket " for same ? You do what I suggested yesterday and implement the bluetooth protocol in your code. The document I gave you the link for gives example code. But if that is not enough you need to study the bluetooth protocol, and Google will find plenty of references for you.
|
|
|
|
|
Member 14968771 wrote: How do I implement "Linux socket " for same ?
Myself I have no idea.
But if it was me and I could not use the other library then, as I already stated, I would look at the source code for the library because the license specifically allows that.
That would give me ideas to implement it on my own.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
You seem to be struggking with some basic concepts. A device_id is simply an identifier that is returned by the bluetooth driver in the kernel. The kernel code uses this id to acces a specific connection (socket etc.) between devices. So every time you call a library function, you pass it the device_id so the driver code knows which connection you are referring to. I use the analogy of a telphone number, if you pass your telephone number to your mobile service provider, it always knows where to send messages.
If you want to bypass the device_id and use a plain socket (which is conceptually the same thing as described above) then that is fine. But as we keep saying, that means you have to write the code to actually use the bluetooth protocol over the connection that the socket makes with a remote device. Also, Bluetooth does not replace RS232, it is a network protocol that uses the ISO/OSI model.
But ultimately all your questions are asking for more information than there is space for in a forum such as this. The only way to get a good understanding of what you are trying to do (which remains something of a mystery) is to do a lot of research. The internet has hundreds of papers that detail networking in general and the various specific protocols, so that is where you need to go.
The link I gave you three days ago gives some good details (although abridged) on this whole subject. I strongly advise you to study it carefully, as it answers at least most of your questions.
|
|
|
|
|
Richard MacCutchan wrote: . Also, Bluetooth does not replace RS232, it is a network protocol that uses the ISO/OSI model. Any protocol that makes a distinction between higher and lower levels can be said to 'use the ISO/OSI model'. Or so it seems. I never saw any protocol with at least some higher/lower distinction (even morse can be said to have a 'higher' layer that is the di and dahs, and a 'lower' layer that is the generating of the carrier wave of the appropriate frequency.
I came into Bluetooth from an OSI angle, and started searching for service definitions according to OSI principles, protocol definitions according to OSI principles, and most important, a separation of these, according to OSI principles.
I started searching for layer independence, so that the same service interface (at each level) could be implemented by alternate lower layer protocols (and lower service interfaces). Nothing like that exists.
I started searching for protocol events and service interface events suitable for building a state machine in agreement with the standard OSI state machines. You'll never find that. The Bluetooth designers have even blurred the event concept: An event is certainly not atomic, but may include several packet exchanges.
Protocol-wise, Bluetooth is one big crow's nest. To quote Ted Nelson: Everything is deeply intertwingled. BT is a world of its own. Sure can be split into levels, just like any other protocol, but using the term 'layers' for these levels doesn't make it OSI. BT service and protocol definitions have no relationship at all to 'true' OSI service/protocol layers.
|
|
|
|
|
I have not looked too deeply into Bluetooth as it certainly does seem as you describe it. Quite why the OP is continuing on this rather vain quest is something I also do not understand.
|
|
|
|
|
On my home Linux box I want to shrink my root 1.8 TB partition (ext4 ). Even unmounted gparted says "1.8 TB minimum size". And the GUI, accordingly, refuses to shrink it.
Googling til the end of elephanting times led me to resize2f2 how dangerous is that, in your experience?
And just trying to wrap my head around it is there "one filesystem size and one partition size?"
I actually want to reinstall the OS, and have poor experiences of upgrading. I have 0.6 TB of data, that I want to copy to a non-boot partition. and do not fancy the idea of buying storage to be used for an hour or two only. So yes I admit I am cheap and lazy, and I will never ever install Linux with such monolithic partitioning.
Thanks : )
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
When you try to resize the filesystem, are you entering numbers in the edit boxes, or using the slider? gparted won't resize the filesystem if the "Free Space Following" box is 0. Using the slider, the Free space following will automatically be filled in as you move the right-hand endpoint.
A quick google search doesn't suggest that there are any issues with resize2fs, and in any case, if you watch the gparted screen, it uses resize2fs to do its work behind the scenes, anyway.
But, as always, when modifying a filesystem, a backup of important data is wise. At the very least, go out and get yourself a USB drive of a suitable size to store your data, and back it up before proceeding. Then you're covered if the worst happens. Or if you just want to start again.
Edit: I'd add that if your drive is more than 3-5 years old you should consider replacing it anyway.
Keep Calm and Carry On
|
|
|
|