[solved]do NOT update via CLI - easy to make warning script?

[catch22]

I'm used to do

Code: Select all

apt-get dist-upgrade

but realize that in Mint I shouldn't, especially since I don't have the technical skills to repair stuff (in Linux or any OS) and prefer to keep my main machine stable.
So when the old habit jumps in at 2 in the morning and I forget this shouldn't-rule, I'd like the terminal to respond to my upgrade request with something like:

Code: Select all

Are you sure you wouldn't rather use the GUI update manager? It's much safer! N/y

I guess a little script could do this?
I haven't checked the tutorials I see in this forum yet; just would like to know if it would be feasable for a newbee scripter, or a hell of a job I can forget on forehand to even attempt.

[hupnuk]

Hello catch22,

What you want to do can be done using a thing called Functions.

Code: Select all

apt-get () {
	if printf '%s\n' "$*" | grep -q '^dist-upgrade$'; then
		cat <<- 'END'
			Are you sure you wouldn't rather use the GUI update manager? It's much safer!
			y) Yes
			n) No
		END
		while read -p '#' yn; do
			case $yn in
				y )
					break
				;;
				n )
					command sudo apt-get dist-upgrade
					break
				;;
			esac
		done
	else
		command sudo apt-get $*
	fi
}

Don't worry, the code above is not as hard as it looks.

What the code above does is create a function called 'apt-get', check if only 'dist-upgrade' is given as parameter, if so, use a heredoc with cat to show some text and execute a while loop that asks you for input using read.
The while loop will repeat unless 'y' or 'n' are given.

If anything different then just 'dist-upgrade is given, it will just execute 'sudo apt-get' normally without asking anything.

If you want to run this in every terminal for your user, add this code to .bashrc in your home directory.
Files starting with a dot are hidden, so you should show hidden files for your file manager to see it.

UPDATE: Every 3 beginning whitespace's where meant to be a tab, if you run it as is, it will give a error on parsing the heredoc.
To fix, change every 3 whitespaces to tabs or remove all beginning whitespaces.

[catch22]

What the code above does is create a function called 'apt-get', check if only 'dist-upgrade' is given as parameter, if so, use a heredoc with cat to show some text and execute a while loop that asks you for input using read.
If anything different then just 'dist-upgrade is given, it will just execute 'sudo apt-get' normally without asking anything.

If you want to run this in every terminal for your user, add this code to .bashrc in your home directory.
Files starting with a dot are hidden, so you should show hidden files for your file manager to see it.

Wow! This is so much better than expected Thank you hupnuk!
I'll test it tomorrow on my older machine first (better safe than sorry )

[catch22]

I'll test it tomorrow on my older machine first (better safe than sorry )

Code: Select all

bash: warning: here-document at line 63 delimited by end-of-file (wanted `END')
bash: /home/ludo/.bashrc: line 99: syntax error: unexpected end of file

where line 63 is:

Code: Select all

cat <<- 'END'

[hupnuk]

I'll test it tomorrow on my older machine first (better safe than sorry )

Code: Select all

bash: warning: here-document at line 63 delimited by end-of-file (wanted `END')
bash: /home/ludo/.bashrc: line 99: syntax error: unexpected end of file

where line 63 is:

Code: Select all

cat <<- 'END'

Ah yes, excuse me i forgot to tell you.

I always use tabs to place indents so my scripts are more organized, but this forum converts 1 tab to 3 whitespace's, or 2 tab's to 6 whitespace's.
The error you get is because a heredoc removes beginning tabs, but not a whitespace, so cause the 'END' marker does not start from the beginning, it cannot find it and will error.

To fix this, remove or change every 3 whitespace's to tab.

[DrHu]

I wouldn't particularly agree that the terminal apt commands updating is less secure than the GUI package manager updating: they both use Apt, and even in a package manager you can see the end part of the script that runs to insert a menu item
--beyond that you can always look (specifically about applications) at their installed files and folders being used, and clean or not (no dependencies being flagged)

But for users, the cleaner appearance within the GUI may be more appropriate
--you just won't know particularly well what did or didn't work, if you don't see the whole script running via the terminal.

• As an option for users: probably not
  --anyone already using the package manager won't likely want to be bothered with an alternate approach: that's the same issue when a user wants something to function exactly as windows OS does..

[catch22]

To fix this, remove or change every 3 whitespace's to tab.

Now it's almost working, thanks
At least, it does so when doing apt-get dist-upgrade, but when I sudo the command as usual, it ignores the script and goes ahead.
I guess something about sudo should be inserted in this first bit somewhere somehow?:

Code: Select all

apt-get () {
	if printf '%s\n' "$*" | grep -q '^dist-upgrade$'; then		

[catch22]

I wouldn't particularly agree that the terminal apt commands updating is less secure than the GUI package manager updating: they both use Apt,

The Help contents of the Update Manager reads: "If you want to you can even make Level 4 and 5 updates safe (although this is not recommended)." And it gives this sort of warning multiple times.

and even in a package manager you can see the end part of the script that runs to insert a menu item
--beyond that you can always look (specifically about applications) at their installed files and folders being used, and clean or not (no dependencies being flagged)

<-- I don't understand what exactly you're saying here.

• As an option for users: probably not
  --anyone already using the package manager won't likely want to be bothered with an alternate approach: that's the same issue when a user wants something to function exactly as windows OS does..

This user is much more comfortable on Linux than on Windows but nevertheless probably a newbee forever, since I started late in life with computers and am slow at learning this kind of stuff because of not enough spare time.
I do like to use the terminal as much as possible though!
I just don't want to get myself in a mess on my main computer and want to keep it as stable as possible.
I have older machines to experiment with, where I don't mind trying out more recent kernels, testing or unstable apt-pinning stuff and what have you; they can break - it doesn't matter.
But on the main machine I want to play by the rules the safe way.

Perhaps I overestimate the risk of using, as they're called in Mint's Update Manager, level 4 and 5 updates?

[tdockery97]

Doing Level 4 & 5 updates with Mint Update Manager will install a newer kernel if one is available. The reason this is considered "unsafe" is a newer kernel could cause serious problems with things like your graphics driver. That's why the update manager is set to only Level 1-3 by default.

Running "sudo apt-get dist-upgrade" in terminal will bypass the GUI update manager's safety features and install all available Level 1-5 updates.

[catch22]

Doing Level 4 & 5 updates with Mint Update Manager will install a newer kernel if one is available. The reason this is considered "unsafe" is a newer kernel could cause serious problems with things like your graphics driver. That's why the update manager is set to only Level 1-3 by default.

Running "sudo apt-get dist-upgrade" in terminal will bypass the GUI update manager's safety features and install all available Level 1-5 updates.

Thanks, but I do know all that; I guess you didn't read the whole thread

[hupnuk]

To fix this, remove or change every 3 whitespace's to tab.

Now it's almost working, thanks
At least, it does so when doing apt-get dist-upgrade, but when I sudo the command as usual, it ignores the script and goes ahead.
I guess something about sudo should be inserted in this first bit somewhere somehow?:

Code: Select all

apt-get () {
	if printf '%s\n' "$*" | grep -q '^dist-upgrade$'; then		

Sudo spawns a new bash process in root and does not enherit the functions and some variables of the lower users, for security reasons.
In other words, this function exists in your account, but not in root/sudo.

I already added sudo to the function, just use apt-get without sudo.

While i understand you want to keep your system stable (for grandma perhaps?), do remember security is also important to keep exploits away.
The packages for linux, xorg and kernel are the most risky and can be held back using 'apt-hold', but the rest is much less, even more since Debian, Ubuntu and Mint team tests them.

[catch22]

Sudo spawns a new bash process in root and does not enherit the functions and some variables of the lower users, for security reasons.
In other words, this function exists in your account, but not in root/sudo.

That's a pity because the script is of no use to me then (too much in the habit of prefixing with sudo) but I'll mark as solved just the same, since you did have a clear answer to the original question. Even including a script - that was more than I hoped for

While i understand you want to keep your system stable (for grandma perhaps?),

Mind your words, you youngster, I AM a grandfather (seriously!)

do remember security is also important to keep exploits away.
The packages for linux, xorg and kernel are the most risky and can be held back using 'apt-hold', but the rest is much less, even more since Debian, Ubuntu and Mint team tests them.

I never heard of apt-hold before, but a quick search shows it looks interesting, thanks!

[xenopeek]

Possibly you could add the function to /root/.bashrc, or to /etc/bash.bashrc, and that would make it available when using sudo also. But I propose a different approach, as also used for certain commands by the Linux Mint developers

I propose you create a file called "apt-get" in /usr/local/bin or, preferably, in the folder called "bin" in your home folder. That folder isn't there by default, but when you create it and log out and log in again scripts that you put in ~/bin will be in your path and scripts there can be run by just typing their name. Putting the file called "apt-get" in ~/bin or /usr/local/bin puts it in a place where it is found before the actual apt-get, so this script gets run instead. Then from that script as needed we call the actual apt-get.

Create the file, put the below in it, and make the file executable (after saving the file, right-click it in your file manager and on properties change it's permissions accordingly). Because copying from here does something funky with white space, I've also put it up here: http://dpaste.com/35JXKNG.txt. Please copy the contents from the dpaste link.

Code: Select all

#!/usr/bin/env bash

readonly APT_GET='/usr/bin/apt-get'

# if connected to a terminal and using an upgrade command, ask before proceeding
if [[ -t 1 && $* =~ (dist-)?upgrade ]]; then
	read -p "It's safer to upgrade with the GUI. Proceed anyway? [N/y] "
	[[ $REPLY =~ ^(y|Y)$ ]] && "$APT_GET" "$@"
else
	"$APT_GET" "$@"
fi

I've extended it a bit to ask on upgrade and dist-upgrade. You'd normally only need to do a dist-upgrade when having changed your apt sources (like when upgrading from Mint 17 to Mint 17.1) and would normally only do an upgrade. Hence including that for the check.

[catch22]

Thank you xenopeek!
I already had a bin folder in home, but there it didn't work for some reason (even though I set it as executable first, before logging out/in).
Placing the file in /usr/local/bin/ did the job.

I see you live in a neighbouring country; whenever you visit Antwerp - the beer is on me

[xenopeek]

Doh! The addition of ~/bin to the path is of course forgotten on running it with sudo

[hupnuk]

propose you create a file called "apt-get" in /usr/local/bin or, preferably, in the folder called "bin" in your home folder. That folder isn't there by default, but when you create it and log out and log in again scripts that you put in ~/bin will be in your path and scripts there can be run by just typing their name. Putting the file called "apt-get" in ~/bin or /usr/local/bin puts it in a place where it is found before the actual apt-get, so this script gets run instead. Then from that script as needed we call the actual apt-get

Oh nice, i did not know about taking over system binaries via local binaries in home, good idea.
Confused though how that works though, it is not included in the "$PATH" variable, i do not even know the name of that function?

I already had a bin folder in home, but there it didn't work for some reason (even though I set it as executable first, before logging out/in).
Placing the file in /usr/local/bin/ did the job.

The reason it did not work is cause the moment you use sudo, most root environments are used, not your users, except some set variables though.
Adding to /root or /usr/local works, but then everyone has the that question since sudo gives root, though i think that is what you want.

Mind your words, you youngster, I AM a grandfather (seriously!)

Oh lol, i'm sorry wrongly conceiving your age .

Well, in anyway, the question is solved.

[xenopeek]

I got it wrong twice I think; /usr/local/bin is at the front of your $PATH. So any script you put there with the same name as another file in one of the later folders in $PATH, is found first. ~/bin is by default added at the end of $PATH... Doh. It's only useful for your own scripts, not for "overriding" system files. For that you use /usr/local/bin.

[hupnuk]

I got it wrong twice I think; /usr/local/bin is at the front of your $PATH. So any script you put there with the same name as another file in one of the later folders in $PATH, is found first. ~/bin is by default added at the end of $PATH... Doh. It's only useful for your own scripts, not for "overriding" system files. For that you use /usr/local/bin.

Hmm, it seems "$HOME/(system folder)" is only added to $PATH after you created a folder 'bin', 'usr', 'etc' in the home folder and relogged the user, sums it up why i couldn't find it.
I know it is not useful for overriding system files systemwide, cause everything in a home folder should only affects the owner of it.

I've extended it a bit to ask on upgrade and dist-upgrade. You'd normally only need to do a dist-upgrade when having changed your apt sources (like when upgrading from Mint 17 to Mint 17.1) and would normally only do an upgrade. Hence including that for the check.

The option 'upgrade' in 'apt-get' does a upgrade of all packages, but will not remove any or add new packages.
I recommend using 'dist-upgrade' when you can though when doing upgrades from cli to not cause breakages or packages not being upgraded if any dependency would need to be added or removed.

The mintUpdate manager uses dist-upgrade, but with a update risk level list.