Python/Perl Command Equivalents

Tinkster · 08-20-2011, 11:38 PM

Quote:

Originally Posted by kbp

Just to stir the pot ... I used to do everything in perl but I find python a lot cleaner - meaning it's easier to read and maintain.

I'm starting to use Python more frequently because of XML-rpc;
while it's fairly easy to pull everything needed in from CPAN
on my Slackware box, in a corporate environment, running RHEL
on s390 it's a pain in the proverbial. Most of the dependencies
aren't available on EPEL for s390; Python does XML-rpc out of
the box (ancient as the version in RHEL is).

I'm starting to like some of the python ways of doing things ...

Cheers,
Tink

ghostdog74 · 08-21-2011, 04:45 AM

Here are some of the shell equivalents (non-exhaustive) for Python. For os specific tasks, use the os module. (check the docs, not going to link for you here )

1) listing files/directories (ls equivalent)

Code:

import os
for file in os.listdir("/path"):
    print file

# or you can use glob (much like shell globbing)
import glob
for file in glob.glob("*pattern*"):
    print  file

# to go through the file system (or any path ) just like the find command 
for r,d,f in os.walk("path"):
    for file in f:
        print file

2) To move/copy files. Use the shutil module. There are also methods like copytree etc similar to cp -r

Code:

import shutil
shutil.move(....)  # mv equivalent
shutil.copy(....)  # copy equivalent

3) To rename/remove files

Code:

os.rename("old","new")
os.remove(...)

4) head/tail/cat etc. All these involve opening file handle, doing something with the file handle, and closing it

Code:

# head example (head -n 4)
n=4
f=open("file"):
for i in range(0,n):
    print f.readline()    
f.close()
    

# cat equivalent

for line in open("file"):
    print line

5) simple grepping for text files

Code:

for line in open("file"):
    if "pattern" in line:
          print line

6) cut equivalent. Basically, cutting is just splitting up text according to fields and processing

Code:

for line in open("file"):
    splitted_text = line.split(delimiter)
    print splitted_text[:3]  # cut -d delimiter -f1-3

7) ftp (use ftp module)
8) telnet (use telnetlib module)

and many more.........

Proud · 08-21-2011, 05:01 AM

Quote:

Originally Posted by Woodsman

Based on some of the replies, I did not explain myself well.

As I mentioned in my last sentence, the idea here is to reduce external command dependencies.

I think I got you, I don't know if you got me.

You really need to clarify if having your users/IT people install perl/python plus tk/wxwindows is going to be ok and look ok, or if you need something easier to work with like Java's Swing. Because you don't want to have to port a half/mostly working solution from perl/python after you've got to the point of trying to make a GUI and finding you/users/IT don't like it.

Quote:

The challenge: convert the shell script into a tool that will be used by non computer people in Windows. Basically that means a point-and-click interface.

Non computer people.

Using a terminal and typing commands is out of the question. A work-around to that criterion is if the script runs transparently as a desktop shortcut. I have created several small "batch files" for these people that run this way. Users point and click to the script shortcut but never actually deal with a terminal window. A similar solution could succeed here too.

Does this still stand?

j-ray · 08-21-2011, 05:05 AM

Quote:

...but for this small app, you might find it much quicker and easier to create and deploy a Java Swing GUI than something in other languages.

Quicker and easier than a perl or python script?
Definetely not.

Sergei Steshenko · 08-21-2011, 05:40 AM

Quote:

Originally Posted by kbp

Just to stir the pot ... I used to do everything in perl but I find python a lot cleaner - meaning it's easier to read and maintain.

Typically such claims indicate lack of Perl knowledge.

Proud · 08-21-2011, 05:56 AM

Because Perl is notoriously easy to read.

j-ray, I'm talking just to make a GUI or some popup dialogs that have a nice look&feel, and ensuring all the dependencies are set up on the system. JRE means you're good to go.

Code:

JOptionPane.showMessageDialog(frame, "Eggs are not supposed to be green.");

http://download.oracle.com/javase/tu...og.html#create

Sergei Steshenko · 08-21-2011, 06:45 AM

Quote:

Originally Posted by Proud

Because Perl is notoriously easy to read. ...

I remember posting in a different forum a snippet of Python code stolen from here. A very short snippet. People after that were laughing big time about Python readability.

It's the programmer who mostly causes unreadable code.

Seriously, I reject Python first and foremost for lack of lexical scoping. And for lack of arrays. And for whitespaces being used to denote code blocks - and I do indent in Perl/"C".

Proud · 08-21-2011, 06:58 AM

Come on, perl's nicknamed a write-only language, the rep is for a reason even if in jest.
Kinda hard to write python that's super bad being as how whitespace has meaning especially for flow control. And why have to use curly braces when you'd have been in error without them anyway if you do as you say and indent correctly.

I might need to brush up on lexical scoping and python but I'm not clear where it's lacking sane scoping. http://docs.python.org/py3k/referenc...tionmodel.html

Also what are you on about lack of arrays? You wish to edit lists/sequences in place explicitly aka manage the memory behind them, and permit uninitialised entries?

markush · 08-21-2011, 06:59 AM

Quote:

Originally Posted by kbp

Just to stir the pot ... I used to do everything in perl but I find python a lot cleaner - meaning it's easier to read and maintain.

Quote:

Originally Posted by Proud

Because Perl is notoriously easy to read.

Well, Larry Wall, the creator of Perl, is a Linguist. Perl is designed to be as context-sensitive as any human language. As in any human language it is necessary to learn the language before one can "see" the context.

This is in my opinion the main difference between Perl and the so called "easier to read" languages like Python or Ruby.

Btw, Perl has never been easy for me, though I'm "learning" it since version 4.

Markus

MTK358 · 08-21-2011, 07:58 AM

Quote:

Originally Posted by Proud

j-ray, I'm talking just to make a GUI or some popup dialogs that have a nice look&feel

Code:

JOptionPane.showMessageDialog(frame, "Eggs are not supposed to be green.");

http://download.oracle.com/javase/tu...og.html#create

Python with PyQt4 is just as simple (if not simpler):

Code:

QMessageBox.information(window, "Example", "Eggs are not supposed to be green.")

EDIT: And it's not just the GUI functions that make it easier to write a program, it's the language itself. Python is much easier to work with than Java.

Sergei Steshenko · 08-21-2011, 07:58 AM

Quote:

Originally Posted by Proud

Come on, perl's nicknamed a write-only language, ...

At the moment:

Quote:

The Comprehensive Perl Archive Network (CPAN) currently has 98,377 Perl modules

If you have difficulties reading, don't blame Perl. Or you want to say all those module are written for nothing, nobody uses them, nobody submits patches ?

As I wrote many times here, my first acquaintance with Python happened in 2000, and it was through a very intelligent guy who knew both Perl and Python.

The acquaintance was through the following process: "Here are things I do in Perl this way for this reason - what is the equivalent in Python ?". At that moment for many things there was no equivalent. Furthermore, we took a production data structure occupying ~250MBytes in memory and translated it into Python. Python simply crashed with segmentation fault.

Python has evolved since, I am watching it. Python-3.x.y is quite different from Python-2.x.y - backward compatibility is broken. Opposed to that, Perl developers pay a lot of attention to regression testing.

Python is slowly catching up with Perl, for example: http://en.wikipedia.org/wiki/Function_object#In_Python - closures were introduced in Perl 5 in mid nineties.

...

Code:

def accumulator(n):
    def inc(x):
        nonlocal n
        n += x
        return n
    return inc

- how ugly is that "nonlocal" - exactly because of lack of lexical scoping. How ugly is the "return" statement.

In Perl

Code:

sub # an anonymous function
  {
  my ($n) = @_;

  sub # since it is the last executed expression in the outer 'sub', it's also the returned value - code reference
      # the code reference points to this anonymous function
    {
    my ($x) = @_;

    $n += $x; # since it's the last executed expression in the inner 'sub', it's also the returned value - a numeric value
    }
  }

.

The above code can be rewritten without '$x':

Code:

sub{my ($n) = @_; sub{$n += $_[0]}}

.

Of course, a name can be given in the consuming scope, e.g.

Code:

my $accumulator = sub{my ($n) = @_; sub{$n += $_[0]}};
my $accumulator_instance = $accumulator->(2);
my $result = $accumulator_instance->(5);

.

ghostdog74 · 08-21-2011, 09:37 AM

Quote:

Originally Posted by Sergei Steshenko

And for lack of arrays.

And this indicate a lack of Python knowledge. Before you take a dig at other people's preferences, maybe you should take a look at it yourself.

TobiSGD · 08-21-2011, 10:03 AM

Hey, anyone, the OP is looking for advice how to make his scripts platform independent, not another Python/Perl flamewar.
Both languages are able to achieve what the OP want, no need for that discussions about readability, there is only one person here that can decide which language suits him better: the OP.

Woodsman · 08-21-2011, 10:34 AM

Thanks everybody for the responses. I get the big picture that at least for Perl and Python, there are ways to perform the same tasks that are performed in shell scripts. Might require some digging into various external modules, but seems porting an equivalent and functional script to either is possible. That observation likely is true for many languages.

Quote:

I think I got you, I don't know if you got me.

I think we are getting each other, just focusing on different objectives.

Quote:

You really need to clarify if having your users/IT people install perl/python plus tk/wxwindows is going to be ok and look ok

I don't think that topic was discussed in detail in either thread. I am aware that portability of a script does not mean the script can be run in other environments. When I started this project one of the first questions I asked is what scripting languages the IT people support. I haven't yet received an answer.

Bottom line is if IT personnel do not support Perl or Python, or refuse to support, then portability is a moot issue. In my other thread I addressed that I might have to port the shell script to VB Script because that is a native scripting language in Windows. That option remains open because although I installed Cygwin in my testing system to run my shell script, and I created two desktop shortcuts so the non computer people don't have to deal with the terminal or command line, I still don't yet have permission to implement that solution.

Quote:

Does this still stand?

Yes, but that statement was in another thread and the topic in this thread is different although somewhat related

. User skills drive these decisions. You and I might dislike how typical end-users are treated with respect to learning new computer skills, but after three decades I have seen no general change in that attitude. Users will learn new apps but only as much as they need to get by. Most will not dig deeper into an app or process. The people I have worked with through the years are smart people, they just don't care to become more skilled with computers than they are interested in changing the oil on their car or repairing a leaky faucet. Likewise with terminals and the command line. Ain't gonna happen with most of these people. They simply have different priorities in life. These people are all born and bred in a Windows environment and that is what they use at home. Point-and-click. Using a terminal is a horrifying idea to them.

Sergei Steshenko · 08-21-2011, 11:49 AM

Quote:

Originally Posted by ghostdog74

And this indicate a lack of Python knowledge. Before you take a dig at other people's preferences, maybe you should take a look at it yourself.

Oh, really ?! How about:

http://docs.python.org/library/array.html :

Quote:

This module defines an object type which can compactly represent an array of basic values: characters, integers, floating point numbers.

.

In Perl arrays are built-in, come with language, not with a module.