[28346] in Perl-Users-Digest
Perl-Users Digest, Issue: 9710 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 11 06:05:51 2006
Date: Mon, 11 Sep 2006 03:05:10 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 11 Sep 2006 Volume: 10 Number: 9710
Today's topics:
Re: Decode data of different charsets into UTF8 (Perl i <skg@mail.inf.fh-brs.de>
DLL Call Follies <technopundit@gmail.com>
Re: DLL Call Follies <john@castleamber.com>
Re: DLL Call Follies <technopundit@gmail.com>
Re: DLL Call Follies <john@castleamber.com>
Re: DLL Call Follies <technopundit@gmail.com>
Re: DLL Call Follies <sisyphus1@nomail.afraid.org>
Re: exec command issue <kenslaterpa@hotmail.com>
Re: exec command issue <kenslaterpa@hotmail.com>
Re: exec command issue <RedGrittyBrick@SpamWeary.foo>
Re: exec command issue <tadmc@augustmail.com>
Re: exec command issue <tadmc@augustmail.com>
Re: exec command issue <don@mastah.com>
Re: exec command issue <don@mastah.com>
Re: exec command issue <bik.mido@tiscalinet.it>
Re: exec command issue <bik.mido@tiscalinet.it>
Re: exec command issue <don@mastah.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 11 Sep 2006 02:08:06 -0700
From: "ska" <skg@mail.inf.fh-brs.de>
Subject: Re: Decode data of different charsets into UTF8 (Perl internal format)
Message-Id: <1157965686.442322.303840@m73g2000cwd.googlegroups.com>
Peter J. Holzer wrote:
> On 2006-09-08 12:36, ska <skg@mail.inf.fh-brs.de> wrote:
> > The text may be in CP437, Latin1, UTF8 or Unicode16 (latter except for
> > the files). There is no way for me to get the charset from the
> > "context".
>
> Are you sure Windows-1252 isn't in the mix, too?
Well, I hope that Latin1 and Windows-1252 do match in all significant
parts, they do as it concerned for the Umlauts & =DF, at least per
"recode".
In fact, these characters are the only hint in order to differ between
the 8bit character sets, so I stick with them and if somebody really
use some strange other characters, s/he needs to do some preformatting
(Noteable: use Unicode).
> >> 3. turn the utf8 flag on with Encode::_utf8_on($scalar);.
> >> 4. check if the data is valid with Encode::is_utf8($scalar, 1);.
>
> That seems to be a rather kludgy way of checking. I'd use Encode::decode
> (probably with Encode::FB_QUIET). That also has the advantage of working
> for other multibyte-encodings than UTF-8.
When I tested Encode::decode() my script was terrible slow, so I tried
this sample from the mentioned thread. Later I use Encode;:decode()
anyway.
However, I turned out that it wasn't the decode() function.
> If they are too large, you have to read them in blocks: Read the first
> block, determine the charset, decode it and process it. then, in a loop,
> read the next block, append it to the remainder of the previous block,
> decode it and process it.
I hoped to not need to do all the buffering etc.pp. myself.
Maybe I should try to look into to call binmode() "mid-stream" and hope
all works as I hope.
> > if(Encode::is_utf8($line, 1)) {
> > $charset =3D 'utf8';
>
> If is_utf8 is true, the data is already in perl's internal utf8 format,
> and must not be decoded again.
The "utf8" charset will skip the decoding part in the script.
In the production code I will most probably call it "pass" or something
like that, so I needn't test for two charsets to pass forth unchanged.
> > } elsif($line =3D~ s/^(?:\xfe\xff)?(\0[^\0])/$1/) {
>
> Why the substitution? Why not simply
Because the 0xFFFE and 0xFEFF markers are kept with Encode:decode().
> } elsif($line =3D~ /^(?:\xfe\xff)?\0[^\0]/) {
>
> Also, I think checking for the first character to be in range U+0001 to
> U+00FF may be a bit too strict. What if the file starts with a Euro
> sign?
Fortunatly, I need not convert any text, but I can make guesses.
(Otherwise I cannot differ cp437 from Latin1 at all). The first
character of a file is most probably a plain ASCII character. Otherwise
I couldn't detect Unicode16 that early -- well, in worst-case, there
wouldn't be any single Latin1 character in it, so there would be no
character less 256, hence, no single \0 in the data --> I wouldn't be
able to detect Unicode16 at all.
I know that I cannot make a 100% sure guess.
> > } else {
> > my $remainder =3D $line;
> > if($remainder =3D~ /[^\x01-\x7f]/
> > && (my $s =3D Encode::decode('utf8', $remainder, Encode::FB_QUIET))
> > && !$remainder) {
> > $charset =3D 'utf8-decode';
>
> You get here only if the file starts with an ASCII character. If it
> starts with an umlaut, the file will not be recognized as UTF-8.
Huh? I probe the data for one character that is NOT 7bit ASCII.
=3D=3D=3D
I found one problem with the logic in the script:
Because I need UTF8 on return, it is nonsense to pass forth Latin1
unchanged and rely on Perl converting it into utf8 on-the-fly.
In one script I fill a utf8 database with the data, what breaks,
because the data is not automatically encoded into utf8.
Therefore I now probe for $line =3D~ /^[\x01-\x7f]*$/ first, mark it as
ASCII.
And Encode::decode anything, that is not marked as 'utf8' or 'ASCII'..
------------------------------
Date: 10 Sep 2006 16:24:06 -0700
From: "Kythe" <technopundit@gmail.com>
Subject: DLL Call Follies
Message-Id: <1157930646.150831.240240@q16g2000cwq.googlegroups.com>
Hello,
My apologies if this is a rather basic question, but I've been beating
my head against the wall trying to get Win32::API interfacing to a dll
working, and I've never done this before.
The dll in question is proprietary; however, it's 32 bit, it requires a
32,000-byte memory space, and returns values via parameters, not just
via return values.
Here's the documentation in question:
"The calling program must provide a workspace for mydll.dll. mydll will
do most of its processing & storing of data in this workspace.
Currently, the work space must be at least 32k bytes (bigger won't
help). Visual Basic programs must provide this via the Windows memory
allocation API. 'C' or Pascal programs may provide a pointer to a
memory area. Mydll creates pointers within the work space, so if the
memory is relocated, the work space must be re-initialized. This can
happen with any call, and is signaled by an error return on the call.
Error codes are listed in the "Return Error Codes" section of this
document."
Here's the provided calling procedure for Delphi/Pascal:
Procedure InitializeDataBaseDbSrvr( DatabasePath_Ptr, Password_Pchar:
Pchar; WorkSpace_Ptr: Pointer; WorkSpaceSize_Wrd: Word; Var
SizeUsed_Wrd: Word; Var ErrorReturn: SmallInt );
And here's the PERL code as it stands now:
#!c:\perl\bin\perl.exe
$password = 'xxxxxxxx';
$cwd = 'C:\\Program Files\\MyDllWorkingDirectory\\';
$err_return = 0;
$buffersize = 32000;
use Win32::API;
Win32::API::Struct->typedef('BUFFER', qw(BYTE Buffer[32000])) or die
"$!\n";
my $buff = Win32::API::Struct->new('BUFFER');
$initialize = new
Win32::API("mydll.dll","InitializeDataBaseDbSrvr","CCSNP","V");
$initialize->Call($cwd,$password,$buff,$buffersize,$err_return);
print "$err_return\n";
Right now, Perl is throwing an error dialog "Perl Command Line
Interpreter has encountered a problem and needs to close. We are sorry
for the inconvenience."
I'm kind of tapped out on this right now. Like I said, I haven't used
PERL to import dll functions before, and I'm at wall when it comes to
the documentation and sample scripts.
Any help would be most appreciated!
------------------------------
Date: 10 Sep 2006 23:51:21 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: DLL Call Follies
Message-Id: <Xns983ABFCE579C5castleamber@130.133.1.4>
"Kythe" <technopundit@gmail.com> wrote:
> 32,000-byte memory space, and returns values via parameters, not just
> via return values.
>
> Here's the documentation in question:
>
> "The calling program must provide a workspace for mydll.dll. mydll will
> do most of its processing & storing of data in this workspace.
> Currently, the work space must be at least 32k bytes (bigger won't
32K is probably 32,768 bytes (2^15), not 32,000
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: 10 Sep 2006 17:33:51 -0700
From: "Kythe" <technopundit@gmail.com>
Subject: Re: DLL Call Follies
Message-Id: <1157934831.759037.68540@m73g2000cwd.googlegroups.com>
John Bokma wrote:
> "Kythe" <technopundit@gmail.com> wrote:
>
> > 32,000-byte memory space, and returns values via parameters, not just
> > via return values.
> >
> > Here's the documentation in question:
> >
> > "The calling program must provide a workspace for mydll.dll. mydll will
> > do most of its processing & storing of data in this workspace.
> > Currently, the work space must be at least 32k bytes (bigger won't
>
> 32K is probably 32,768 bytes (2^15), not 32,000
>
> --
> John Experienced Perl programmer: http://castleamber.com/
>
> Perl help, tutorials, and examples: http://johnbokma.com/perl/
Very true. In the sample code they provide for allocating memory using
the kernel32 function GlobalAlloc, however, they use the nice, round
32,000 bytes. I figured it was probably close enough :)
Even so, using 32,768 doesn't change the outcome.
------------------------------
Date: 11 Sep 2006 02:48:41 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: DLL Call Follies
Message-Id: <Xns983ADDDED5A43castleamber@130.133.1.4>
"Kythe" <technopundit@gmail.com> wrote:
>
> John Bokma wrote:
>> "Kythe" <technopundit@gmail.com> wrote:
>>
>> > 32,000-byte memory space, and returns values via parameters, not
>> > just via return values.
>> >
>> > Here's the documentation in question:
>> >
>> > "The calling program must provide a workspace for mydll.dll. mydll
>> > will do most of its processing & storing of data in this workspace.
>> > Currently, the work space must be at least 32k bytes (bigger won't
>>
>> 32K is probably 32,768 bytes (2^15), not 32,000
>>
>> --
>> John Experienced Perl programmer:
>> http://castleamber.com/
>>
>> Perl help, tutorials, and examples:
>> http://johnbokma.com/perl/
>
> Very true. In the sample code they provide for allocating memory
> using the kernel32 function GlobalAlloc, however, they use the nice,
> round 32,000 bytes. I figured it was probably close enough :)
>
> Even so, using 32,768 doesn't change the outcome.
Ok, I was guessing that not enough memory caused the behavior you saw but
was not sure :-)
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: 11 Sep 2006 00:15:29 -0700
From: "Kythe" <technopundit@gmail.com>
Subject: Re: DLL Call Follies
Message-Id: <1157958929.295728.146080@d34g2000cwd.googlegroups.com>
Any ideas? Even sources references to further information would be
helpful!
------------------------------
Date: Mon, 11 Sep 2006 18:10:16 +1000
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: DLL Call Follies
Message-Id: <45051ad7$0$5105$afc38c87@news.optusnet.com.au>
"Kythe" <technopundit@gmail.com> wrote in message
.
.
>
> And here's the PERL code as it stands now:
>
> #!c:\perl\bin\perl.exe
> $password = 'xxxxxxxx';
> $cwd = 'C:\\Program Files\\MyDllWorkingDirectory\\';
> $err_return = 0;
> $buffersize = 32000;
>
> use Win32::API;
> Win32::API::Struct->typedef('BUFFER', qw(BYTE Buffer[32000])) or die
> "$!\n";
> my $buff = Win32::API::Struct->new('BUFFER');
>
> $initialize = new
> Win32::API("mydll.dll","InitializeDataBaseDbSrvr","CCSNP","V");
> $initialize->Call($cwd,$password,$buff,$buffersize,$err_return);
>
> print "$err_return\n";
>
You should determine just which line of code is producing the error you
reported. Is it the initial assignment to $buff, the initial assignment to
$initialize, or the '$initialize->Call()' that's causing the error.
I could be miles off ... but what happens if you rewrite that as:
#!c:\perl\bin\perl.exe
$password = 'xxxxxxxx';
$cwd = 'C:\\Program Files\\MyDllWorkingDirectory\\';
$err_return = 0;
$buffersize = 32768;
use Win32::API;
my $buff = " " x $buffersize;
$initialize = new
Win32::API("mydll.dll","InitializeDataBaseDbSrvr","PPPNN","V"); # or maybe
"PPPNP" as 3rd arg
if (not defined $initialize)
{die "Failed to import InitializeDataBaseDbSrvr"}
$initialize->Call($cwd,$password,$buff,$buffersize,$err_return);
print "$err_return\n";
Are you sure that InitializeDataBaseDbSrvr() does not return a value ?
There are some people here who are quite good with Win32::API (though I'm
not one of them). Be patient and you'll probably get a solution.
Cheers,
Rob
------------------------------
Date: 10 Sep 2006 15:28:55 -0700
From: "kens" <kenslaterpa@hotmail.com>
Subject: Re: exec command issue
Message-Id: <1157927335.163265.224070@e3g2000cwe.googlegroups.com>
Don Corleone wrote:
> Hey All
>
> I got a simple program that reads an file listing using the dos dir command
> and then performs another exec on each file name in the list. Problem is
> perl doesnt seem to run the second dos command. ?
>
> Any help appreciated.
>
> # Get a list of all the files in the directory
> #
> print STDOUT "Enter path: ";
> $path = <STDIN>;
> exec("dir/b /od *.tif $path");
> $result = `PROGRAM`;
>
> # Process each file
>
> while (<>) {
> chomp;
> @Line = split "\t",$_;
> exec("bong $_ );
> #bong if a dos program for converting tif files to jpg files.
> #exec("ocr --pdf 1.tif \n");
> #print "Pdf File created: \n";
>
> }
Use the "system" function. 'exec' never return control to your script.
perldoc -f exec
Ken
------------------------------
Date: 10 Sep 2006 15:34:09 -0700
From: "kens" <kenslaterpa@hotmail.com>
Subject: Re: exec command issue
Message-Id: <1157927649.241874.163320@i42g2000cwa.googlegroups.com>
Don Corleone wrote:
> Hey All
>
> I got a simple program that reads an file listing using the dos dir command
> and then performs another exec on each file name in the list. Problem is
> perl doesnt seem to run the second dos command. ?
>
> Any help appreciated.
>
> # Get a list of all the files in the directory
> #
> print STDOUT "Enter path: ";
> $path = <STDIN>;
> exec("dir/b /od *.tif $path");
> $result = `PROGRAM`;
>
As an aside, you could use a 'readdir' with a 'grep' to get an array
of tif files
instead of issuing the first system (exec) command.
Ken
------------------------------
Date: Sun, 10 Sep 2006 23:48:33 +0100
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: exec command issue
Message-Id: <J9WdnX3d7IlADpnYRVny2Q@bt.com>
Don Corleone wrote:
> Hey All
>
> I got a simple program that reads an file listing using the dos dir command
> and then performs another exec on each file name in the list. Problem is
> perl doesnt seem to run the second dos command. ?
>
> Any help appreciated.
>
I always start my perl scripts with
#!perl
use strict;
use warnings;
> # Get a list of all the files in the directory
> #
> print STDOUT "Enter path: ";
I suspect that is the same as
print 'Enter path: ';
> $path = <STDIN>;
> exec("dir/b /od *.tif $path");
I'd sanitise the input before running it, you never know what people may
type.
The above probably doesn't do what you expect. What exactly did you
expect to happen to the output of your 'dir' command?
perldoc -f exec
> $result = `PROGRAM`;
I can't imagine this doing anything useful. Firstly 'PROGRAM' is
unlikely to be the name of a program. Secondly, you never use $result
after this.
>
> # Process each file
>
> while (<>) {
This doesn't 'process each file' if by 'file' you mean the *.tif in your
'dir' command. The <> reads from any files listed on the perl command
line or from STDIN. I suspect you provide neither.
> chomp;
> @Line = split "\t",$_;
Why are you splitting into @Line? You never use @Line after this!
> exec("bong $_ );
I imagine the unmatched quotes would cause a syntax error. This isn't a
real program! By not cutting and pasting your real code you are wasting
everyone's time.
> #bong if a dos program for converting tif files to jpg files.
> #exec("ocr --pdf 1.tif \n");
> #print "Pdf File created: \n";
>
> }
------------------------------
Date: Sun, 10 Sep 2006 21:03:58 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: exec command issue
Message-Id: <slrneg9h0e.kc3.tadmc@magna.augustmail.com>
Don Corleone <don@mastah.com> wrote:
> I got a simple program
> @Line = split "\t",$_;
> exec("bong $_ );
Then please show us your simple program, because it is obvious
that this is not it...
Have you seen the Posting Guidelines that are posted here frequently?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 10 Sep 2006 21:09:14 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: exec command issue
Message-Id: <slrneg9haa.kc3.tadmc@magna.augustmail.com>
Don Corleone <don@mastah.com> wrote:
> I got a simple program that reads an file listing using the dos dir command
The program you've posted does not read a file listing using
the dos dir command.
Did you mean to post some other program that _does_ do that?
> and then performs another exec
^^^^^^^
It is impossible to have "another" exec (unless the 1st exec failed).
Have you read the documentation for the function that you are using?
> perl doesnt seem to run the second dos command. ?
Because there IS NO perl program after a sucessful exec().
That is what exec() is supposed to do.
> Any help appreciated.
Read the documentation for the functions that you use.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 11 Sep 2006 08:25:11 +0100
From: "Don Corleone" <don@mastah.com>
Subject: Re: exec command issue
Message-Id: <G42dnQZJiMcPkpjYRVnyug@giganews.com>
Thanks for some of the comments.
In a nutshell this is what i am trying to make the program do:
1. get a directory name (works ok)
2. Get a list of all the tif files in this directory (works ok)
3. perform a msdos file operation on each file returned by 2 above (doesnt
work).
thats it. I dont get why 3 isnt working, any help appreciated.
thanks
"Don Corleone" <don@mastah.com> wrote in message
news:VaOdnWs-KI_9F5nYRVny2w@giganews.com...
> Hey All
>
> I got a simple program that reads an file listing using the dos dir
> command
> and then performs another exec on each file name in the list. Problem is
> perl doesnt seem to run the second dos command. ?
>
> Any help appreciated.
>
> # Get a list of all the files in the directory
> #
> print STDOUT "Enter path: ";
> $path = <STDIN>;
> exec("dir/b /od *.tif $path");
> $result = `PROGRAM`;
>
> # Process each file
>
> while (<>) {
> chomp;
> @Line = split "\t",$_;
> exec("bong $_ );
> #bong if a dos program for converting tif files to jpg files.
> #exec("ocr --pdf 1.tif \n");
> #print "Pdf File created: \n";
>
> }
>
>
>
>
------------------------------
Date: Mon, 11 Sep 2006 08:45:45 +0100
From: "Don Corleone" <don@mastah.com>
Subject: Re: exec command issue
Message-Id: <WMednb8Oh-X_iZjYRVnyhg@giganews.com>
Thanks Tad,
I have made some changes after suggestions from the group, here is the list:
PROBLEM 1:
The System command that replaces exec seems to not pass the information to
msdos correctly, I want this command to run:
dir/b /od $path *.tif
what actually happens (as shown by print @arg) is shown below. the sysmtem
command makes up ".tif1" for some reason.
"dir/b /od c:\test
*.tif1.tif"
PROBLEM2:
The while loop doesnt work at all, its not proecessing each line of the file
list even though i see the file list on the screen ?
thanks all
# program to move files to correct folder
# Get a list of all the files in the directory
use warnings;
print STDOUT "Enter path: ";
$path = <STDIN>;
print "Here is the path you have chosen: $path \n";
# Run the msdos command to get the list
@args = ("dir/b /od $path *.tif");
print @args; # testing only - check the arg
system(@args) == 0
or die "system @args failed: $?"
#Process each file and move to correct folder
while (<>) {
chomp;
@Line = split "\t",$_;
exec("move /y $path c:\archive\*.*");
}
"Tad McClellan" <tadmc@augustmail.com> wrote in message
news:slrneg9h0e.kc3.tadmc@magna.augustmail.com...
> Don Corleone <don@mastah.com> wrote:
>
>
>> I got a simple program
>
>> @Line = split "\t",$_;
>> exec("bong $_ );
>
>
> Then please show us your simple program, because it is obvious
> that this is not it...
>
> Have you seen the Posting Guidelines that are posted here frequently?
>
>
> --
> Tad McClellan SGML consulting
> tadmc@augustmail.com Perl programming
> Fort Worth, Texas
------------------------------
Date: 11 Sep 2006 11:34:41 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: exec command issue
Message-Id: <e47ag2peut8lm4f1pm4214fri1f0jq1v91@4ax.com>
[edited and rearranged for clarity]
On Mon, 11 Sep 2006 08:45:45 +0100, "Don Corleone" <don@mastah.com>
wrote:
>>> I got a simple program
>>
>>> @Line = split "\t",$_;
>>> exec("bong $_ );
^ ^
^ ^ ?!?
>> Then please show us your simple program, because it is obvious
>> that this is not it...
He means that your program as you wrote it here should not even
compile, let alone "work", whatever it is supposed to do. (See the
underlined line above.) It is recommended that you paste your code
rather than retype it.
>> Have you seen the Posting Guidelines that are posted here frequently?
>Thanks Tad,
It seems you *didn't*.
*Please* at least do not top post!! (See the comment at the top.)
> The System command that replaces exec seems to not pass the information to
>msdos correctly, I want this command to run:
> dir/b /od $path *.tif
To run an external program in most cases you either want system() or
qx// or possibly a pipe open().
>what actually happens (as shown by print @arg) is shown below. the sysmtem
>command makes up ".tif1" for some reason.
>
>"dir/b /od c:\test
\t in a quoted string is a tabulation charachter. Thus you want
"c:\\test". But *in perl* (as opposed to cmd.exe, and command.com)
"c:/test" will work just fine - see below.
> *.tif1.tif"
C:\temp>touch foo.tif
C:\temp>perl -le "system 'dir /b /od *.tif'"
foo.tif
Hence, a complete minimal example exhibiting the problem would be
welcome.
Said this, getting a list of files in a directory in perl can be done
without resorting to an external command. You can use opendir() & C.
or have perl do that for you with glob(), which seems appropriate for
your case:
C:\temp>perl -le "print for glob '*.tif'"
foo.tif
Oh, and /od sorts by date: do you really need it? If so then you can
sort() yourself.
>use warnings;
(Do a favour to yourself, letting perl give you all the help it can,
and)
use strict; # as well!
>print STDOUT "Enter path: ";
You've already been told you don't need that STDOUT.
>$path = <STDIN>;
chomp(my $path=<STDIN>);
># Run the msdos command to get the list
>@args = ("dir/b /od $path *.tif");
Even if the following was supposed to work as expected, you would get
a listing of $path *and* of files matching *.tif in CWD.
>print @args; # testing only - check the arg
>system(@args) == 0
>or die "system @args failed: $?"
So far so fine. That's how system() is supposed to work. Please note
that the list of files as *printed* by the system() command is *not*
passed to your perl program in any way.
>#Process each file and move to correct folder
>
>while (<>) {
Huh?!? this is for processing the magical ARGV filehandle which will
"map" either to the arguments supplied on the command line,
interpreted as filenames, if any, or to STDIN if not. What could
possibly make you think that you would process system()'s output like
that?
> chomp;
> @Line = split "\t",$_;
>exec("move /y $path c:\archive\*.*");
Even if the while loop were the right thing to do, it wouldn't cycle
over *all* of the files, unless their total number is either 0 or 1
since exec() still does what it has been told you.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: 11 Sep 2006 11:46:03 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: exec command issue
Message-Id: <5ebag29vnr01bhlajnlviodap1s0usa274@4ax.com>
On Mon, 11 Sep 2006 08:25:11 +0100, "Don Corleone" <don@mastah.com>
wrote:
>1. get a directory name (works ok)
Sorts of.
>2. Get a list of all the tif files in this directory (works ok)
As of your other post, it doesn't. You do *not* get the list. You
print the listing to STDOUT.
>3. perform a msdos file operation on each file returned by 2 above (doesnt
>work).
#/usr/bin/perl
use strict;
use warnings;
use File::Spec;
die 'Usage: $0 <dir>' unless @ARGV==1;
chomp(my $path=shift);
die "$path: not a directory!" unless -d $path;
system "mdoscommand $_"
for glob File::Spec->catfile($path, '*.tif');
__END__
But if the msdos file operation is a 'move', then you may either want
a simple rename() if you are sure it won't cross filesystem's
boundaries, or File::Copy's move() otherwise.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Mon, 11 Sep 2006 10:49:13 +0100
From: "Don Corleone" <don@mastah.com>
Subject: Re: exec command issue
Message-Id: <cMidnRnE88vOrJjYnZ2dnUVZ8s6dnZ2d@giganews.com>
Thanks for the information.
I didn't think 3 simple msdos commands would defeat my perl skills. Recorded
a macro to do the same in less than 2 mins.
perl 1 me 0
;/
"Michele Dondi" <bik.mido@tiscalinet.it> wrote in message
news:e47ag2peut8lm4f1pm4214fri1f0jq1v91@4ax.com...
> [edited and rearranged for clarity]
>
> On Mon, 11 Sep 2006 08:45:45 +0100, "Don Corleone" <don@mastah.com>
> wrote:
>
>>>> I got a simple program
>>>
>>>> @Line = split "\t",$_;
>>>> exec("bong $_ );
> ^ ^
> ^ ^ ?!?
>
>>> Then please show us your simple program, because it is obvious
>>> that this is not it...
>
> He means that your program as you wrote it here should not even
> compile, let alone "work", whatever it is supposed to do. (See the
> underlined line above.) It is recommended that you paste your code
> rather than retype it.
>
>>> Have you seen the Posting Guidelines that are posted here frequently?
>
>>Thanks Tad,
>
> It seems you *didn't*.
>
> *Please* at least do not top post!! (See the comment at the top.)
>
>> The System command that replaces exec seems to not pass the information
>> to
>>msdos correctly, I want this command to run:
>> dir/b /od $path *.tif
>
> To run an external program in most cases you either want system() or
> qx// or possibly a pipe open().
>
>>what actually happens (as shown by print @arg) is shown below. the sysmtem
>>command makes up ".tif1" for some reason.
>>
>>"dir/b /od c:\test
>
> \t in a quoted string is a tabulation charachter. Thus you want
> "c:\\test". But *in perl* (as opposed to cmd.exe, and command.com)
> "c:/test" will work just fine - see below.
>
>> *.tif1.tif"
>
> C:\temp>touch foo.tif
>
> C:\temp>perl -le "system 'dir /b /od *.tif'"
> foo.tif
>
> Hence, a complete minimal example exhibiting the problem would be
> welcome.
>
> Said this, getting a list of files in a directory in perl can be done
> without resorting to an external command. You can use opendir() & C.
> or have perl do that for you with glob(), which seems appropriate for
> your case:
>
> C:\temp>perl -le "print for glob '*.tif'"
> foo.tif
>
> Oh, and /od sorts by date: do you really need it? If so then you can
> sort() yourself.
>
>>use warnings;
>
> (Do a favour to yourself, letting perl give you all the help it can,
> and)
>
> use strict; # as well!
>
>>print STDOUT "Enter path: ";
>
> You've already been told you don't need that STDOUT.
>
>>$path = <STDIN>;
>
> chomp(my $path=<STDIN>);
>
>># Run the msdos command to get the list
>>@args = ("dir/b /od $path *.tif");
>
> Even if the following was supposed to work as expected, you would get
> a listing of $path *and* of files matching *.tif in CWD.
>
>>print @args; # testing only - check the arg
>>system(@args) == 0
>>or die "system @args failed: $?"
>
> So far so fine. That's how system() is supposed to work. Please note
> that the list of files as *printed* by the system() command is *not*
> passed to your perl program in any way.
>
>>#Process each file and move to correct folder
>>
>>while (<>) {
>
> Huh?!? this is for processing the magical ARGV filehandle which will
> "map" either to the arguments supplied on the command line,
> interpreted as filenames, if any, or to STDIN if not. What could
> possibly make you think that you would process system()'s output like
> that?
>
>> chomp;
>> @Line = split "\t",$_;
>>exec("move /y $path c:\archive\*.*");
>
> Even if the while loop were the right thing to do, it wouldn't cycle
> over *all* of the files, unless their total number is either 0 or 1
> since exec() still does what it has been told you.
>
>
> Michele
> --
> {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
> (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
> .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
> 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9710
***************************************
