Nobody is going to be able to help you because you haven't shown the code you've written that has the problem nor even described a problem! Just showing up to a forum and saying "it doesn't work" is a complete waste of your time.
You are assuming that hcitool controls that. Versus just reporting on what is there.
If there is a way to return other attributes you might be able to identify it that way.
I have not worked with this protocol but I have worked with many others so I suggest that you do not assume that your testing by itself will return all possibilities. A general solution might either be coded only to support limited scenarios (those tested) or must provide a way to monitor/report when it is not found, what is found, and potentially a way to configure/add more info to a running app.
The linux command whereis has no recursive invocation. From the man page:
whereis locates the binary, source and manual files for the specified command names. The supplied names are first
stripped of leading pathname components. Prefixes of s. resulting from use of source code control are also dealt with.
whereis then attempts to locate the desired program in the standard Linux places, and in the places specified by $PATH
Maybe you're thinking more of find, which searches given directories for a file matching a pattern? e.g. find $HOME -name 'mumble*.cpp'. Or maybe locate which will find files anywhere on the system that you have access to (i.e. the results for user1 may be different from user2, and both may be different from root)
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
Well part of it is, which provides the actual kernel interface and drivers. The other part is the user space components which provide for the developer access. More details can be found at BlueZ » About[^]. You cannot bypass the library, since user space code cannot use Kernel features directly.
I have "upgraded" to Ubuntu 23.04.
"Discovered"it is lacking Bluetooth.
Used this opportunity to test "verify Bluetooth " in my code using "bluetoothctl".
The command responds correctly , but "gets stuck "
in "Waiting to connect to bluetoothd...".
Used same command in "terminal" with same result.
Can somebody suggest similar command or "bluetoothctl"command option (timeout ?)so it does detect lack of Bluetooth, but does not get stuck.
Temporary , I do verify Bluetooth not working by looking for "Agent registered " failure - which is correct response when Bluetooth is OK, actually running. Then if it runs I can "exit" from command.
Help is much appreciated.
Waiting to connect to bluetoothd...
I certainly cannot find a way to change a timeout for it.
Presumably this is your actual situation since it was not clear whether you fixed the first.
1. Bluetooth is not installed
2. You ran the command.
3. It blocks.
Given that then in terms of error detection for a tool you would need to do the following
1. Code something that can run the command asynchronously such as a thread.
2. The caller initiates the call with a timer (that will expire.)
3. If the timer fires a timeout then the tool reports 'bluetooth not found'
4. If the command returns (before the timeout) cancel the timer, then process the results from the command.
Sorry for delay, had to move my PC and it all broke. Appreciate both suggestions, will use both. While testing, found out that some commands requires "boot access" on "check if enabled" and no "root access" "enable service" -- weird and incontinent.
That's pretty clear. You need to tell bluetoothctl how long to wait e.g. bluetoothctl --timeout 2 should time out after 2 seconds. Who knows, maybe you could even use a floating point value e.g. --timeout 1.5 for finer grain control.
Normally, though, a long option is specified as --timeout=2, so you might try that as well if the above does not work. I've checked a few of web sites, but none of them were able to help in this regard. Still a little experimentation on your part should clear that up. When you get it sorted, maybe post a note the to the maintainers that it needs to be explained better.
So you're suggesting I knock my core count down to below 8, say 7 ..., reboot then fire up that linux programmer's 64-bit windows app which can't see any architecture above 2 gigastories and try rendering at level four and everything will turn out all right?