»
Tech Talk
»
Beyond the Basics
»
Sequentially Renaming Files
| Beyond the Basics |
|
Sequentially Renaming Files |
|
|
Christopher
Moderator
Member Rara Avis
since 1999-08-02
Posts 8296Purgatorial Incarceration 
|
I'm soon to have close to three hundred files that I want to rename (into the format: 0001.jpg). I've been trying to figure out how to do that and the closest I could even guess is below - and I'm not even sure that it's doable. The first problem I'm running into is even opening the directory. I keep getting an error saying that it can't open the directory? Some help would be appreciated! ***** #!/usr/local/bin/perl opendir(DIRECTORY, "http://countlesshorizons.com/family/images") or die "Can't open directory: $!"; @index = readdir(DIRECTORY); foreach $file(@index) { open (HANDLE, "http://countlesshorizons.com/cgi-bin/family/image.idx") || "Can't open file: $!"; $lastFileID = <HANDLE>; close (HANDLE); getLock(); $new = $lastFileID + 1; $new = sprintf("%4d", $new); $new =~tr/ /0/; open (HANDLE, ">http://countlesshorizons.com/cgi-bin/family/image.idx") || "Can't open file: $!"; print HANDLE $new; close (HANDLE); dropLock(); rename $file, "$new.jpg"; } closedir DIRECTORY; print qq~Content-type: text/html\n\n~; print @index; |
||
| © Copyright 2002 C.G. Ward - All Rights Reserved | |||
|
Ron
Administrator
Member Rara Avis
since 1999-05-19
Posts 8669Michigan, US |
LOL. When I went back to school in the early-80's with the intent of changing careers, I spent most of a summer working on the help desk of a mainframe manufacturer. That entailed talking to customers on the phone and trying to walk them through problems and solutions, in hopes we could avoid sending a technician on-site. I remember a call my first week there, where I spent 90 minutes asking the customer to "try this" over and over in hopes of discovering why his computer didn't work. Turns out the monitor wasn't plugged into the wall. That experience taught me how easy it is to overlook the obvious.  Chris, http://countlesshorizons.com/family/images is an URL, not a disk address.  |
||
|
vlraynes Member Rara Avis
since 2000-07-25
Posts 8229Somewhere... out there... |
<i> ROFL! No...I'm not laughing at you Christopher. I'm laughing WITH you..yeah, that's it. |
||
|
Christopher
Moderator
Member Rara Avis
since 1999-08-02
Posts 8296Purgatorial Incarceration |
after plugging in my monitor... i've realized 2 things: 1) ../../family/images isn't a valid directory either 2) ../../www/family/images IS a valid directory. actually threw me for a while. i tried it earlier with the relative path info ( #1 ) but it didn't work, because it required the "www" part out of the document root. ok, thank you for that start. i'm looking at the rest and can see that it won't work the way i'd hoped. i'm going to try to see if i can come up with something else before I ask for more help. Virgil -  |
||
|
Ron
Administrator
Member Rara Avis
since 1999-05-19
Posts 8669Michigan, US |
Okay, your REAL problem here then relates back to this earlier thread, where you were trying to "require" a script using an absolute path and failing. My guess was that the server was configured to lock you out of areas above your own assigned disk space and my advice was to use relative paths. That's fine for requires, which are always close, but sooner or later you're going to need to be able to use an absolute path. So, it's time to revisit our earlier discussion. require "$ENV{DOCUMENT_ROOT}/cgi-bin/test/toolbox.pl"; This didn't work for you, but the reason was NOT because you were locked out of certain areas as I guessed was the case. Your relative paths in post #3 gave me the clue to what was happening, and I did a little research at FQ to verify. To understand what's happening, we need to understand what the DOCUMENT_ROOT Environment string should be pointing to. Doc Root is where Apache expects to find HTML pages - otherwise known as documents. On most web servers, the Doc Root is synonymous with your assigned disk space, and the way you used it above would have worked. But not at FutureQuest. FQ has put your cgi-bin OUTSIDE of the Document Root. This is totally cool and makes your system much more secure, but it means you cannot use the DOCUMENT_ROOT Environment string to access anything in your cgi-bin. That's why your require statement in the earlier thread was failing. Here's an idea of how your paths are defined (if I read the FQ info correctly). /big ___/dom ______/xcountlesshorizons _________/cgi-bin _________/www The division at xcountlesshorizons marks the beginning of your assigned disk space. It does NOT correspond to your doc root, which starts at the www directory. Your cgi-bin resides inside your assigned disk space, but sits outside of the doc root. Ergo, you can't access anything in the cgi-bin using the DOCUMENT_ROOT Environment string. Returning to our earlier require problem, you should be able to use require "/big/dom/xcountlesshorizons/cgi-bin/test/toolbox.pl"; as an absolute path. I suspect, if you try that, you'll find that it works. In the above post, you should be able to use something like this: $Path2Images = "/big/dom/xcountlesshorizons/www/family/images"; Or, because your images are INSIDE the document root and not the cgi-bin, you can return to your earlier usage of the ENV string. $Path2Images = "$ENV{DOCUMENT_ROOT}/family/images"; Your rule of thumb will be that anytime you are referencing directories inside the www folder, you can and probably should use the DOCUMENT_ROOT Environment string. If you are trying to reference something inside your cgi-bin, however, there isn't any Environment variable that will directly work. You'll need to hard-code the path. That presents a potential problem should you ever move to a different server and want to take your scripts with you. You can't eliminate that potential, but you can at least limit it. If it were me, I'd set up a new include file, maybe called "globals.pl" and use that in every script I wrote. # globals.pl # $cgiPath = "/big/dom/xcountlesshorizons/cgi-bin"; 1; Make sure globals.pl is the FIRST file you require in each script, and from that point on you can use $cgiPath in the same way you would use $ENV{DOCUMENT_ROOT}. If you ever move to a server where the cgi-bin is not outside the doc root, globals.pl will be the only place you have to make a change. Okay, you ready for the irony of all this? Your configuration is a little unusual, which is why I guessed wrong in that earlier thread. On most Unix-type machines, the cgi-bin is under the www directory, not outside it. I should NOT have guessed wrong, though, because even though it's unusual … it's also the way I've configured my machines. |
||
|
vlraynes Member Rara Avis
since 2000-07-25
Posts 8229Somewhere... out there... |
*stops laughing and wishes she had a clue what all of this means* |
||
|
Christopher
Moderator
Member Rara Avis
since 1999-08-02
Posts 8296Purgatorial Incarceration |
scared me for a second there... lol - slipped that one in on me Ron! *rolls eyes* |
||
|
|
⇧ top of page ⇧ |
|
| All times are ET (US). All dates are in Year-Month-Day format. | ||
