I have several desktop launchers that launch bash scripts as follows:

command: bash <path_to_script> <parameters>

The launchers (and scripts) worked with Mint 18.3 and 19.0, but they do NOT work with Mint 19.1. If I enter the command from a terminal window they DO work.

After a lengthy debugging session, I determined that (when launched from the desktop) the scripts fail when a "sudo" command is reached, presumably because there is no terminal from which to obtain the password. The "solution" to this would appear to be to use gksu instead of sudo, but

1) gksu is deprecated and no longer available

2) If I launch the script with gksu, the entire script runs as root, which could be dangerous.

3) Alternately, if I change each "sudo" command to "gksu", I would have to enter the password multiple times during the running of the script.

4) Why/how did these scripts work from the desktop launchers before? Did Mint simply ignore the password requirement?

5) Is there another solution than gksu? I saw something about adding an ADMIN prefix to the command(s), but the "instructions" for using it weren't very helpful.

for me it looks strange. But instead of su you might want to try sudo.

Thank you, but (as clearly stated), I am using "sudo", not "su". If, by "su" you are referring to gksu, gksudo is the same.
------------------------
A program will ALWAYS do what you wish if properly implemented!

sudo does not need terminal. Only if you want to ask password. But you can configure it to avoid that.

I don't think you understand the problem described above. I don't want to disable passwords for sudo (why would anyone?). I just want to disable it for several commands in a single script that is run via a desktop launcher, which worked under previous versions of Mint.

Yes, probably. But if you think the missing terminal is the problem you could try passwordless sudo. Just to test if that works.
I think there is no regular tty available (when you use launcher), therefore sudo must die (if it need password to continue). You need to find a solution which will use DISPLAY (and GUI) to ask. This is called pkexec: https://unix.stackexchange.com/quest.../203149#203149

I KNOW the missing terminal is the problem, as I have verified this with testing. What I don't know, and which I asked above, is why it worked with previous versions of Mint (which apparently do not require a password for sudo when there is no terminal). Yes, I know that there is not tty available when a launcher is used. gksu/gksudo solve the problem, but (as stated above) create additional problems. PKEXEC seems to be a much more complicated method to do the same thing. I'll just use gksu to launch the script AFTER I've tested it thoroughly and know it isn't going to accidentally overwrite the system.

What others think about it:
https://askubuntu.com/questions/7835...vs-gksu-gksudo
https://forums.mageia.org/en/viewtop...=10058&p=58164

I don't think that this issue is limited to the use of sudo. I have a script that doesn't use sudo but similarly runs correctly in terminal but not from a program launcher. The script is identical to that used in Mint 19.0 before upgrading to Mint 19.1. In my case, the problem is that the script isn't pausing on a read command. I can simplify the script as follows so that there are only echo and read commands:

#! /bin/bash
echo "Shell command complete"
read

Running this test script from terminal cause the script to pause before the terminal window is closed or Enter is pressed. When the script is run through a program, no terminal window is displayed and the script simply terminates in the background.

It makes sense that a script run from a launcher won't work if there is a read command (or a sudo command that requests a password via a read command), since there is no terminal from which to display a message and/or read a response. So the real question is why it worked before?

In the case of sudo, I'm speculating that it did NOT prompt for a password when run from a desktop launcher, but now it does. Alternately, because sudo retains the password for a small time frame, perhaps coincidentally I ran sudo (and entered a valid password) from a terminal, and then ran the desktop launcher script within the time frame?

I have no idea how your read command would have worked before, unless it simply returned a null response, because there is no terminal input device to read from when you run a script from a launcher. That's why we use zenity for I/O instead of print and read commands.

Launching my script with sudo or gksu or gksudo "solves" the problem, but then the entire script runs with root privileges, rather than just the three sudo commands. For some reason, the script doesn't work properly when launched with pkedit, probably because of the need for an overly-complicated "profile" with pkedit.

But none of these will solve the "read" problem you describe.

I have no idea why it worked in previous versions of Mint, but it did. However, I found a solution (or at least a workaround) to my particular problem in an old post on AskUbuntu.

The trick is to use the following command in the program launcher: gnome-terminal -e "bash -c ~/test.sh; bash"

See the answer posted by Karsvo in: How to run a script without closing the terminal?

that works because gnome-terminal creates a new pseudo tty and bash can use that.

When I call gnome-terminal -e I get a warning :-

Option “-e” is deprecated and might be removed in a later version of gnome-terminal

So I feel it is rather worrying to rely on for a long term solution.

This is a major issue for me as I have a large number of desktop icons (mostly organised within desktop folders) launching bash script files. The latter always start with a line #!/bin/bash

Many of them are either invoked via sudo (whole script) or contain sudo within the script. They have worked perfectly on Mint 17.3 and Mint 19 and sudo always prompts for the password the first time it is called from any particular script - usually it is only once anyway.

Most also call read to pause the script to allow viewing of the terminal window and to allow questions to be displayed and answers supplied. Again this has all worked perfectly under Mint 17.3 and Mint 19.

I did an in-situ upgrade from Mint 19 to Mint 19.1 [ having first run my total backup script of course ]. The upgrade went quickly and without incident. However running on Mint 19.1 I immediately found that none of my launchers calling a bash script worked.

I reverted to my Mint 19 backup and all the launchers are working perfectly again.

This is the exact same problem I reported at the beginning of the thread. I've tried various other suggestions, but none of them work. When a script containing "sudo" is launched with gnome-terminal, pkexec, etc., the script doesn't work, presumably failing when it reaches a "sudo" command, just as it does without the suggested fix. The only thing that works is to launch the script with "gksu", but that means the entire script runs with elevated privileges, rather than just the "sudo" commands, which could be dangerous if the script isn't thoroughly tested.

I really wish the Linux and Mint developers would spend more time testing their code before releasing it, and document their deliberate changes, so we wouldn't have to do their debugging for them, and/or rewrite our code to comply with arbitrary changes.

P.S. In their infinite wisdom, the developers have now omitted "gksu" from Mint and from the "repositories". It can still be obtained and installed as follows:

you need to use pkexec instead of sudo (not together).