Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#14031 closed defect (fixed)

provide proper cygwin rebasing scripts

Reported by: dimpase Owned by: tbd
Priority: major Milestone: sage-5.9
Component: porting: Cygwin Keywords: rebaseall, rebase, cygwin
Cc: kcrisman, jpflori Merged in: sage-5.9.rc1
Authors: Dmitrii Pasechnik, Jean-Pierre Flori Reviewers: Jean-Pierre Flori, Karl-Dieter Crisman
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by kcrisman)

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:

Attachments (2)

trac_14031.patch (2.4 KB) - added by dimpase 7 years ago.
trac_14031-scripts.patch (4.8 KB) - added by jpflori 7 years ago.
Updated scripts, using rebaseall or rebase -O.

Download all attachments as: .zip

Change History (21)

Changed 7 years ago by dimpase

comment:1 Changed 7 years ago by dimpase

  • Cc kcrisman jpflori added
  • Description modified (diff)
  • Status changed from new to needs_review

Is this the right way to provide patches for sage_scripts?

comment:2 follow-up: Changed 7 years ago by 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).

comment:3 in reply to: ↑ 2 ; follow-up: Changed 7 years ago by 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. :-)

comment:4 in reply to: ↑ 3 Changed 7 years ago by 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!

comment:5 follow-up: Changed 7 years ago by jpflori

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

Last edited 7 years ago by jpflori (previous) (diff)

comment:6 Changed 7 years ago by jdemeyer

Please add your real name as Author.

comment:7 Changed 7 years ago by dimpase

  • Authors set to Dmitrii Pasechnik
  • Status changed from needs_review to needs_work

comment:8 in reply to: ↑ 5 Changed 7 years ago by 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.

comment:9 Changed 7 years ago by 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?).

comment:10 Changed 7 years ago by 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.

Changed 7 years ago by jpflori

Updated scripts, using rebaseall or rebase -O.

comment:11 Changed 7 years ago by jpflori

  • Authors changed from Dmitrii Pasechnik to Dmitrii Pasechnik, Jean-Pierre Flori
  • Description modified (diff)
  • Keywords cygwin added
  • Status changed from needs_work to needs_review

comment:12 Changed 7 years ago by kcrisman

  • Dependencies set to #14465
  • Description modified (diff)

comment:13 Changed 7 years ago by 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.

comment:14 follow-up: Changed 7 years ago by kcrisman

  • Dependencies #14465 deleted
  • Reviewers set to Jean-Pierre Flori, Karl-Dieter Crisman

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!).

comment:15 in reply to: ↑ 14 Changed 7 years ago by jdemeyer

  • Milestone changed from sage-5.10 to sage-5.9
  • Status changed from needs_review to positive_review

Replying to kcrisman:

I give positive review to the actual commands

Great! We can still fix bugs later.

comment:16 Changed 7 years ago by jdemeyer

  • Merged in set to sage-5.9.rc1
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:17 follow-up: Changed 7 years ago by 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.

Last edited 7 years ago by dimpase (previous) (diff)

comment:18 in reply to: ↑ 17 ; follow-up: Changed 7 years ago by 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.

comment:19 in reply to: ↑ 18 Changed 6 years ago by 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.

Note: See TracTickets for help on using tickets.