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?
The -S (stdin) option causes sudo to read the password from the standard input instead of the terminal device.
Which is what my post it about.
You run the command in code.
Then you code that code so you can control "standard input" (ie "stdin") which is exactly what I suggested via my google search.
1. Write code to run the command
2. Figure out how to use the 'stdin' input in the code. That allows your code to pass content to the 'stdin' of the command.
3. You then pass input in via that code to the command.
It would be much easier to call sudo from the terminal before you try to run whatever code itb is that you are trying to run that requires privileged access. My limited testing does not seem to allow this to be run from inside a program.
An easier option might be to configure sudo to allow the user of your program to call it without a password. The sudoers file is the place to do this. Obviously there may be security implications with this, but that is up to you to decide.
Another alternative is to set the set-user-id bit on your executable so that it automatically runs as root (using chmod and chown). Again, this has security implications to think about.
But before you do that, you should stop and think about whatever it is you think you need to sudo. As a general rule user level programs should not need to elevate privilege to perform work. That's a security hole waiting to be exploited. If you need to create a device file, load a kernel module or change permissions on a device file, that should be handled by the OS at boot time or device initialization time (eg a USB device being plugged in). Using sudo is almost certainly the Wrong Thing, and should only be considered when all other options have been exhausted.
The expression "echo ""q"" | sudo ... " doesn't do what I think you think it does. But it all works out anyway. This time. Successive string constants, with only intervening white space get concatenated together so
prints Hello World!. See. You learned something from "sidechatter"!
Member 14968771 wrote:
I need to be honest - I am getting discouraged by posters "making small talk" posts such as
...make sure you have a backup...
...it is a security issue...
To my mind, there's been very little in your previous posts that suggest you have any idea what issues you might be unleashing with your blind man with a sledgehammer approach. There's no sense that you understand what the possible consequences of your choices are. Given that, it would be remiss of us not to point out the possible pitfalls of your "solutions" ... many of which, I at least, find dubious. And most of us have "Been there, done that" in terms of making unwise or uninformed choices, and had to rebuild, repair, and recover. If we're lucky, damage to customer systems, and our reputations, has been minimal. But we learn. We grow. We pass on our insights (and war stories) to others in hopes that they will learn, remember and be proactive in areas like security before it affects them or their customer's in negative ways. It's all about an ounce of prevention being worth a pound of cure. If we can guide others away from dangers, I think we should, rather then letting the foolhardy walk unprepared into the lions den.
For example, I don't think that creating /dev/rfcomm0 as a soft link to /dev/ttyUSB0 is going to achieve what you expect. Have you tested this approach and got the results you want? Looking at this post https://unix.stackexchange.com/a/410128 regarding a missing /dev/rfcomm0, it seems highly unlikely that creating a link between what seems to be a USB serial device and what I can only assume is supposed to be a bluetooth device binding is going to work. They're completely different objects. It seems like you're trying to create a link between, say /dev/sda and /dev/console, and expect GPU I/O operations to somehow be magically interpreted to save video to the disk.
But maybe you have already done some testing and know that works. I don't know. I can only wish you luck.