Since `tr` converts lowercase to uppercase according to system locale using `LC_CTYPE` environment variable; on some locales, rustup.sh fails to use correct variables names, thus deletes temporarily downloaded files and gives a meaningless error as shown below. This a simple fix which explictly sets `LC_CTYPE` as `C`.
The timezone of the server that builds rustc nightlies
appears to be in UTC. From what I can tell, it builds
the nightlies at 0300 UTC, which takes about ~15 minutes.
So, there were a couple options here for which offset to use.
UTC+3 would ensure that you always got the latest rust, but it
would mean the script is broken ~15/20 minutes a day. UTC+4
means users get a stale nightly for 45 minutes, but that feels
okay to me.
Ideally, buildbot would publish the "current" nightly, but
that seems unneeded relative to fixing it for all Timezones
quickly.
Fixes#21270
This way installer can work fully in offline mode.
Put pre-downloaded files
(rust-nightly-x86_64-unknown-linux-gnu.tar.gz and
rust-nightly-x86_64-unknown-linux-gnu.tar.gz.sha256)
into the $HOME/.rustup/YYYY-MM-DD directory
as it would be done by script itself.
Specify --save and --date=YYYY-MM-DD when running.
Files will be picked up and used to install in offline mode.
Was testing rustup on a very minimal Debian installation and got errors during the install process (error occurred in `install.sh` of the Rust nightly.)
Noticed that Rustup was downloading the i686 nightly instead of x86-64. Installing `file` fixed the problem, and this patch adds the probe to ensure file is installed before attempting to use it.
There may still be an issue with the i686 installation, I did not investigate further.
This closes#19168. It's possible that if the downloading of `rustup.sh`
is interrupted, bad things could happen, such as running a naked
"rm -rf /" instead of "rm -rf /path/to/tmpdir". This wraps rustup.sh's
functionality in a function that gets called at the last time that should
protect us from these truncation errors.
Using the current directory may not always be appropriate, for example in
the case where it will unnecessarily trigger a backup to be made.
The only risk with this change is that systems might not have a mktemp.
I am not aware of such a system, but have not tested on Windows. It is
working on a basic Ubuntu and OS X installation.
