Opened 6 years ago

Last modified 6 years ago

#20107 closed enhancement

Add optional gap3_jm package — at Version 42

Reported by: stumpc5 Owned by:
Priority: major Milestone: sage-7.2
Component: packages: experimental Keywords: gap3, experimental package
Cc: saliola, tscrim, jmichel, SimonKing Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: u/stumpc5/20107 (Commits, GitHub, GitLab) Commit: 83d890688c11805d2c65797760d3b3f3e7eb13d3
Dependencies: Stopgaps:

Status badges

Description (last modified by stumpc5)

We have been trying to have an optional GAP3 package for a while now. Instead of the official GAP3, we instead use a forked package gap3_jm which has regularly been updated.

Previously, this was made a Sage package (#8906) but it contained binaries, so it was removed again (#19164).

I removed all binaries, and prepared a new tarball at ​http://downloads.findstat.org/gap3-jm5-2015-02-01.tar.gz .

Change History (42)

comment:1 Changed 6 years ago by stumpc5

How do I actually find all binaries? Such as

gap3_test$ grep -r -m 1 "^"  . | grep "^Binary file"
Binary file ./pkg/monoid/doc/manual.dvi matches
Binary file ./pkg/anusq/bin/Sq matches
Binary file ./pkg/anusq/doc/sq94.dvi matches
Binary file ./pkg/anusq/doc/sqn92.dvi matches
Binary file ./pkg/nq/bin/nq matches
Binary file ./pkg/cryst/doc/paper.dvi matches
Binary file ./pkg/meataxe/tests/m11.2 matches
Binary file ./pkg/meataxe/tests/Mat9 matches
Binary file ./pkg/meataxe/tests/a2 matches
Binary file ./pkg/meataxe/tests/a1 matches
Binary file ./pkg/meataxe/tests/Mat256 matches
Binary file ./pkg/meataxe/tests/Perm2 matches
Binary file ./pkg/meataxe/tests/Mat25 matches
Binary file ./pkg/meataxe/tests/Mat125 matches
Binary file ./pkg/meataxe/tests/ac.2 matches
Binary file ./pkg/meataxe/tests/Mat67 matches
Binary file ./pkg/meataxe/tests/Perm1 matches
Binary file ./pkg/meataxe/tests/Mat5 matches
Binary file ./pkg/meataxe/tests/C0.2 matches
Binary file ./pkg/meataxe/tests/C0.1 matches
Binary file ./pkg/meataxe/tests/Mat2 matches
Binary file ./pkg/meataxe/tests/ac.1 matches
Binary file ./pkg/meataxe/tests/m11.1 matches
Binary file ./pkg/sisyphos/bin/sis-i586-unknown-linux matches
Binary file ./pkg/sisyphos/doc/sisman.0.8.3.dvi matches
Binary file ./pkg/ve/examples/meout.pb matches
Binary file ./pkg/ve/bin/qme matches
Binary file ./pkg/ve/bin/me matches
Binary file ./pkg/ve/docs/nme.dvi matches
Binary file ./pkg/arep/bin/leonin matches
Binary file ./pkg/arep/bin/desauto matches
Binary file ./pkg/arep/bin/leonout matches
Binary file ./pkg/arep/src/leon/doc/manual.dvi matches
Binary file ./manual.pdf matches
Binary file ./bin/gapdjg.exe matches
Binary file ./bin/gap.mac matches
Binary file ./bin/gap.x86linux64 matches
Binary file ./bin/gapcyg.exe matches
Binary file ./bin/gap.macx86 matches
Binary file ./bin/gap.x86linux matches
Binary file ./bin/gapdjg.pif matches
Binary file ./bin/cygwin1.dll matches

Are any of these okay to keep, such as the dvi files?

comment:2 in reply to: ↑ description ; follow-up: Changed 6 years ago by jdemeyer

Replying to stumpc5:

I think this is the problem: it doesn't seem to be the "official" GAP3 package, just some random repackaging of GAP3.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 6 years ago by stumpc5

Replying to jdemeyer:

I think this is the problem: it doesn't seem to be the "official" GAP3 package, just some random repackaging of GAP3.

The development of GAP3 has stopped a long time ago. But there are several GAP3 packages that have never been ported to GAP4, and which are still developed.

From that webpage:

To help people who are just interested in GAP3 because they need a package
which has not been ported to GAP4, I have prepared an easy-to install
minimal GAP3 distribution containing an up-to-date versions of the packages.

So this is the only place where we can find up-to-date versions of the GAP3 package *chevie* to work with unitary reflection groups and their representation theory.

I fail to see what might be wrong with adding support for those packages using that "random repackaging" since I and several others need them.

I install the packages myself and then use them from within Sage, but since several things inside Sage are about to depend on that package - see #11187, #11010, #10819 - I think it is worth providing the option for others to automatically install that version of GAP3 with the newest *chevie* package.

comment:4 in reply to: ↑ 3 Changed 6 years ago by jdemeyer

Replying to stumpc5:

Replying to jdemeyer:

I think this is the problem: it doesn't seem to be the "official" GAP3 package, just some random repackaging of GAP3.

The development of GAP3 has stopped a long time ago. But there are several GAP3 packages that have never been ported to GAP4, and which are still developed.

From that webpage:

To help people who are just interested in GAP3 because they need a package
which has not been ported to GAP4, I have prepared an easy-to install
minimal GAP3 distribution containing an up-to-date versions of the packages.

All the above doesn't explain why you use the repackaged version and not the official GAP 3 release from http://www.gap-system.org/Gap3/Download3/download.html

So this is the only place where we can find up-to-date versions of the GAP3 package *chevie* to work with unitary reflection groups and their representation theory.

No, the official gap3r4p4 release also contains chevie.

I fail to see what might be wrong with adding support for those packages using that "random repackaging" since I and several others need them.

Because the repackaging seems to made in a messy way, see #19164.

comment:5 follow-up: Changed 6 years ago by jdemeyer

Frank Lübeck's page How to get CHEVIE also says to download the official GAP3 release and doesn't talk about the "repackaged" version.

comment:6 in reply to: ↑ 5 Changed 6 years ago by stumpc5

  • Cc jmichel added

Replying to jdemeyer:

Frank Lübeck's page How to get CHEVIE also says to download the official GAP3 release and doesn't talk about the "repackaged" version.

Neither this nor the above is up-to-date. Afaik, Jean Michel is the only person still actively developing *chevie* and his website is the only place where these new versions can be found. E.g., I found a small bug in chevie last month (so years after the release of gap3r4p4) through my Sage usage -- Jean fixed it within a few hours and posted the new version on his website.

Using any other version of gap3 and chevie will result in running into old mistakes that will slow down my understanding of research problems I compute!

comment:7 Changed 6 years ago by jdemeyer

Jean fixed it within a few hours and posted the new version on his website.

With "new version", I guess you mean a new version of the repackaged GAP3?

It should be possible to just get the up-to-date chevie sources without all the extra clutter.

comment:8 Changed 6 years ago by stumpc5

From my email discussion with Jean Michel:

>> These  days I sometimes change files in other places than Chevie, so indeed
>> each  time I change something one must take the whole distribution (however
>> I  almost  never  change  the  C  sources).

> Is the stuff that you change in other places needed for chevie to run?

Well,  yes. There were  patches to the  library loaded when loading Chevie.
Since  I maintain the whole distribution, I  decided it makes more sense to
*do*  these  patches  to  the  library  once  and  for  all (this could fix
undiscovered  bugs in other  packages). So the  correct behaviour of Chevie
depends on having my version of gap3/lib.

@Jeroen, what do you think how to proceed from here?

comment:9 Changed 6 years ago by jdemeyer

First of all, thanks for the clarifications!

I think that somebody (either Jean Michel himself or somebody on this Sage ticket) needs to package a source-only repackaged GAP3.

Further questions to be asked to Jean Michel:

  1. Could he state more clearly on his website that his version is not just a repackaged GAP3, it's really a fork of GAP3 with additional fixes which are not in GAP3 proper.
  1. Can he provide a clean source-only repackaged GAP3?
  1. If no to the previous question: is he willing to host such a source-only repackaged GAP3 on his website, if it is created by some Sage contributor?

comment:10 Changed 6 years ago by jdemeyer

  • Description modified (diff)
  • Summary changed from Add again optional GAP3 package to Add optional gap3_jm package

comment:11 follow-up: Changed 6 years ago by stumpc5

Replying to jdemeyer:

I think that somebody (either Jean Michel himself or somebody on this Sage ticket) needs to package a source-only repackaged GAP3.

I don't understand how this differs from my initial suggestion on this ticket.

comment:12 in reply to: ↑ 11 Changed 6 years ago by jdemeyer

Replying to stumpc5:

I don't understand how this differs from my initial suggestion on this ticket.

It does not differ. It's just that the situation has been clarified, making sure that your initial suggestion is the right thing to do.

comment:13 Changed 6 years ago by jdemeyer

  • Description modified (diff)

comment:14 follow-up: Changed 6 years ago by stumpc5

Dear Christian, I cannot post directly on sage-trac so I reply to you.

Further questions to be asked to Jean Michel:

  1. Could he state more clearly on his website that his version is not

just a repackaged GAP3, it's really a fork of GAP3 with additional fixes which are not in GAP3 proper.

OK, I will try to be clear on my webpages. The fact is I do not distribute a complete GAP3 distribution (all packages, all libraries) to save space. Perhaps I should distribute a complete distribution and this would obsolete the St Andrews distribution -- it would go from 15MB to 70MB.

  1. Can he provide a clean source-only repackaged GAP3?

I could try if I understand exactly what this means. But this should certainly not be the default distribution since my distribution contains Mac and Windows executables (and executables for some packages which have executables separate from the gap3 executable). We thus have to agree to a name for this for-Sage distribution which I will keep separate from the default distribution.

  1. If no to the previous question: is he willing to host such a source-

only repackaged GAP3 on his website, if it is created by some Sage contributor?

Yes.

comment:15 Changed 6 years ago by jdemeyer

  • Description modified (diff)

comment:16 in reply to: ↑ 14 ; follow-up: Changed 6 years ago by jdemeyer

Replying to stumpc5:

I could try if I understand exactly what this means.

It means: delete all binaries (i.e. system-specific) from the package. Make sure that the package has a build system such that it can be built/installed in a standard Unix environment.

We thus have to agree to a name for this for-Sage distribution which I will keep separate from the default distribution.

Well, I wouldn't call it a "for-Sage distribution". Call it a "source distribution". The actual filename doesn't matter much, most likely we will rename it for Sage anyway.

comment:17 in reply to: ↑ 16 Changed 6 years ago by stumpc5

Replying to jdemeyer:

It means: delete all binaries (i.e. system-specific) from the package. Make sure that the package has a build system such that it can be built/installed in a standard Unix environment.

I will try to do that.

comment:18 Changed 6 years ago by jdemeyer

Also (this is mostly a comment for Jean Michel): ideally the binary distribution would be made from the source distribution, not the other way around.

comment:19 Changed 6 years ago by stumpc5

  • Branch set to u/stumpc5/20107

comment:20 Changed 6 years ago by stumpc5

  • Commit set to 5483a58699784651d5fd47a633a68aed04f71cf1

I prepared a first version by

  1. taking the tarball from 2016-02-01 from Jean Michel's website
  2. deleting all binaries that were listed using grep -r -m 1 "^" . | grep "Binary file"
  3. putting the result into a new tarball with the name gap3-jm5-2015-02-01.tar.gz, this can be downloaded at https://drive.google.com/file/d/0B1POEh8bhq1fLXdfTEZkZjVLOGs/view?usp=sharing
  4. preparing an optional package using this upstream tarball. This was basically a blind trip through the documentation for creating packages + looking at the old optional package patch #8906.

@jdemeyer and @tscrim: I would very much appreciate if you could have a look!

If the linked tarball is okay, I would discuss with Jean Michel whether he could provide such a source distribution directly on his website.


New commits:

5483a58first working version, wandering in the darkness though

comment:21 Changed 6 years ago by stumpc5

  • Description modified (diff)

comment:22 Changed 6 years ago by stumpc5

  • Description modified (diff)

comment:23 follow-up: Changed 6 years ago by jdemeyer

This is far from an exhaustive list:

+if [[ $UNAME == 'Linux' ]]; then
+    if [[ $(uname -m) == 'x86_64' ]]; then
+        MAKE_COMMAND='x86linux-gcc64'
+    else
+        MAKE_COMMAND='x86linux-gcc'
+    fi;
+elif [[ $UNAME == 'Darwin' ]]; then
+        MAKE_COMMAND='macosx-gcc'
+fi

Is gap3 only supported on those architectures? In that case, it will need to be an experimental package.

comment:24 Changed 6 years ago by jdemeyer

You should check for errors in spkg-install.

comment:25 in reply to: ↑ 23 Changed 6 years ago by stumpc5

Replying to jdemeyer:

This is far from an exhaustive list:

I get

gap3_source/src$ make
usage: 'make <target>' where target is one of
'x86linux-gcc64'   for x86linux with gcc
'x86linux-gcc'     for x86linux with gcc in 32bit mode
'macosx-gcc'       for mac os x with gcc
'x86bsd-gcc'       for x86BSD with gcc
'sun-sparc-solaris-gcc' for SUN under Solaris with GNU cc
'sun-sparc-solaris-cc'  for SUN under Solaris with cc
'bsd'		       for others under Berkeley UNIX with cc
	
	  additional C compiler and linker flags can be passed with
	  'make <target> COPTS=<compiler-opts> LOPTS=<linker-opts>',
	  i.e., 'make x86linux-gcc COPTS=-g LOPTS=-g for debug'

and the GAP3 download page (http://www.gap-system.org/Gap3/Download3/download.html) does not say anything about other hardware.

Can you tell me how to extend that if ... elif ... fi statement to also support these other options -- and if that is enough for the package to be optional rather than experimental?

Many thanks!

comment:26 Changed 6 years ago by jdemeyer

Personally, I think it is better to have a look at the Makefile in gap3_jm and see why it so platform-dependent. Because there is very likely no fundamental reason why the platform should be given explicitly.

comment:27 Changed 6 years ago by stumpc5

The critical part of the Makefile is

x86linux-gcc:
	@$(MAKE) system.o   CC=gcc  CFLAGS="$(COPTS) -m32 -O2 -DSYS_IS_USG -DSYS_HAS_TIME_PROTO -DSYS_HAS_SIGNAL_PROTO -DSYS_HAS_IOCTL_PROTO"
	@$(MAKE) gap CC=gcc CFLAGS="$(COPTS) -m32 -O " SYS_FILE=system.o LOPTS="$(LOPTS) -m32 -static"
	strip gap
	mv gap ../bin/gap.x86linux

x86linux-gccd:
	@$(MAKE) system.o   CC=gcc  CFLAGS="-g -m32 -O2 -DSYS_IS_USG -DSYS_HAS_TIME_PROTO -DSYS_HAS_SIGNAL_PROTO -DSYS_HAS_IOCTL_PROTO"
	@$(MAKE) gap CC=gcc CFLAGS="-g -m32 -O " SYS_FILE=system.o LOPTS="-g -m32 -static"

x86linux-gcc64:
	@$(MAKE) system.o   CC=gcc  CFLAGS="$(COPTS) -O -DSYS_IS_64_BIT -DSYS_IS_USG -DSYS_HAS_TIME_PROTO -DSYS_HAS_SIGNAL_PROTO -DSYS_HAS_IOCTL_PROTO"
	@$(MAKE) gap CC=gcc CFLAGS="$(COPTS) -O -DSYS_IS_64_BIT " SYS_FILE=system.o LOPTS="$(LOPTS) -static"
	strip gap
	mv gap ../bin/gap.x86linux64

x86-dos-djgpp:
	@$(MAKE) system.o   CC=gcc  CFLAGS="$(COPTS) -DSYS_IS_MSDOS_DJGPP -DSYS_HAS_MISC_PROTO"
	@$(MAKE) gapdjg.exe CC=gcc  CFLAGS="$(COPTS) -O1"  SYS_FILE=system.o  LOPTS="$(LOPTS)"

x86-dos-djgppcross:
	@$(MAKE) system.o   CC=dos-gcc	CFLAGS="$(COPTS) -DSYS_IS_MSDOS_DJGPP -DSYS_HAS_MISC_PROTO"
	@$(MAKE) gapdjg.exe CC=dos-gcc	CFLAGS="$(COPTS) -O1"  SYS_FILE=system.o  LOPTS="$(LOPTS)"

# sbrk doesn't work in macosx so we need to use vm_allocate
macosx-gcc:
	@$(MAKE) system.o   CC=gcc  CFLAGS="$(COPTS) -m32 -DSYS_IS_MACOSX -DARCH_INCLUDE -DSYS_HAS_IOCTL_PROTO"
	@$(MAKE) gap	    CC=gcc  CFLAGS="$(COPTS) -m32 -O2"  SYS_FILE=system.o  LOPTS="$(LOPTS) -m32"

# sbrk doesn't work in macosx so we need to use vm_allocate
# This is using Frank Luebeck's optimized compile....but it doesn't
# change the GAPstones for the files in ../tst
macosx-gcc-686-optimized:
	@$(MAKE) system.o   CC=gcc  CFLAGS="$(COPTS) -m32 -fomit-frame-pointer -pipe -fno-strength-reduce -march=i686 -falign-loops=2 -falign-jumps=2 -falign-functions=2 -DCPU=686 -g -O2 -DSYS_IS_MACOSX -DARCH_INCLUDE -DSYS_HAS_IOCTL_PROTO"
	@$(MAKE) gap	    CC=gcc  CFLAGS="$(COPTS) -m32 -fomit-frame-pointer -pipe -fno-strength-reduce -march=i686 -falign-loops=2 -falign-jumps=2 -falign-functions=2 -DCPU=686 -g -O3"  SYS_FILE=system.o  LOPTS="$(LOPTS) -m32"

sun-sparc-solaris-cc:
	@$(MAKE) system.o   CC=cc  CFLAGS="$(COPTS) -O -DSYS_IS_USG -DSYS_HAS_TIME_PROTO -DSOLARIS2"
	@echo "Don't worry about 'out of range' and 'overflow' warnings"
	@echo "(29 in total)"
	@$(MAKE) gap	    CC=cc  CFLAGS="$(COPTS) -O2"  SYS_FILE=system.o  LOPTS="$(LOPTS)"

sun-sparc-solaris-gcc2:						   
	@$(MAKE) system.o   CC=gcc  CFLAGS="$(COPTS)  -O6 -DSYS_IS_USG -DSYS_HAS_TIME_PROTO -DSOLARIS2"						       
	@$(MAKE) gap	    CC=gcc  CFLAGS="$(COPTS)  -O6"  SYS_FILE=system.o LOPTS="$(LOPTS)"								     

# 'sys/times.h' claims 'times' returns 'clock_t' (how shall it return -1?)
sun-sparc-sunos-gcc:
	@$(MAKE) system.o   CC=gcc  CFLAGS="$(COPTS) -DSYS_IS_USG -DSYS_HAS_TIME_PROTO -DSYS_HAS_SIGNAL_PROTO"
	@$(MAKE) gap	    CC=gcc  CFLAGS="$(COPTS) -O2"  SYS_FILE=system.o  LOPTS="$(LOPTS)"

# 'sys/times.h' claims 'times' returns 'clock_t' (how shall it return -1?)
sun-sparc-sunos-cc:
	@$(MAKE) system.o   CFLAGS="$(COPTS) -DSYS_IS_USG -DSYS_HAS_TIME_PROTO"
	@$(MAKE) gap	    CFLAGS="$(COPTS) -O"  SYS_FILE=system.o  LOPTS="$(LOPTS)"

bsd:
	@$(MAKE) system.o   CC=$(CC)  CFLAGS="$(COPTS) -DSYS_IS_BSD"
	@$(MAKE) gap	    CC=$(CC)  CFLAGS="$(COPTS) -O"  SYS_FILE=system.o  LOPTS="$(LOPTS)"

I have no idea what of that is necessary and what can be simplified... Do you know?

comment:28 Changed 6 years ago by jdemeyer

Does this Makefile come from gap upstream or from gap3_jm?

To start with, I would remove these: mv gap ../bin/gap.x86linux. Then at least the name of the executable won't be system-dependent.

Second, are the x86linux-gcc and x86linux-gcc64 rules really x86-specific? At first sight, this doesn't seem to be the case: I think it is just 32-bit Linux and 64-bit Linux.

comment:29 follow-up: Changed 6 years ago by stumpc5

This Makefile comes from gap3_jm, the Makefile in the last official version is this + even more options.

To start with, I would remove these: mv gap ../bin/gap.x86linux. Then at least the name of the executable won't be system-dependent.

Okay, no problem.

Second, are the x86linux-gcc and x86linux-gcc64 rules really x86-specific? At first sight, this doesn't seem to be the case: I think it is just 32-bit Linux and 64-bit Linux.

Is there a way to find that out? I compiled GAP3 for the first time ever to get this optional package.

comment:30 in reply to: ↑ 29 Changed 6 years ago by jdemeyer

Replying to stumpc5:

Is there a way to find that out?

Assume that it works like I said and we'll see if it breaks.

comment:31 follow-up: Changed 6 years ago by stumpc5

I wanted to modify the Makefile accordingly, but it didn't work along the lines

ARCH = $(shell getconf LONG_BIT)
UNAME_S = $(shell uname -s)

ifeq ($(UNAME_S),Linux)
    ifeq ($(ARCH),32)
        # do foo
    endif
    ifeq ($(ARCH),64)
        # do bar
    endif
endif
ifeq ($(UNAME_S),Darwin)
    # do foobar
endif

unknown:
    ...

but I got many different type of errors that I wasn't able to resolve. Some were caused by tabs vs. spaces, others by the recursive calling of the makefile. Could you help me getting it correct?

comment:32 in reply to: ↑ 31 Changed 6 years ago by stumpc5

Replying to stumpc5:

I wanted to modify the Makefile accordingly, but it didn't work along the lines

Okay, I think I got it now, I had to further mess with tabs vs spaces... I am going to upload a new version soon.

comment:33 Changed 6 years ago by git

  • Commit changed from 5483a58699784651d5fd47a633a68aed04f71cf1 to ce54879a7a3f27a0edc620bee9706ce876d01bbe

Branch pushed to git repo; I updated commit sha1. New commits:

ce54879modified the makefile to autodetect the system Linux/Darwin and 32/64 bit

comment:34 Changed 6 years ago by git

  • Commit changed from ce54879a7a3f27a0edc620bee9706ce876d01bbe to 2ae234f35b813e8e11e453957a6b207d159b73fa

Branch pushed to git repo; I updated commit sha1. New commits:

2ae234fadded explanation in the header of the makefile patch

comment:35 Changed 6 years ago by git

  • Commit changed from 2ae234f35b813e8e11e453957a6b207d159b73fa to 696eaeb9ec9c4d7688dd38c1719e53e2c4713722

Branch pushed to git repo; I updated commit sha1. New commits:

696eaebadded description of the patches to SPKG.txt

comment:36 Changed 6 years ago by stumpc5

  • Status changed from new to needs_review

I took care of the two suggestions by Jeroen and now think it is ready for review -- many thanks!

comment:37 Changed 6 years ago by jdemeyer

  • Status changed from needs_review to needs_work

spkg-check doesn't actually do anything...

Does GAP3 have a testsuite?

comment:38 Changed 6 years ago by git

  • Commit changed from 696eaeb9ec9c4d7688dd38c1719e53e2c4713722 to 8e0e38ab80d45c0d55675b6860e4adcd31458884

Branch pushed to git repo; I updated commit sha1. New commits:

8e0e38aadded the memory for gap3 depending on 32/64 bit systems

comment:39 Changed 6 years ago by dimpase

I installed it once on OSX, then I decided to redo it with SAGE_CHECK=yes, and got

###########################################################
#  Building complete, you can run GAP3 from './../bin/gap3'
###########################################################
Installing (copying) files...
cp: symlink: me: File exists
cp: symlink: qme: File exists
Error installing (copying) gap3 files.

This comes from copying executables of ve package, me and qme somewhere; probably by the ve installation script.

you need to use the corresponding flag, -f, to avoid this trouble.

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

comment:40 Changed 6 years ago by dimpase

It would also be great if you host the tarball on a "real" server. Some browsers would automatically untar this file, and this is no good. So I had to get the tarball on a Linux machine, and copy it to the OSX machine for testing (oh the joy of this...)

And the release manager will be very, very unhappy, too, without a wget-able link for the tarball.

comment:41 Changed 6 years ago by git

  • Commit changed from 8e0e38ab80d45c0d55675b6860e4adcd31458884 to 83d890688c11805d2c65797760d3b3f3e7eb13d3

Branch pushed to git repo; I updated commit sha1. New commits:

83d8906added -r option to the cp command

comment:42 Changed 6 years ago by stumpc5

  • Description modified (diff)
  • Status changed from needs_work to needs_review
Note: See TracTickets for help on using tickets.