Terminal window - kde
>su
[password]
#
#exit
>exit
[close window]
How do I do this within a script using the ‘exit’ command?
exit;exit
exit && exit
eval 'exit;exit'
No effect
It’s hard to guess what you are really asking.
“exit” terminates a shell. If you are running a script, the script is normally run in a subshell, so exit terminates that subshell.
If you run: some-script
in a window, then when the script ends, you are still in the window.
If you run: exec some-script
then when the script ends, that’s the last thing done and the window will probably close.
The downside is that if there’s a bug in the script, the window may close on that, too, and you won’t see the error message.
But I don’t know whether I have answered your question, because I’m not sure what was the question.
Run the script as a cron job.
Hi
Cron is dead… 
Use a systemd timer going forward, Or just tie the systemd service running the script to the system timer… run as a one-shot should work fine.
Oh dear! It seems that, I’m “riding dead horses” … >:)[HR][/HR]US American Indian anecdote: “If you suspect that, your horse has died, dismount.” – From the legends of dead Software Projects which were not closed down …
the answer su starts a new shell as root - if you add ; exit there - exit will exit both
as a shortcut you an add an alias to your profile alias su=‘su ; exit’ that will do the same when you type su
like this:
su ; exit
.
.
.
exit
Not about the original subject, but about the usage od su.
Always use
su -
Only if you want to be in the root’s home and environment and not the user’s home directory and environment.
And it is good practise to always want that. It is a security risk to use a user’s envorinment as root. And when you want to make a user’s home directory as your working directory (which is not normal where you need to use root for, except when that user created a mess that only root can repair), root cd into that home directory after “becoming root”.
In other words, the “Konsole” application – if you were to use “KSysGuard” to inspect the systems processes, you’ll find a process named “konsole” with a “Parent Process” – in my case “krunner” – hover the Mouse over the text “konsole” in the KSysGuard “Process Table” tab.
For each active tab in the Konsole Window you’ll find a “bash” process.
- For the case of a “normal” user, the Parent Process is “konsole”.
- For the case of the user “root”, the Parent Process is “su”.
Do you want to only close the active tab in the Konsole Window or, the Konsole Window and all the active tabs in that Window?
If only the active tab in the Konsole Window then, you’ll need to kill the “bash” process which is calling the script – the “Parent Process” of the process where the script is executing …
- If you determine the PID of the script’s process then, grep the output of “cat /proc/«script PID»/status” for “PPid” – then kill the “PPid” process …
I know, I know – the script commits suicide …
Maybe, but, the openSUSE YaST automatic online update still uses cron jobs:
# l /etc/cron.daily/
total 20
drwxr-xr-x 2 root root 4096 Jun 4 12:35 ./
drwxr-xr-x 148 root root 12288 Jun 2 15:00 ../
lrwxrwxrwx 1 root root 32 Jun 4 12:35 opensuse.org-online_update -> /usr/lib/YaST2/bin/online_update*
-rwxr-x--- 1 root root 2029 Oct 29 2018 suse.de-rkhunter*
#
That is of course only true in the most simple use case, but that might be sufficient for the OP (I have no idea).
There can be any text oriented program there, other shells then bash to begin with, but other programs are possible also.
E.g.:
konsole -e vi /etc/hosts
or
xterm -e /sbin/yast
As far as I understand it, systemd simply took over control of the cron files/configurations. And I assume that thus “using cron” will be supported by systemd for a long time to come. Think of all those legacy systems where some may have hunderds of cron jobs specified in either system or user crontabs. When that would stop functioning …
Hi
Never seen that on an openSUSE system here? Either the cron entry or anything online_update* that is just crazy running an update automatically without review.
It’s official: <https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha-onlineupdate-you.html#sec-onlineupdate-you-automatically>.
It’s needed for unattended systems and, for those who trust the OpenQA procedures …
- But, yes, for a network of managed systems, the repository mirror should be a local filtered one – only reviewed patches and updates to be applied by the per machine automatic procedure.
- The SUSE advantage is, there’s an admin tool to distribute the patches and updates to the (thousands of
) machines being managed …
A couple of years ago, there was an openSUSE Conference session on this (SUSE) topic …
Hi
Yes, well aware of the tools… I use it here… SUSE Manager… I stage my updates and push to my SLED and SLES systems. Most folks use salt these days. You can also use RMT on openSUSE.
You don’t. Isn’t it the realm of system admins to run this however they see fit anyway? I don’t think you as an application provider should make any assumptions about that.
It’s linux - you can make it do anything that is programmable. This is not impossible - it is possible - I do this on remote support of 1000’s of SUSE machinesI ssh into - I have to because they run with no GUI (all run level 3).
using su ; exit will you tell the terminal to exit after the superuser command.
according to some su - ; exit is better choice
I would recommend that you add an alias to the end of .bashrc file
alias suz="su - ; exit"
and use the suz command to do that - you can call it anything you want even su - if you call it su and do not want to exit you will have to type /usr/bin/su to avoid the alias.
you will have to logoff and back on to see the alias take effect.
Create a start menu item or other program starting icon with as the command something like
/usr/bin/xdg-su -c '/usr/bin/konsole -e your-text-oriented-program and its arguments'
Example:
/usr/bin/xdg-su -c '/usr/bin/konsole -e less /etc/hosts'
When you are finished looking at that interesting output, hit q to end less and thus to end konsole.
I’m sorry but you’ve misunderstood my utterly synthetic “You don’t”. OP was very specific: “How do I do this within a script using the ‘exit’ command?”. You don’t. It wasn’t an attempt to give a solution to OP’s undisclosed needs. Most didn’t pay attention to the within a script part (on purpose or not), which is saner as a matter of fact. Some noticed OP was about avoiding typing both ‘exit’, not just one. Then I gave some advice I’d like to receive when I’m pursuing a path I shouldn’t. Apart from telling if a tty is present or not, a script/program almost never should attempt to guess the environment, even less end the parent process (per OP request). It makes the program less portable, which is a requirement OP shared later on on the thread. Maybe a terminal, or su, or bash, are not even required. The less assumptions the script/tool makes about the environment, the better systems admins can do their jobs.