ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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 ...
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
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.
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.");
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".
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.
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?
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.
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.
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.
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);
.
Last edited by Sergei Steshenko; 08-21-2011 at 08:00 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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.