Re: listing symbolic links recursively, with dir listing
Or you might try:
find . -type l -exec ls -l {} \;
David Glick
Transmit Consulting, Inc
619-475-4052
[EMAIL PROTECTED]
- Original Message -
find . -type l -print
finds all symbolic links in the current directory and any subdirectories.
prints their paths too. however, it doesn't print the output like 'ls'
does, so you'd have to do something else to get the link's target.
a better way would be to write a perl script to get all the symbolic
links and then use readlink() to get the link's target.
Colby Allred
Advanced Hardware Architectures
http://www.aha.com/
On Thu, 18 Jan 2001, Hanser, Kevin wrote:
> I've just imported a directory structure into CVS that has a lot of symbolic
> links in it. I've written a script to restore these links from a file that
> lists what they are and where they point. However, I'm having trouble
> finding all the links now. I need to be able to recursively list all the
> symbolic links, and what subdirectories they're in. I can do a
> 'ls -lR | grep lrwx' and that will show me all the links and where they
> point, but I can't tell what subdirectory they're in. I need to be able to
> list them out and have the full path/filename listed...
>
> Does anybody have any suggestions on how to do this, or know of a utility
> that will do this?
>
> Thanx
>
> Kevin Hanser
> System Administrator
> Merchant Internet Group
> [EMAIL PROTECTED]
>
>
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
>
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
- Original Message -
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: listing symbolic links recursively, with dir listing
You make it too simple. From the "Real programmers don't eat quiche" manual:
"If it was hard to write, it should be hard to understand and harder to modify"...
David Glick
Transmit Consulting, Inc
619-475-4052
[EMAIL PROTECTED]
- Original Message -----
> From: David Glick <[EMAIL PROTECTED]>
> Date: Thu, 18 Jan 2001 15:36:52 -0800 (PST)
>
> Or you might try:
>
> find . -type l -exec ls -l {} \;
Or (depending on your version of find):
find . -type l -ls
(When I taught an Intro to Unix course, I recommended that my students re-read
the find man page every few months. Every time I re-read it, I find something
I didn't know before.)
Chris
--
Chris Garrigues http://www.DeepEddy.Com/~cwg/
virCIO http://www.virCIO.Com
4314 Avenue C
Austin, TX 78751-3709 +1 512 374 0500
My email address is an experiment in SPAM elimination. For an
explanation of what we're doing, see http://www.DeepEddy.Com/tms.html
Nobody ever got fired for buying Microsoft,
but they could get fired for relying on Microsoft.
- Original Message -
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
With all due respect, Greg, I think Gianni made some very telling points which CVS will need to address if it is to survive. I'm an independent consultant, and I try to bring CVS into each organization I work with. I'm sometimes successful, but I fail at times for exactly the reasons Gianni articulates. With the proliferation of MSWord, IDE project files, etc, no reasonable person can argue that non-text files are not a necessary part of most projects these days. If CVS does not 'grow up' and attempt to support the new development environments, it will slowly be replaced by something that does, and CVS will ultimately become a bit player, promoted by a few fanatic users who try to make its case at every opportunity (whether appropriate or not), and ignored or laughed at by the majority of the population. I've heard your same arguments applied to Forth, OS/2, Geos, Clarion, Lotus 1-2-3, Wordstar, UCSD P-System... the list goes on. I'd hate to add CVS to the list. David Glick Transmit Consulting, Inc 619-475-4052 [EMAIL PROTECTED] - Original Message - <--- snip ---> [ On Friday, March 30, 2001 at 07:07:14 (-0800), Gianni Mariani wrote: ] > Subject: RE: cvswrappers - any better suggestions ? > > Your point is well taken. However, time are a changing - source code is not > only text. Image, sound, movie, geometry, encryption key, etc etc files are > all parts of modern day applications. All these files need to be version > managed just like regular files. If we could apply an rcsmerge on these > kinds of files, then it would be ideal. Yes, what you say is all very well and fine. What it means though is that CVS is not the correct tool for use in such a diverse environment. Obviously my point did not sink in properly though so I will say it more clearly: PLEASE go use something else <--- /snip ---> - Original Message - ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
Don't be silly, Greg; abusing other software wouldn't be nearly as amusing... BTW, I *do* get it; I just don't agree with you. I've spent most of 20+ years listening to people just like you explain why something shouldn't/couldn't be done, and then finding ways to make it happen anyway. Clearly, other people feel the same way, because CVS does support binary files after a fashion. I just want them supported better. Because I respect someone as certain of themselves as you are (even if you're wrong), I'll let you know what the answer is when I find it. David Glick Transmit Consulting, Inc 619-475-4052 [EMAIL PROTECTED] - Original Message - [ On Sunday, April 1, 2001 at 08:26:32 (-0800), Gianni Mariani wrote: ] > Subject: RE: cvswrappers - any better suggestions ? > > Your discussion below exposes a perspective which is about as far off from > my own as you can get. I will go as far to say that your goals are very > different to most that are using CVS today. I will stretch even further > and say that there are about as many different goals users have for CVS > as there are CVS users. You people just don't get it. CVS adheres to design principles that are completely contrary to your requirements. You CANNOT succeed with it given your current goals! It's irrelevant how many users have made the wrong choice and are using CVS despite the fact that its design is contrary to their goals. A wrong choice is wrong no matter which side you look at it from. Please go find some other software to abuse, and hopefully this time you'll choose some non-free software and you'll be able to pay it's maintainers to change their design if it doesn't happen to fit your goals! Maybe you'll be lucky and you'll choose some non-free software that has a significant "market share" too. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs - Original Message - ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
I'd argue that I do get it; you just don't get that I get it. Your statement "CVS literally cannot support binary files..." should be changed to "CVS does not currently support binary files in a way that is consistent with the philosophy of concurrent editing". If we can agree with the above statement, then this immediately leads to two possible approaches (or three, if you continue to argue that binary files should not be supported...): 1) Violate the 'concurrent' philosophy with regard to binary files, and implement a locked checkout to allow for straightforward creation of deltas and avoid the messy problems of figuring out how to concurrently update binary files. 2) Allow for concurrent checkout of binary files, but disallow concurrent commits, e.g. only a user that has updated to the current version will be allowed to commit changes. Neither approach is ideal, but both provide a step in the direction of better support for binary files. I'm sure there are other approaches that may well satisfy other people's needs, too. There may even be a way to fold binary file support completely into the CVS philosophy; I'm just too busy right now to think it through completely (and, unfortunately, I'm *way* to busy to actually do the work... sigh.). - Original Message - Clearly you do not get it at all. CVS literally cannot support binary files in any better fashion without becoming something that will no longer be a "Concurrent Versions System". It was designed specifically to force concurrent editing and that design goal permeates the way it works through and through (despite the valiant attempts by others to bend it to suit their twisted ideas). You cannot throw out the bath water without throwing out the baby in this case -- they are one in the same. - Original Message - ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvswrappers - any better suggestions ?
ashing old argurments or coming up with anything new. >> I'm just too busy right now to think it through completely (and, >> unfortunately, I'm *way* to busy to actually do the work... sigh.). > > I can appreciate that. However it's no excuse though for blaming CVS > for being designed the way it is. It's not even really a valid excuse > for using CVS when some better tool would make your work more > productive. I'm not blaming CVS; as I said, I *like* CVS, and I fully buy into its general development model. I do believe that the 'Concurrent' in CVS is what makes it superior to most other tools. Having said that, I'd like a better way to handle binary files, even if its not 'concurrent' in this instance (and I accept that this *is* contradictory ). David Glick Transmit Consulting, Inc 619-475-4052 [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
