/ 
Unix-0.02
/ Unix

NAME

Unix - Perl extension for shell access

SYNOPSIS

use Unix;

my $fh = UNIX ("ps -eaf");

while ( <$fh> ) {
   warn $_;
}  

my $fh = UNIX "cat /etc/passwd";  

# fine as long as getline() doesnt return 0
while ($_ = $fh->getline) { 

   print ( (split ':')[4], $/ );

}

DESCRIPTION

This module is nothing but syntactic sugar for something I do a lot of:

use FileHandle;
my $fh = new FileHandle "$unix_cmd |";

I just prefer the cleanliness of:

use Unix;
my $fh = UNIX $unix_cmd;

In other words, I prefer the DWIM approach that this module affords me, albeit a small amount.

I imagine this might work on Windows and other machines.

Response to Criticisms at http://cpanratings.perl.org/d/Unix

Simon Cozens

In Software Engineering it is very important that you state what you intend to do as opposed to actually doing it. If a piece of code performs the same conceptual function more than once, then that concept must be packaged.

To wit, a recent thread on Perlmonks.org shows just how widely people's views contrast on this subject. The thread:

http://perlmonks.org/index.pl?node_id=287647

was about how to "slurp" a file. Some people were keen on my $string = do {local $/;<DATA};> while someone else suggested File::Slurp to which came the query:

why get a module and a function just for this two expression idiom?

And that is the central point and one on which I am _very_ obsessive about my code talking to a human as opposed to talking to a computer... definitional succinctness is and always will be my guiding factor. If you can show a more definitional way of handling this process, I am all ears.

Regarding a top-level namespace, I am very conscientious about creating new top-level namespaces. There were already several Unix::* modules on CPAN, so I did not feel I have created another.

True, this module is not Unix-specific, but it was Unix-*inspired*.

Response to Juerd

"Just syntactic sugar" and its importance in my coding style was discussed above.

Regarind the amount of space taken for a such a simple module, it is unfortunate that the only available packaging in Perl is modules. I think a C preprocessor macro is more appropriate for the intent of Unix.pm... did you see the type of voodoo that was required in Semi::Semicolons to do a simple string rewrite? In plain C, one could simply write:

#define peterbilt ;

and be done. It would be nice to have some sort of CPP for Perl... one that is simpler than the current source filters.

Regarding testing, what kind of test could I do that would run on someone else's machine for certain. Ditto for portability.

Response to Unspoken Criticism

I spent a good amount of time on CPAN looking for a solution to what I wanted. I looked at Pipe and Proc::SafePipe but nothing really seemd to fit.

AUTHOR

T. M. Brannon, <tbone@cpan.org>

SEE ALSO

Proc::SafePipe.