Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Updating Cygwin

Joe Caverly

Joe Caverly

Aug
1,929
71
I like to keep my Cygwin up-to-date, which I usually do once a week.

I have been using the following .BTM for the past few months, which works well for me, in keeping Cygwin up-to-date;
Code: 
@setlocal
@echo off
cdd C:\Users\jlc\Downloads\cygwin
copy https://www.cygwin.com/setup-x86.exe
setup-x86.exe -q -g
endlocal

Note that this is for the 32-bit version of Cygwin.

Thought that others might find this useful.

Joe
 
I also use Cygwin (64 bit), but I only update once a month or so. I made some minor changes to your script, and it works well for me. It does need to be run in Admin mode, which is funny because when I run it manually it doesn't need to start as Admin. I suppose when run manually it elevates by itself.


@setlocal
@echo off
cdd C:\cygwin64
copy https://www.cygwin.com/setup-x86_64.exe
setup-x86_64.exe -q -g
endlocal
::
:: use sudo to run as admin
 
Except the call to "ssh-pageant.sh" wrapper, it all could be used literal.

Code: 
@ECHO OFF
SETLOCAL

IF "%[_ELEVATED]" == "1" GOTO :RUN
ECHO Restarting elevated.
START "" /MIN /ELEVATED "%~0" %*
EXIT /B

:RUN

"ssh-pageant.sh" -k
gpgconf --kill gpg-agent dirmngr scdaemon
UNSET STOP_SVC
UNSET START_SVC
DO svc IN /P cygrunsrv --list
  IFF "%[svc]" == "cygserver" THEN
    SET "START_SVC=%[svc] %[START_SVC]"
    SET "STOP_SVC=%[svc]"
    ITERATE
  ENDIFF
  SET "START_SVC=%[START_SVC] %[svc]"
  net stop "%[svc]"
ENDDO
IF NOT "%[STOP_SVC]" == "" net stop "%[STOP_SVC]"

:SAFETY
REM Crude test for other Cygwin processes running.
IFF "%~1" != "--force" THEN
  IF %@EXECSTR[ ( ( ps -al | grep -vE "\<%@INSTR[5,,%@EXECSTR[tty]]\>" ) | TEE CON: ) | wc -l ] GT 1 (
    ECHO There's likely other processes running from Cygwin environment.
    ECHO Please stop them or use --force to suppress this test.
    GOTO :RESTART
  )
ELSE
  SHIFT
ENDIFF

REM Cygwin upgrade helper script.
REM Usage:
REM
REM   install-cygwin.btm [--force] [-ns]
REM
REM If you intend to use it for new installs, you will need minimal bootstrap
REM including POSIX shell interpreter and wget utility.
REM
REM You will have to edit the script to provide mirror URL of your choice
REM or set CYGWIN_MIRROR environment variable to the mirror URL.
REM
REM The script assumes existing installation of the same architecture as
REM the host operating system.
REM If you want to install 32-bit Cygwin on 64-bit host, override
REM $ARCH with value other than "x86_64".
REM F.e.
REM
REM   SET ARCH=x86 && install-cygwin.btm

IF "%[CYGWIN_MIRROR]" != "" SET "MIRROR=%[CYGWIN_MIRROR]"
IF "%[MIRROR]" != "" GOTO :ARCH
REM Mirror URL - don't include trailing slash!
SET "MIRROR=https://mirrors.kernel.org/sourceware/cygwin"

:ARCH
REM System architecture.
IF "%[ARCH]" != "" GOTO :LOCALE
SET "ARCH=%@EXECSTR[ uname -m ]"

:LOCALE
REM Localization is fine... as long as you don't show it to other people.
SET LANG=C.UTF-8

IF "%[ARCH]" != "x86_64" SET ARCH=x86

wget -N "https://cygwin.com/setup-%[ARCH].exe"

REM Skip running setup on "NoSetup" switch
IF "%~1" == "-ns" GOTO :RESTART

".\setup-%[ARCH].exe" -O -s "%@RTRIM[/,%[MIRROR]]/" %[KEYS] %$

:RESTART
DO svc IN /Q %[START_SVC]
  net start "%[svc]"
ENDDO
"ssh-pageant.sh"
ENDLOCAL
 
Along the same vein, here's a script I use to get the latest nightly build off FFMpeg. This will run under CMD or TCC, if you're using TCC you won't need aria2c.

This will download the latest nightly build of FFMpeg and extract only the 3 exe files (FFMPEG, FFPROBE, FFPLAY) to C:\BIN.

@echo off set "get_from=https://github.com/BtbN/FFmpeg-Builds/releases/download/latest/" set "get_file=ffmpeg-master-latest-win64-gpl.zip" set "dest_path=c:\bin" pushd %TEMP% aria2c %get_from%%get_file% if NOT exist ffmpeg-master-latest-win64-gpl.zip goto :NOT_THERE 7z.exe e -y %get_file% -o%dest_path% -r ff*.exe if NOT exist c:\bin\ffmpeg.exe (goto :FAILED_EXTRACTION) if NOT exist c:\bin\ffprobe.exe (goto :FAILED_EXTRACTION) if NOT exist c:\bin\ffplay.exe (goto :FAILED_EXTRACTION) dir c:\bin\ff*.exe del %TEMP%\ff*.exe del %TEMP%\ffmpeg*.zip popd goto :EOF :NOT_THERE echo %get_file% is NOT found in %TEMP% goto :EOF :FAILED_EXTRACTION echo ff*.exe not found in c:\bin dir c:\bin\ff*.exe goto :EOF
 
Amazingly, this totally broke my sed, such that it would no longer work with emoji, despite having the same version.

I had to revert my cygwin\bin folder as the error message erroneously made it look like a problem with quoting delimiters, causing 100% of human beings to go out of their mind insisting it was a quotes-vs-apostrophe thing.

[But you could demonstrate that it wasn't by issuing identical commands with both delimiters with and without emoji. Only 4 possibilities. And 3 cygwin\bins to prove it with.]

Moral of the story... Be careful if you don't have some form of regression tests (i sure don't, lol).
 
I find sed quite handy on occasion, but I don't really use it very often. After seeing your post, I tried it and saw similar failures. I ran the Cygwin setup program, which did not update SED itself, but did update several libraries. After the update, sed works again.
 
ohenryx said:
I find sed quite handy on occasion, but I don't really use it very often. After seeing your post, I tried it and saw similar failures. I ran the Cygwin setup program, which did not update SED itself, but did update several libraries. After the update, sed works again.
Click to expand...

Interesting! I kidna went the "burn it down" route and just recopied the cygwin\bin folder from one of my other 2 machines. I kept the borked one around for experimentation, but when i put it back, my error message was different.

Madness! :)

I'm glad it was an easy fix!

I actually have a script that uses sed to decorate any mention of the machinenames in my lan with a machine-specific emoji that is defined by an environment variable. So i noticed right away because I use it to decorate my mapped drives list (drives get the emoji of the machine next to them) and it was failing haha. Talk about a tangent...
 
AnrDaemon: This is so wrong I don't even know where to begin. Let me just say that executable files do not have "base addresses".

ClioCJS: I do something similar when I setup a new computer. I run the Cygwin setup program, with just the basics. Then I unzip a zip file containing the entire Cygwin64 directory from my main computer. This gives me all of the extras that I have chosen to add to Cygwin over the years. There is probably a configuration file somewhere that I could use on the new machine, but I have no idea how to find it. Online searches show other users adopting my same technique.
 
I strongly suggest reading something about Cygwin implementation of POSIX fork() specification.
I mean, before writing such emotional comments.
 
AnrDaemon: If you found his comment emotional, then you're engaging in either textbook psychological projection, or subtle gaslighting.

He corrected you.

And he's right.

You're wrong.


If you were right, things would have broken

But they weren't.

And if they did break as you suggested, I would have simply restored the proper version of the folder back

So it's not actually a situation i actually need to avoid, nor a situation i require your helpful advice for.

In my opinion, your comment is condescending, unhelpful, and unnecessary, so I was going to come back and say you were wrong. But in the meanwhile, I see you accuse people who agree with me on this of being emotional.

Life has taught me that the people accusing those of being emotional after being told they are wrong .... are usually the ones who have emotional dysregulation problems. I recognize these problems in others because I have them myself. But this has veered off topic.

I fixed my cygwin. It did not break. It has not broken. It has been fine since. I usually go years without disturbing those files, and I intend to go years before doing so again. The upgrade was a cool idea but I learned my lesson: With my level of embeddedness i really need some kind of regression testing for cygwin upgrades, and that's way too much work for my personal computing life, so i just won't mess with it again.
 
We should all avoid getting overwrought about this. While I was basically correct about what I said previously, my wording was wrong. Executable files do have a “base address”, but it is not absolute, it is relative.



Base Address (Linker and Libraries Guide)



To oversimplify, the actual address consists of the address where the executable was loaded into memory plus the “relative base address”.



Common logic will tell you that you have to be able to move an executable file (*.exe). If that weren’t true, you could not copy executable files, you could not backup and restore, nothing would work afterward.



I do not know what steps the Cygwin installer takes, what registry values it may set. Which is why I run the installer one time on a new computer. After that, Cygwin is ready to roll. I can then unzip a larger, more complete version of Cygwin over the initial small setup with no problems. I have, over the years, added many many things to my Cygwin installation. It would take an enormous amount of time to go in and add all of those to a new install. And that assumes that I could easily determine just exactly what I have installed (a dubious proposition in itself).
 
ohenryx said:
I have, over the years, added many many things to my Cygwin installation. It would take an enormous amount of time to go in and add all of those to a new install.
Click to expand...
It's actually quite easy to find out, if you have installed it from repo.
Code: 
sed -Ee '/ 1$/s/^([^[:space:]]+) [^[:space:]]+?(\.tar[^[:space:]]+ 1)$/\1 \1-0\2/; t; d;' < /etc/setup/installed.db
Configuration could be copied over, no issues.
 
AnrDaemon said:
I suggest starting from What does rebaseall in Cygwin do? for a brief overview and reading Highlights of Cygwin Functionality for in-depth explanation.
Click to expand...

I just went and read your link. And then did a google search and found this:

cygwin-setup & rebaseall

cygwin.cygwin.narkive.com cygwin.cygwin.narkive.com

Long thread about problems with "rebase" in Cygwin. Short version -- probably best not to use the rebase command unless something is broken.

Basically, it seems that if everything worked at the time you zipped up your Cygwin64 directory tree, when you unzip it on a different computer, it is still going to work.
 
AnrDaemon said:
It's actually quite easy to find out, if you have installed it from repo.
Code: 
sed -Ee '/ 1$/s/^([^[:space:]]+) [^[:space:]]+?(\.tar[^[:space:]]+ 1)$/\1 \1-0\2/; t; d;' < /etc/setup/installed.db
Configuration could be copied over, no issues.
Click to expand...
Thanks for that information, I had never seen "installed.db". I will have to try that. I assume the steps on a different computer would be to install the minimal version of cygwin, copy in the saved "installed.db", and then run "setup-x86_64.exe". Have you tried this, does it work?
 
You must log in or register to reply here.
Back
Top