I'm accessing serial ports in linux, which means the program needs to run as root, or I gotta know if the user has rights to use tty, else synaser will try, but the program won't crash or anything, it just won't communicate...I think you can give permision to your user, to user serial port.
As such, with gksudo now gone etc, here's my code to self elevate, which doesn't work and I don't know why.... I have found that it's extremely hard to visualize what the command line is going to look like in order to figure out why things fail in both linux and windows. I wish it was as easy as it looks in the memo.
sudo chown username /dev/ttyACM0
I'm accessing serial ports in linux, which means the program needs to run as root
- echo is a shell command, not a program you can run; and
Careful there. It's one of a number of commands which exist as both shell intrinsics and binaries on disc, so can be confusing.
Careful there. It's one of a number of commands which exist as both shell intrinsics and binaries on disc, so can be confusing.
Yes, you're right, but the shell one (if it exists) usually supersedes the independent one, more so for simple:lines, without options.
Yip, after I posted and retired to bed I realized that bash was doing the piping so I leaned/dreamed very heavily towards exactly what Lucamar posted....
Unfortunately that still fails with no a clue as to why? It's Linux Mint 19.3 Tricia and bash is the default shell, yet perhaps the path is not there? How would I know?
Even this still fails silently!
As I said, it's very hard to understand what goes wrong with tprocess without it telling me something like, "Hey you, I couldn't find that bash thing you were looking for." Though I should probably just start piping the shelled data back to the tmemo to try to find out what may be happening.
Yes I should be using the properties Executable and Parameters, but as per the commented memo.append line, the tprocess.commandline resembles that tmemo.append syntax exactly, thus eliminating a stray space, or some such anomaly, that has ruined many of my past shell attempts. Thus, with a quick cut and past from a visual text representation of tmemo that works when cut and pasted into a bash prompt it's an easy thing to do. So again how does bash echo ' + password + ' | sudo -S "' + paramstr(0) + '" not work???
As far as the philosophy of linux and it's permissions, there's no point in arguing any of that especially when folks find it necessary to criticize an entire premise based on a single portion of an extreamly mal-constructed sentence designed to convey the exact nature of the Linux beast.. And so, as MarkMLI explained and explained and explained, thereby again proving why such a user unfriendly beast should be tamed by a fool such as I for the sake of the world; the facts are this: Linux and it various flavors have throwbacks to that of electronic typewriters tty's. When a user sits down at a linux box they are usually allowed to surf the web, yet they're not allowed to access to an antiquated serial interface!! To to fix that programmatically without administrating every box that my software my hit root is required or the user themselves must be savvy enough on their own, which is quite plainy found written in my message to the user via the password box....
Yip, after I posted and retired to bed I realized that bash was doing the piping so I leaned/dreamed very heavily towards exactly what Lucamar posted....
As far as the philosophy of linux and it's permissions, there's no point in arguing any of that especially when folks find it necessary to criticize an entire premise based on a single portion of an extreamly mal-constructed sentence designed to convey the exact nature of the Linux beast.. And so, as MarkMLI explained and explained and explained, thereby again proving why such a user unfriendly beast should be tamed by a fool such as I for the sake of the world; the facts are this: Linux and it various flavors have throwbacks to that of electronic typewriters tty's. When a user sits down at a linux box they are usually allowed to surf the web, yet they're not allowed to access to an antiquated serial interface!! To to fix that programmatically without administrating every box that my software my hit root is required or the user themselves must be savvy enough on their own, which is quite plainy found written in my message to the user via the password box....
But, do you really want to execute your whole program as root?
But, do you really want to execute your whole program as root?
That's one of the key things. Unix doctrine is to give a program as few rights as possible, and the capabilities mechanism was specifically added to make this fine-grained. If the requirements of the program /demand/ that access to a device be granted by a password, then it would be far better to organise it so that this granted a single extra capability (which is removed as soon as the device has been opened) rather than making the whole thing root which /will/ eventually cause problems.
Spot on. This is also why daemons which need to bind to low ports start as root but then switch to a non-privileged user after accomplishing that. Anything else introduces a serious security issue. Expecting any user to run a user application as root is just so wrong on so many levels, quite apart from the assumption that a normal user has root access.
Actually, in Debian at least there's been some "give and take" over the last few years.Be careful, total nonsense. Debian has become MORE strict, not less.
Actually, in Debian at least there's been some "give and take" over the last few years.Be careful, total nonsense. Debian has become MORE strict, not less.
You are playing a Trump? IOW really inexcusable nonsense. >:D >:D >:D
Apart from the user, you need to add to the group that has sufficient rights first and then add to the device group.