It's probably easier to open the file as UTF-16

open my $fh, "<:encoding(UTF-16)", $filename or ...
[download]

and then operate on the resulting text string as usual...

(Use UTF-16LE, in case the file should have no BOM.)

That's a good idea and I may resort to that. I had it in my head to get this piped from the output. Can I open a pipe as UTF-16?

Update: I was thinking of a syntax like:
wmic process | find /i "myprog.exe" | getmyfields.pl

---

#my sig used to say 'I humbly seek wisdom. '. Now it says:
use strict;
use warnings;
I humbly seek wisdom.

This appears to work:

wmic.exe process | perl -CS script.pl
[download]

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

I wrestled with wmic a while back and came up with a very perl-friendly way to access the data.

The key is using list /format:value on the command line.

-Craig

use strict;
use Tk;
use Data::Dumper;

my %DATA;

# Get info via wmic (not available on all versions of windows)...
my @data = split(/^\s*\cM\n/m, `wmic process list /format:value`);
shift(@data); pop(@data);    # Remove first/last blank lines

my %procs;
# Iterate through each element...
foreach my $p (@data) {
    $p =~ s/\cM//g;            # Grrrr, rotten windows
    my %child = split(/[=\n]/, $p);    # Hashify information
    $procs{$child{ProcessId}} = \%child;
}

print Dumper(\%procs), "\n";
[download]

Very good, but it doesn't quite meet our use case. Our Admin knows the exe name he's looking for, but there could be several running at one time differentiated by the command line arguments. Task Manager shows them all, but not the command line arguments, so the admin doesn't know which to kill. wmic process list full produces outpout similar to your /format:value, so we did things like wmic process list full | find /i "ourprog.exe", but when more than one was running, couldn't tell the pid (because it's on another line). Just plain wmic process put all the data on one line so that's what I was thinking about and it colored my design space.

I actually like your hash-ification better, and if I were writing a larger program (I see you have Tk in your use statements) that's exactly how I'd go.

Thanks again.

---

#my sig used to say 'I humbly seek wisdom. '. Now it says:
use strict;
use warnings;
I humbly seek wisdom.

I learned some things while working on this little problem, so I thought I'd share. update: changed $ARGV[0] for @ARGV per discussion.

The first thing is that wmi doesn't necessarily use the same fixed headers on different machines. My first attempt was a simple batch file and worked on my machine:

So, I ended up turning it inside-out. Instead of using perl in a batch file I used the wmic command in a perl script. I ended up opening a file (well, pipe) like almut suggested, but using BrowserUK's command line option to cover the unicode issue.

If I were to spend more time on it I would get the common code (to get the position of a field and also to constuct the output lines) out into functions. Also, I've rethunk how to get the length of the fields by looking for something like /\G(\b)/gc, but it's a fairly strightforward little throw-away script, so I'm not going to spend that much more time on it.

Back to lessons learned:
- if you're searching for 'ProcessID' you'll find it in 'ParentProcessID' (duh!); this messed me up for a little bit and drove me to put all that $nextField logic in (again, I've rethunk it and think it would be more elegant with \G).
- -CS worked on the command line, but when I added it to the she-bang (#!/usr/bin/perl -CS -W) it complained about an 'Unknown Unicode option letter'. I finally figured out I had to combine things in the command options as #!/usr/bin/perl -WCS. In retrospect, there are other problems in my past that are explained by this and I never knew it.
- I had to pos=undef; to get the search to reset, since it didn't search backwards from the previous match.
- $#ARGV is 0 whether there are zero or 1 arguments. This led me to the $ARGV[0] ? : solution.
- I was worried about getting the output fields in the order I want and was happy to learn that using @location in the template let me bounce around in the string and still return the fields in the order they appreared in the template.

I'm sure there are other lessons here and many wasy to improve my little script, but as I said, I probably won't spend any more time on it (the script that is; I'll happily spend time learning form any feedback I get here). I hope the lessons learned are helpful.

$#ARGV is 0 whether there are zero or 1 arguments.

That's not true. $#ARGV is -1 when there are no arguments.

And by the way, I think -CS is unnecessary and even harmful. wmic probably outputs characters based on your local, so use open ':std', ':locale'; would be more appropriate.

Hrmmm . . . I copied only the relevant code from my script, above:


C:\chas_sandbox\columns-by-name>
copy con ARGVtest.pl
#!/usr/bin/perl -WCD

use strict;
use warnings;
use Data::Dumper;

$\ = $/;
my $debug = 1;

#array of fields to display
my @processFields = ('Caption','ParentProcessId','ProcessId','CommandL
+ine');

#ARGV processing
my $searchfor = $ARGV[0] ? join(' ',@ARGV) : die("I need a process to 
+look for."
);
^Z
        1 file(s) copied.

C:\chas_sandbox\columns-by-name>
notepad ARGVtest.pl
[download]

and changed it a little (in notepad, above) and tested it:


C:\chas_sandbox\columns-by-name>
type ARGVtest.pl
#!/usr/bin/perl -WCD

use strict;
use warnings;
use Data::Dumper;

$\ = $/;
my $debug = 1;

#array of fields to display
my @processFields = ('Caption','ParentProcessId','ProcessId','CommandL
+ine');

#ARGV processing
my $searchfor = $#ARGV ? join(' ',@ARGV) : die("I need a process to lo
+ok for.");
#               ^^^^^^ change here

C:\chas_sandbox\columns-by-name>
ARGVtest.pl
I need a process to look for. at C:\chas_sandbox\columns-by-name\ARGVt
+est.pl lin
e 14.

C:\chas_sandbox\columns-by-name>
ARGVtest.pl chas
I need a process to look for. at C:\chas_sandbox\columns-by-name\ARGVt
+est.pl lin
e 14.
[download]

and added some debug (in notepad again) and tested again:


C:\chas_sandbox\columns-by-name>
type ARGVtest.pl
#!/usr/bin/perl -WCD

use strict;
use warnings;
use Data::Dumper;

$\ = $/;
my $debug = 1;

#array of fields to display
my @processFields = ('Caption','ParentProcessId','ProcessId','CommandL
+ine');

#ARGV processing
print Dumper(\@ARGV);
print $#ARGV;
my $searchfor = $#ARGV ? join(' ',@ARGV) : die("I need a process to lo
+ok for.");


C:\chas_sandbox\columns-by-name>
ARGVtest.pl
$VAR1 = [
          ''
        ];

0
I need a process to look for. at C:\chas_sandbox\columns-by-name\ARGVt
+est.pl lin
e 16.

C:\chas_sandbox\columns-by-name>
ARGVtest.pl chas
$VAR1 = [
          ' chas'
        ];

0
I need a process to look for. at C:\chas_sandbox\columns-by-name\ARGVt
+est.pl lin
e 16.
[download]

. . . and it sure looks like $#ARGV is 0 either way. I totally trust your experience, so I conclude that either my test is wrong or my conclusions are. Does the she-bang line arguments mess this up or something?

---

#my sig used to say 'I humbly seek wisdom. '. Now it says:
use strict;
use warnings;
I humbly seek wisdom.

Thanks and ++ for the tip about :std or :locale. It's working in place as is, so I'll file this away for the next time I'm working on it. Again, it's a one-off script, but this is a good place to document the caveats for others who might be researching similar things.

---

#my sig used to say 'I humbly seek wisdom. '. Now it says:
use strict;
use warnings;
I humbly seek wisdom.