@Videonauth Are you still looking for feedback? Currently the question has only one downvote.

The comment about how people probably don't want to upgrade all their packages to the latest versions--which was false anyway, people usually do want to do that, and the StableReleaseUpdates policy combined with the general importance of installing security updates means people should upgrade every package to the latest version available for their system except when they have a specific reason not to do so.

muru changed it to use the intall action. You may want to mention running sudo apt upgrade as an alternative, though, if they want to upgrade other packages, which they should do too. As Byte Commander mentioned in AUGR, you don't need the dist-upgrade action because with apt (but not apt-get) the upgrade action is configured by default to allow new packages to be installed as dependencies. dist-upgrade allows packages to be removed too, which is often not desired.

My guess is that the comment where someone said they were downvoting was removed as obsolete, either by its author or through flagging. I don't think one can assume one way or another whether it was that comment's author or another downvoter who removed their downvote. I don't know what the remaining downvote is for. I wouldn't downvote that post, either before or after the edit.

If you like, I'll read it more closely though and see if I can come up with any other ideas for improving it (besides mentioning that they might want to just run sudo apt upgrade rather than sudo apt install firefox (which applies to the edited version and didn't apply at the time you had requested my input).

@Videonauth For Way 1, on Ubuntu 17.10, will such systems actually have that .deb file in /var/cache/apt/archives after being installed from a live environment? It is not clear to me why it would. Did you test this on 17.10 and, if so, how did you create the installation on which you tested?

As a separate matter, in the post you say:

> but if in doubt holding/unholding firefox* will do it too and all additional packages beginning with firefox

At minimum I recommend writing it as firefox\* or 'firefox*' or stating that the * should be quoted in the shell. But also, do the hold and unhold actions treat that as a glob for a whole package name? Or do they treat it as a regular expression to match any substring of a package name? (Or do they try to treat it as a glob and then try to treat it a regular expression if that fails?) Do hold/unhold treat it as list does or as install, remove, purge, and autoremove do?

Also, the paragraph with that text is hard to understand. You may want to reword it, split it into two paragraphs, or move the idea of holding firefox* (with the *) either to the first place holding firefox is mentioned or down into a footnote that is cited where firefox is mentioned, or just make it an afterthought that appears near the end of the post. I would've edited to reword that paragraph but I don't want to obscure the main issue of whether or not firefox* is correct.

@EliahKagan i did create a VM with pure fresh installed 17.10 and updated it, deleted the cache and reinstalled with exact that command, but yes as long you not choose to update while installing you having 56 in your archive

@EliahKagan yes the comment got finally removed due to flagging as no longer needed, but first it was there for a long long time while other coment flags got processed quickly

norberts answer should not have so many upvotes if you ask me, because it not adreses the question, it is more like as you would go to a mercedes benz dealership to buy a mercedes, and the dealer is telling you "hey you not want a mercedes benz, you want a caddilac, but for that you have to move your big bum 5 blocks further downtown"

I can tell you who did the other downvote on my answer, as he did on all other answers too which competed with his one

and the question was what is the most straight forward way to downgrade FF57 to FF56 and not what is a good replacement for firefox56 / 57

thank you for the rest of your input, will revise my answer according to it later, I'm actually on mobile

@Videonauth Ah, I see. It's not that a .deb for that version is present already on a freshly installed system when the Ubiquity installer is used--as I had wrongly thought you meant--but instead that it's still in the repository, so apt-get can download it. Do you happen to know how long it will be kept? Will it always be in the repository, because it was the version of the package that shipped with 17.10? Or will it be removed eventually, as superseded packages sometimes are?

@EliahKagan for 17.10 it will be kept till it dies, since 56 was the delivery version with which 17.10 got released

as i stated for the other versions in the note, there is always be the version with which the different releases got delivered, on 16.04 it is FF 45

so for 16.04 `sudo apt-get install firefox=45.0.2+build1-0ubuntu1 will always work untill EOL

Thanks. I wasn't sure if original package versions always remain on the server, since updated versions that are superseded by other updated versions within the same release are not usually kept. It makes sense, though, that a package would only be considered superseded for purposes of removal from the download servers if it is superseded by another package version in the same pocket (e.g., a package in artful-security getting replaced with another one in artful-security).

yep

hahaha wow unix.stackexchange.com/a/404143/166226 58 UV, this still baffles me

I am confused by this comment...

@Zanna request further explaination, i'd say

as it is now i cant get the connection from the comment to your post

yeah :) but I think I'll wait a while before doing that to see if I understand what they mean later

oh maybe they mean the answer implies that single quotes only suppress parameter expansion, not other expansions

@Zanna Of course, that doesn't directly answer the question of why ksh93 puts the signal number itself, rather than the signal number plus 256, in $? when it comes due to pipefail from a crashed command in a pipeline. I don't know for sure why this happens, but even in ksh93 all but the last command in a pipeline run in subshells. Suppose the subshell terminates and actually attempts to return 256 + N as an exit code, where N is the signal number of the crashed process.

what would happen then?

Then all but the low-order byte are truncated and the calling shell (the outer shell) receives just N.

So that could be the reason...

do you get the same result with ./crash on the right side of the pipe?

No. That's not a situation where set -o pipefail makes a difference. The rightmost command in a pipeline is normally what determines the pipeline's exit status. The result is 267.

so that supports your idea

does the shell still crash itself?

When the exit status was 11 instead of 267, the shell does not crash itself. It only crashes itself when the exit status is above 255. I don't know the precise details. I think it only treats the last exit status as eligible to raise a signal if it is below some number, like 384 or 512.

Actually it's when it's strictly higher than 256 but less than or equal to 320.

But he then commented on this bug report to say "ksh93's behaviour is the behaviour that will likely be recommended by POSIX..." Anytime Stéphane Chazelas and I disagree about shells, it's hard for me to imagine that I could be right. Yet I cannot think of any way he could be correct about this. This is the formal proposal he linked to.

I believe Stéphane Chazelas was correct, in the sense that the likely text of the forthcoming standard requires that if a shell represent crashes with exit statuses above 256, then they must raise a signal when the shell exits an $? is such a value.

The recommendation in the notes section differs significantly from the proposal itself. Anyway, none of this defends the practice of returning the signal number itself in the pipefail situation we've been talking about. But both the proposal by Geoff Clare (linked above) and this answer by Stéphane Chazelas state that "older versions of `ksh93`" would always return the signal number itself.

That is, the exit status would be above 256 and it would get truncated when the shell exits.

So I suspect that this pipefail situation is actually a bug in ksh93, or the last vestige of the old bug where those exit statuses got returned and truncated all the time. The draft's recommendation to refrain from generating a core dump when it does crash itself seems to be followed in ksh93 Version AJM 93u+ 2012-08-01 on my FreeBSD system where I have core dumps enabled for all crashes.

As for whether or not the current standard's requirement that $? be over 128 when a command is terminated by a signal, I don't know if that -- or really, any -- requirement applies when shopt -o pipefail has been used, since that's a nonstandard shell option (though several shells support it). I presume such options are permitted to change the behavior of a shell.

It's worth reading the proposal especially since it explicitly discusses the optimization we found where the shells avoids forking on the last command run. This is an argument for ksh93's behavior, after all, because it makes it seem to work the same when ksh93 runs a last command that crashes and when it replaces itself with a last command that crashes. Since ksh93 doesn't (usually? ever?) make a real subshell for ( ) grouping, I wonder what all the circumstances are when it does.

If I can test other ones under crashing, I should be able to figure out what's going on with the pipefail situation where unmodified signal numbers become the exit status of the whole pipeline.