On Mon, Apr 18, 2011 at 6:14 AM, Rich Shepard <rshep...@appl-ecosys.com> wrote: >> Will take the spaces out (destructively, so be careful. I don't know how >> it handles filename conflicts that may arise, I suspect not gracefully.). >> Combined with find and xargs, you can apply it to a whole directory tree >> (I haven't tested the following line though, so beware of typos/etc..): > > If there are no filename conflicts with spaces how could there be filename > conflicts without them? Just curios.
So, it sounds like your files are uniquely identified by visible characters, so this won't be a problem. If that weren't the case, then there are three problem scenarios come to mind, all of which are more or less rooted in the fact that rename is not an injective (one-to-one) function and its domain is a superset of its codomain. - Any time you rename, you *might* rename to something that already exists. e.g.; consider the files "READ ME.txt" and "README.txt". Put more generally, you're only transforming the files that currently have spaces, so it's not uniformly applied to all the files in the directory. - The rename is only applied to one file at a time, regardless of how it may act as a batch job, so there is no guarantee that some intermediate state of your files won't result in conflicts. - If you happen to have any files that are only differentiated by whitespace, some of those would eventually conflict. e.g.; "READ ME" (one space) and "READ ME" (two spaces) --Rogan > >> There are also probably other programs called rename. This is what I >> get if I run 'rename' with no arguments: > > Here, it's: > > [rshepard@salmo ~]$ rename > call: rename from to files... > > Thanks, > > Rich > _______________________________________________ > PLUG mailing list > PLUG@lists.pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
