Hi:
Thanks for all your suggestions and help. I was able to do the following --
1)Flatten out the directory structure into a file containing the dir and
files within the dir into
C:\buildlist.txt
2)Read the lines from a file say files2.txt and modify the lines to contain
the filenames fetched into C:\buildlist.txt. Write out the modified lines
into result.txt.
$path = "$ARGV[0]";
opendir ( DIR, $path ) or die "Can't open $path: $!";
while(defined($DIR = readdir DIR))
{
push(@array_A,$DIR)
}
closedir DIR;
open(FILE,">c:/buildlist.txt");
foreach $y (@array_A)
{
next if $y =~ /^\./;
push(@new,$y);
print FILE "$y\n";
}
open (FILE1, "<c:/files2.txt") || die ("Could not open file. $!");
@text = <FILE1>;
open(FILE2,">>c:/results.txt");
foreach $a(@text)
{
$y = shift(@new);
$a =~ s/("[^"]*)("\s+"[^"]*)("\s+"[^"]*)("\s+NA)/$1$y$2$y$3$y$4/;
print "$a\n";
print FILE2 "$a";
}close FILE2;
close FILE1;
close FILE;
My sample files2.txt is
"SL/" "%HOME%/server/bin/" "" NA
"SL/" "%HOME%/server/bin/" "" NA
My sample results.txt is
"SL/one" "%HOME%/server/bin/one" "one" NA
"SL/onetwo.txt" "%HOME%/server/bin/onetwo.txt" "onetwo.txt" NA
How can I modify this program, so that instead of reading the lines from
files2.txt, modifying them and writing them to results.txt, I can directly
write out entire lines as in "SL/one" "%HOME%/server/bin/one" "one" NA to
the results.txt(the only dynamic part of these entries, which will be
different in each line will be the filename ie one, onetwo etc). So,
depending on how many filenames are fetched into buidlist.txt, that many
number of lines will be get added into results.txt
Please let me know. Thanks.
On 7/8/06, Rob Dixon <[EMAIL PROTECTED]> wrote:
(Randal L. Schwartz) wrote:
Hi Randal
>>>>>>"Rob" == Rob Dixon <[EMAIL PROTECTED]> writes:
>
>
> Rob> I favour
>
> Rob> print FILE "$_\n" foreach grep /[^.]/, readdir DIR;
>
> Rob> for clarity
>
> But certainly not for correctness! It's easy to look pretty if you
don't care
> about the right answer. Your regex rejects *any* filename that contains
*any*
> dot. On a windows system, that'd be just about any file. :)
>
> Nahh, best to ignore yours and look upthread heere.
Look again. My regex rejects any filename that contains /only/ dots.
/[^.]/
matches any character that isn't a dot.
>
>>>closedir DIR;
>>>close FILE;
>
>
> Rob> Or even
>
> Rob> system "dir /b $path > C:/filelist.txt";
> Rob> $? and die "Can't create C:/filelist.txt: $?"
>
> Rob> since portability is not a question
>
> Apparently, since your code isn't portable either. :)
I don't understand this comment. The only lack of portability I can see is
in
the form of the file paths, which was in the original post.
>>>s/("[^"]*)("\s+"[^"]*)("\s+"[^"]*)("\s+NA)/$1$file$2$file$3$file$4/;
>
>
> Rob> Again, I think
>
> Rob> s/("[^"]*)(")/$1$file$2/g;
>
> Rob> is less befuddling.
>
> And less correct.
I don't see why? This was the request:
>>> Can you also let me know how to read the line in the below file, look
>>> for
>>> the second and forth " and write the name of the file fetched in the
>>> above program before the second and fourth " and between the fifth and
>>> sixth
>>> " one by one.
>>>
>>> "SL/" "%HOME%/server/bin/" "" NA
>>> as in
>>> "SL/one" "%HOME%/server/bin/one" "one" NA
John's approach was to match the strings
'"SL/'
'" "%HOME%/server/bin/'
'" "'
and
'" NA'
and to put them back into the replacement string with the filename
interposed. I
saw it more simply as just putting the filename before the closing quote
of all
embedded quoted strings. Either way, my code works with the given data, so
unless you've seen a case where it doesn't hold up I can't see the
problem.
> Hmm. Your track record isn't good on this post.
Please explain youself Randal. Or did you just wake up in troll mode
today?
> Perhaps you should read and learn more before answering, because a bad
answer
> is a lot more damaging than *no* answer, especially when correct answers
> have already been given elsewhere in the thread.
I do read and I do learn, and learning is one of my main reasons for
subscribing
to this mailing list. A bad answer is certainly damaging, but I still
don't
think my post was wrong. Perhaps more destructive still is an abusive
rejoinder.
> We appreciate your enthusiasm to help. But in this case, "help" means
> "please spend more time reading and less time posting". Or at least
> check your answers before posting... that would have been caught here.
I checked my answers before posting them. Did you check them before
rubbishing them?
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
