provide proper cygwin rebasing scripts

[dimpase]

Rebasing half-built, or fully built, Sage Cygwin installation currently needs manual labour. This patch provides shell scripts and MSDOS batch files to make this more automatic, using 'rebaseall' or 'rebase -O'. One will only needs to adjust SAGE_ROOT in the batch file once (per Sage install). The documentation (outside of within the script themselves) will be provided at #14465.

Apply to sage_scripts:

• trac_14031-scripts.patch​

[dimpase]

Is this the right way to provide patches for sage_scripts?

[kcrisman]

I don't know what you mean by "right way". I usually go into $SAGE_LOCAL/bin and do hg commands from that repository...

rem dash %SAGE_ROOT%\local\bin\s.sh 

But the script isn't called s.sh? I know nothing about DOS so maybe this is obviously right.

An additional remark in the script about just using C:\cygwin\bin\dash.exe in the command prompt would not be amiss, since one could imagine people helping who don't know how to set paths in Windows, or even how to make env vars in Windows (e.g., I have no idea how to set SAGE_ROOT in the Windows command line).

[dimpase]

Replying to kcrisman:

I don't know what you mean by "right way". I usually go into $SAGE_LOCAL/bin and do hg commands from that repository...

I was wondering whether I need to wrap it up in an spkg...

rem dash %SAGE_ROOT%\local\bin\s.sh 

But the script isn't called s.sh? I know nothing about DOS so maybe this is obviously right.

rem means that the whole line is commented out, same as # for Unix shells. Indeed, this line can be deleted (a debugging leftover).

An additional remark in the script about just using C:\cygwin\bin\dash.exe in the command prompt would not be amiss,

the batch file does the right thing, if your Cygwin is in C:\cygwin. Otherwise the corr. line there needs to be changed.

since one could imagine people helping who don't know how to set paths in Windows, or even how to make env vars in Windows (e.g., I have no idea how to set SAGE_ROOT in the Windows command line).

no, it is meant to be changed in the batch file body. Perhaps I should mention that it is meant to call the dash script from the batch file, and not directly.

By the way, setting BLAH to foo in the Windows command line is just

set BLAH=foo

And if you need to evaluate BLAH you do %BLAH%, e.g.

echo %BLAH%

will print BLAH's value. You might also want to know that if you call dash after setting BLAH, it will be known to dash, and can be evaluated as usual, i.e. as $BLAH. dash will also treat PATH in a special way, by trying to translate it into Cygwin's PATH in some cases. But I digressed. :-)

[kcrisman]

I don't know what you mean by "right way". I usually go into $SAGE_LOCAL/bin and do hg commands from that repository...

I was wondering whether I need to wrap it up in an spkg...

No, one can just do the usual hg thing.

But the script isn't called s.sh? I know nothing about DOS so maybe this is obviously right.

rem means that the whole line is commented out, same as # for Unix shells.

I did figure that out eventually by staring at it :)

Indeed, this line can be deleted (a debugging leftover).

Good.

no, it is meant to be changed in the batch file body. Perhaps I should mention that it is meant to call the dash script from the batch file, and not directly.

Sure. I would have just called it directly somehow.

But I digressed. :-)

Useful info, though!

[jpflori]

We should also/instead provide a bash script using rebase -O as Dima suggested on #6743.

[jdemeyer]

Please add your real name as Author.

[kcrisman]

We should also/instead provide a bash script using rebase -O as Dima suggested on #6743.

+1 - this worked very nicely for me recently. I don't see why one couldn't replace the current one with that.

[jpflori]

It would also be nice to mention the /etc/rebase.db.i386 file, its use and the potential need to clean it up (or at least it seems that at some point deleting it was useful for some of us, Dima could you confirm that?).

[kcrisman]

There is also a tiny typo.

C:\cygin\bin)

It doesn't affect things because it's in a comment, but could affect users.

[jpflori]

Updated scripts, using rebaseall or rebase -O.

[jpflori]

I'm not sure #14465 should be an explicit dependency. The script are already self documented, so we could merge this even without #14465.

[kcrisman]

The script are already self documented, so we could merge this even without #14465.

Fair enough.

By the way, I give positive review to the actual commands, as does no doubt J-P. But I haven't (and won't have) had the chance to try out the actual scripts "in production" as my Cygwin is not available currently, and someone should try them in such a situation just to make sure we didn't miss a typo or something, or that the extreme minimality of the shells in Windows doesn't cause one of them to hiccup (dash doesn't even have an ls command!).

[jdemeyer]

Replying to kcrisman:

I give positive review to the actual commands

Great! We can still fix bugs later.

[dimpase]

I had a situation when I needed to rebase before sage_scripts spkg was installed (while building python spkg), so sage-rebase was not installed.

This is a kind of bug I don't know how to address properly (although installing the spkg with ./sage -f did help). At least this got to be documented.

[jdemeyer]

Replying to dimpase:

This is a kind of bug I don't know how to address properly

Move the scripts to $SAGE_ROOT/spkg/bin. That's really the place for scripts which are needed at build-time.

[dimpase]

Replying to jdemeyer:

Replying to dimpase:

This is a kind of bug I don't know how to address properly

Move the scripts to $SAGE_ROOT/spkg/bin. That's really the place for scripts which are needed at build-time.

I've opened #14742 to deal with this.