d88-mbe@sm.luth.se (Michael Bergman) (07/27/90)
Is there anyone besides me who uses the mv-cp-rm program by (d**n, I forgot
his name)? I'm talking about version 1.1 and it's really wonderful as it
replaces the copy and delete command *and* gives you a UN*X mv command.
Alias mechanism can be used so that only one copy of the binary is needed
(it's about 13000 bytes long).
Unfortunately, there are a few bugs. I have the source, but I can't
make it compile correctly (because the author has used some special routines
I think - I don't have those).
1. mv used as rename doesn't work correctly when you do something like
`mv FileName filename`. The file is cleared (0 bytes) and an error
message is produced. Not good!
mv works across devices and volumes (unlike rename) but he says he uses
rename when on the same device. Obviously he made a mistake here.
2. mv doesn't remove the old directory structure when you mv a file tree
*within* a device (e.g. RAM:). Across devices it works correctly. All the
*files* in the old tree are removed, but he forgets(?) to remove the
old directories also. I spotted this bug after 5 minutes - I'm surprised
he didn't see it!
3. He has misspellt `overide` (override...) used when you try to rm a delete-
protected file (is this really a bug? :-)
4. The cp command has date CLONE as default. This should be the other way
around: you shouldn't have to use `cp -n File1 File2` to get a fresh
date on the new copy. `cp -o File1 File2` to retain the old date is
much better (don't you agree?)
Well, that's it really. It shouldn't be very difficult to fix this,
especially as the source is available but I'm no C-wizard and haven't much
system programming experience on the Amiga yet.
I've tried to email the author, but no answer. The doc file hints that he
left the account about a year ago. It still exists, but I don't think he's
there anymore.
If there is a bugfix or someone is interested in using this utility/fixing
the bugs, please contact me right away!
It should be worth the trouble, 'cause in my experience the UN*X-style
mv/cp/rm are very useful and the most used commands in an OS (together with
ls of course).
Mike
--
Michael Bergman Internet: d88-mbe@sm.luth.se
// Undergrad. Comp. Eng. BITNET: d88-mbe%sm.luth.se@kth.se
\X/ U of Lulea, SWEDEN ARPA: d88-mbe%sm.luth.se@ucbvax.berkeley.edu
UUCP: {uunet,mcvax}!sunic.se!sm.luth.se!d88-mbea218@mindlink.UUCP (Charlie Gibbs) (07/30/90)
In article <1035@tau.sm.luth.se> d88-mbe@sm.luth.se (Michael Bergman) writes: >4. The cp command has date CLONE as default. This should be the other way > around: you shouldn't have to use `cp -n File1 File2` to get a fresh > date on the new copy. `cp -o File1 File2` to retain the old date is > much better (don't you agree?) No, I don't. The main reason I stick with Matt Dillon's Shell2.07m is that its cp command assumes CLONE by default. I'm a date-stamp fanatic; I depend on them for program version control, and so does make. Perhaps the best solution would be to have an environment variable to determine the default action of any copy (are you listening, Commodore?). Just another chance to harp on my pet peeve... Charlie_Gibbs@mindlink.UUCP "Oh, shit!" "We're all in it together." -- Brazil
hclausen@adspdk.CBMNET (Henrik Clausen) (07/31/90)
>In article <2666@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: > No, I don't. The main reason I stick with Matt Dillon's Shell2.07m >is that its cp command assumes CLONE by default. I'm a date-stamp >fanatic; I depend on them for program version control, and so does make. >Perhaps the best solution would be to have an environment variable to >determine the default action of any copy (are you listening, Commodore?). I'm a date-stamp fanatic, too, so I've put the following into my Shell-Startup file: Alias cp "copy clone " Simple, eh? -Henrik -- | Henrik Clausen, Graffiti Data (Fido: 2:230/22.33) | | ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen |
wfh58@leah.Albany.Edu (William F. Hammond) (08/01/90)
In article <2666@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >In article <1035@tau.sm.luth.se> d88-mbe@sm.luth.se (Michael Bergman) writes: >>4. The cp command has date CLONE as default. This should be the other way >> ... >> much better (don't you agree?) > No, I don't. The main reason I stick with Matt Dillon's Shell2.07m > ... >Perhaps the best solution would be to have an environment variable to >determine the default action of any copy (are you listening, Commodore?). > ... >Charlie_Gibbs@mindlink.UUCP I've been a very happy datestamp fanatic since the time of the ARP 1.1 release (early '88, I believe) when I was able to use the environmental variable "copyflags" to govern the behavior of ARP's "copy" with regard to datestamps. The 1.3 release of ARP offers the possibility of controlling 5 switches on the "copy" command with this environmental variable. And the price can't be beat. ---------------------------------------------------------------------- William F. Hammond Dept. of Mathematics & Statistics 518-442-4625 SUNYA, Albany, NY 12222 wfh58@leah.albany.edu wfh58@albnyvms.bitnet ----------------------------------------------------------------------
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (08/02/90)
In <hclausen.2093@adspdk.CBMNET>, hclausen@adspdk.CBMNET (Henrik Clausen) writes: >>In article <2666@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >> No, I don't. The main reason I stick with Matt Dillon's Shell2.07m >>is that its cp command assumes CLONE by default. I'm a date-stamp >>fanatic; I depend on them for program version control, and so does make. >>Perhaps the best solution would be to have an environment variable to >>determine the default action of any copy (are you listening, Commodore?). > > I'm a date-stamp fanatic, too, so I've put the following into my >Shell-Startup file: > >Alias cp "copy clone " > > Simple, eh? Yes, and also a kludge that should not have to be done. Bottom line is that it doesn't necessarily work for all shells, doesn't come into play when another program calls 'copy', and is not something that everyone knows about or will do. That means that it can't be counted on. It makes file dates and comments useless to have the default behaviour the way it is. -larry -- Sex is better than logic, but I can't prove it. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
aduncan@rhea.trl.oz.au (Allan Duncan) (08/02/90)
From article <2666@mindlink.UUCP>, by a218@mindlink.UUCP (Charlie Gibbs): > No, I don't. The main reason I stick with Matt Dillon's Shell2.07m > is that its cp command assumes CLONE by default. I'm a date-stamp > fanatic; I depend on them for program version control, and so does make. > Perhaps the best solution would be to have an environment variable to > determine the default action of any copy (are you listening, Commodore?). I agree with the desire for clone as the default, but I get around this with 'alias cp "copy [] clone"' somewhere in the startup. What I really want on 2.0 is "sort" on the list command, as in ARP. Is it time now to start the 2.1 requests? :-) Allan Duncan ACSnet a.duncan@trl.oz (03) 541 6708 ARPA a.duncan%trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (08/04/90)
In <13618@cbmvax.commodore.com>, andy@cbmvax.commodore.com (Andy Finkel) writes: >In article <1837@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>In <hclausen.2093@adspdk.CBMNET>, hclausen@adspdk.CBMNET (Henrik Clausen) writes: >>>>In article <2666@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >>do. That means that it can't be counted on. It makes file dates and comments >>useless to have the default behaviour the way it is. >> >>-larry > >The eternal debate. Ah, well. You know, BSD Unix does the same thing. >(gives a copy of a file a new filedate) and people don't claim file dates >are useless on Unix systems. Well, maybe they do :-) There are 3 file dates on BSD files, I think; created, last modified, and last accessed. Would be nice to have this in Amigados, if there was room. -larry -- Sex is better than logic, but I can't prove it. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
andy@cbmvax.commodore.com (Andy Finkel) (08/04/90)
In article <1837@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <hclausen.2093@adspdk.CBMNET>, hclausen@adspdk.CBMNET (Henrik Clausen) writes: >>>In article <2666@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >do. That means that it can't be counted on. It makes file dates and comments >useless to have the default behaviour the way it is. > >-larry The eternal debate. Ah, well. You know, BSD Unix does the same thing. (gives a copy of a file a new filedate) and people don't claim file dates are useless on Unix systems. Well, maybe they do :-) andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Of course it's the murder weapon. Who would frame someone with a fake?" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (08/04/90)
In <1844@lpami.wimsey.bc.ca>, lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <13618@cbmvax.commodore.com>, andy@cbmvax.commodore.com (Andy Finkel) writes: >>In article <1837@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>>In <hclausen.2093@adspdk.CBMNET>, hclausen@adspdk.CBMNET (Henrik Clausen) writes: >>>>>In article <2666@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >>>do. That means that it can't be counted on. It makes file dates and comments >>>useless to have the default behaviour the way it is. >>> >>>-larry >> >>The eternal debate. Ah, well. You know, BSD Unix does the same thing. >>(gives a copy of a file a new filedate) and people don't claim file dates >>are useless on Unix systems. Well, maybe they do :-) > >There are 3 file dates on BSD files, I think; created, last modified, and >last accessed. Would be nice to have this in Amigados, if there was room. Ooops! I have been informed that the three dates in question have been in every version of Unix since V7, and that they are: time of last modification time of last access time of last *file attribute or contents change* My original point remains valid. Thanks to Guy Harris for pointing this out. -larry -- Sex is better than logic, but I can't prove it. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+