Re: Opinion on best practice...
On Sat, Feb 9, 2013 at 5:29 AM, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: If you want the real nightmare -- look into the IBM queue scheme (not many REXX implementations except on IBM mainframes support that). One can push lines onto the queue, such that when the script exits, the command processor reads those lines first before reading from keyboard... Or push lots of text in a way that the next script to start reads it without using a temporary file. IBM mainframes didn't multitask too well G; no easy creation of processes with pipes between them. Heh. The OS/2 implementation of REXX has that too, but also has much easier piping mechanisms... and, ironically, provides a convenient way to pipe text into your script using the RXQUEUE external command: some_command | rxqueue /fifo do while queued()0 parse pull blah blah blah end ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On Tuesday, February 5, 2013 5:55:50 PM UTC-8, Steven D'Aprano wrote: To do anything meaningful in bash, you need to be an expert on passing work off to other programs... [snip] If you took the Zen of Python, and pretty much reversed everything, you might have the Zen of Bash: I have to agree. Recently I needed to write some glue code which would accept some input; run a few Linux command-line programs which were supplied that input; run some Matplotlib scripts of my own to graph the results; and finally, clean up some unwanted intermediate files. I realized that bash was the right way to get the job done... but after struggling with bash for a day, I decided to try Python. I wrote a shell script that starts with #!/usr/bin/env python. My program imports os, sys, and shlex.split. I had my first working version within about four hours, even though I had never written a command-line Python program before. Over the next several months, I returned to the program to make several improvements. I can't imagine maintaining a bash script that does what my Python script does. -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
Chris Angelico wrote: On Thu, Feb 7, 2013 at 5:50 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 07 Feb 2013 16:28:17 +1100, Chris Angelico wrote: You misunderstand. It's actually a very simple rule. Python follows C's principle of accepting that any return value from an expression should be ignored if you don't do anything with it. Return values are safe. They don't do anything, since they are *being ignored*, not being executed as code. You have to explicitly choose to do something with the return value before it does anything. If C said if you don't do anything with the return result of an expression, execute it as code in the shell, would you consider that a desirable principle to follow? def oh_my_stars_and_garters(): return rm -rf / oh_my_stars_and_garters() Naming a function is safe, too. def earth_shattering(): os.system(rm -rf /) earth_shattering; But putting parentheses after it suddenly makes it dangerous. Wow! Yes, that is correct. Because now you are executing code, which could do something, and some things are dangerous. But Python will never execute code unless you explicitly tell it to. There's no concept in Python of falling back onto code execution if parsing fails. Python's pretty risky, right? Not really, because Python never executes anything you don't tell it to. But on the other hand, compared to the sandboxing capabilities of Java and Javascript, Python *is* pretty risky. Hell, we known how risky Javascript and Actionscript are (Flash vulnerabilities are now the number 1 source of malware, or so I understand), and they're designed to run in a secure sandbox. Python isn't. Some rather innocent-looking things *could* involve code execution (e.g. imports, attribute access). But given the assumption that you know what you're doing, and you don't eval() or exec() untrusted strings, Python never executes code *by mistake*. You might write the wrong code (you can do that in any language) but Python will never cause something to be executed *because it can't parse it*. If something doesn't parse, you get a syntax error. In REXX, you simply don't *do* that sort of thing. (You'd use the CALL statement, for instance.) Well, Dennis claims that he *does* do it, and that it is one of the better features of REXX. And in the code snippet you published earlier, I saw plenty of code intended for the shell, but no CALL statement in sight. I note that you ignored my question. If REXX reaches code that fails to parse, does it send it to the shell to be executed by default? If the answer was No, I expect you would have said so. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
Dennis Lee Bieber wrote: Line 3 has unquoted echo which is not a REXX command; it is considered an external command and is passed the /result/ of calling REXX time() -- where Windows executes it Good lord, that's even worse than I feared. So it's not just unparsable non-REXX code that is implicitly sent to the shell, but the equivalent to Python's NameErrors. And you can implicitly mix calls to the shell and REXX function calls in the same line. I know that sometimes Python's lack of declarations for variables causes problems. If you make a typo when assigning to a variable, Python will go ahead and create a new variable. But if you make a typo when *calling* a function, or try to call something that doesn't exist, you get an exception, not silently pushing the typo off to some other process to be executed. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
Dennis Lee Bieber wlfr...@ix.netcom.com writes: PowerShell is meant to be used for administrative level scripting, replacing such things as WSH. Yeah and WSH has been included since Windows 98... So Windows has been at least OK with shell scripting VBScript and JScript for the last 15 years or so. And I can't believe I'm defending Windoze. -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 2013-02-05, Grant Edwards invalid@invalid.invalid wrote: On 2013-02-05, Neil Cerutti ne...@norwich.edu wrote: On 2013-02-05, Walter Hurry walterhu...@lavabit.com wrote: Sorry, I'm a Linux guy. I have no clue what that means. Hooray for common sense! Python is great, but it's silly to use Python (unless there is good reason) when a simple shell script will do the job. Python is an excellent option for writing shell scripts, particularly if your shell is cmd.exe. The OP stated explicitly that the target OS was Linux: I need to pick up a language that would cover the Linux platform. I use Powershell for a scripting language on the Windows side of things. Don't get me wrong -- I think Python is great -- but when the target OS is Linux, and what you want to do are file find, move, copy, rename, delete operations, then I still say bash should be what you try first. I had Cygwin on my office computer for many years, and wrote shell scripts to do things like reconcile fund lists from separate source files, and generate reports of the differences. Here's the top-level script. Both files have to be preprocessed before comparing them. #!/bin/sh awk -f step1.awk -v arg=$1.spec $1 | sort | awk -f step2.awk t1.out awk -f step1.awk -v arg=$2.spec $2 | sort | awk -f step2.awk t2.out ./recon.pl I'm bad at shell scripts, obviously (step1? step2? Why doesn't recon.pl use the command line arguments?). I used several programs together that I knew only how to read the docs for. Honestly, my first Python scripts from those days aren't that much better, and have nearly all been themselves abandoned. Today I'm much more productive with Python. Virtually all my programs are data conversion and comparisons, with a good deal of archiving and batch processing of large groups of files. I can imagine a programmer who is learned in sh, sed, awk, sort and sundry who would do just fine at these tasks, but I can't imagine myself going back. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 2013-02-06, Ian Kelly ian.g.ke...@gmail.com wrote: On Tue, Feb 5, 2013 at 3:59 PM, Grant Edwards invalid@invalid.invalid wrote: On 2013-02-05, Neil Cerutti ne...@norwich.edu wrote: On 2013-02-05, Walter Hurry walterhu...@lavabit.com wrote: Sorry, I'm a Linux guy. I have no clue what that means. Hooray for common sense! Python is great, but it's silly to use Python (unless there is good reason) when a simple shell script will do the job. Python is an excellent option for writing shell scripts, particularly if your shell is cmd.exe. The OP stated explicitly that the target OS was Linux: The impression I got was that he was looking for something that would be cross-platform and work in both Windows and Linux. Python is a reasonable choice for that if you're not willing to deal with Cygwin. True, the _language_ of Python is cross-platform, but doing much of anything filesystem/administration related in a cross-platform manner can be painful. -- Grant Edwards grant.b.edwardsYow! I feel like I'm at in a Toilet Bowl with a gmail.comthumbtack in my forehead!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 2013-02-06, Neil Cerutti ne...@norwich.edu wrote: On 2013-02-05, Grant Edwards invalid@invalid.invalid wrote: On 2013-02-05, Neil Cerutti ne...@norwich.edu wrote: On 2013-02-05, Walter Hurry walterhu...@lavabit.com wrote: Sorry, I'm a Linux guy. I have no clue what that means. Hooray for common sense! Python is great, but it's silly to use Python (unless there is good reason) when a simple shell script will do the job. Python is an excellent option for writing shell scripts, particularly if your shell is cmd.exe. The OP stated explicitly that the target OS was Linux: I need to pick up a language that would cover the Linux platform. I use Powershell for a scripting language on the Windows side of things. Don't get me wrong -- I think Python is great -- but when the target OS is Linux, and what you want to do are file find, move, copy, rename, delete operations, then I still say bash should be what you try first. I had Cygwin on my office computer for many years, and wrote shell scripts to do things like reconcile fund lists from separate source files, and generate reports of the differences. Back when the earth was young, I used some pretty extensive Bourne shell scripts to perform design checks on multi-volume software requirements specifications that were written in LaTeX -- and that was on VAX/VMS with DECShell (sort of the VMS equivalent of Cygwin). It worked fine but it was excruciatingly slow because of the high fork() overhead in VMS. -- Grant Edwards grant.b.edwardsYow! If Robert Di Niro at assassinates Walter Slezak, gmail.comwill Jodie Foster marry Bonzo?? -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 2013-02-06, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Chris Angelico wrote:
Python is not an excellent option. It's a bad fit for shell
scripting, it just happens to be way better than a weak shell. Having
grown up on command.com, I found OS/2's cmd.exe to be a massive
improvement, and Windows's cmd.exe to be rather less impressive... but
both of them pale into insignificance compared to bash.
I have to disagree with much of this. bash is a poorly designed
language which, in my opinion, is only good enough for short (under
20 lines) throw-away scripts.
And the OP wanted to write someting that was what, about 3 lines?
This is how you test whether something is not the name of a directory:
[[ -d $dir ]] || {
echo $FUNCNAME: $dir is not a directory 2
return 2
}
It can be written more clearly.
http://www.bashcookbook.com/bashinfo/source/bash-4.2/examples/functions/emptydir
Arithmetic requires either calling an external program, or special magic
syntax:
z=`expr $z + 3`
i=$(( i + 1 ))
Agreed: Bash is not good at math. It should not be used for numerical
analysis.
Spaces are magic -- these two lines do radically different things:
So? Leading spaces are magic in Python.
bash is even more weakly typed than Perl. As far as I can tell, bash
is completely untyped -- everything is text, all the time, even
arrays.
Correct. In bash, everything is a string.
If you're doing something other than manipulating files (and therefore
filenames and paths), then bash is probably the wrong language to use.
--
Grant Edwards grant.b.edwardsYow! Are we wet yet?
at
gmail.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
Dennis Lee Bieber wrote: On Wed, 6 Feb 2013 17:16:04 +1100, Chris Angelico ros...@gmail.com declaimed the following in gmane.comp.python.general: It feels silly enough translating this OS/2 batch script: @logon SOME_USER /pSOME_PASS /vl @e:\rexx\load @db2 start database manager @exit into this REXX script: /* */ @logon SOME_USER /pSOME_PASS /vl @e:\rexx\load @db2 start database manager @exit And that's a change I've made myriad times (to \startup.cmd on many an OS/2 boot drive) It's far far worse translating it into Python, Pike, or any other good language. Though that is the nice feature of REXX*... Anything that wasn't parsable as a REXX statement was automatically sent to the current command processor. Nice? Are you being sarcastic? What you're describing sounds like a classic Do What I Mean system, which invariably end up being followed by anguished shouts of N, I didn't mean that!!!. The Zen of Python is not just design principles for *Python*. They hold for other languages as well. Having to explicitly send a command to an external command processor (say, the shell) is much better **and safer** than implicitly doing so on SyntaxError, even if such a requirement makes your program more verbose. Converting such to Python turns into a mishmash of (pick your favorite) os.system(), subprocess.Popen(), etc. with their particulars of how to pass command line arguments. Why on earth would anyone use a mismash within the one script? Pick one and stick to it. If you have only wish to give a few commands, and don't care about getting data back from them, use os.system which is embarrassingly easy and almost as concise as the REXX script above: from os import system as s s(@logon SOME_USER /pSOME_PASS /vl) s(@e:\rexx\load) s(@db2 start database manager) s(@exit) If you find yourself needing complicated string escapes, use subprocess.call instead. If you do care about getting data back from the external system, then you need to integrate the external code with your Python (or REXX) code, and that requires more than just firing off a few system commands and forgetting about them. That's inherently complicated, because there are many possible factors to care about: - do you care about stdout, stderr, stdin? - start a new subshell? - deal with shell metacharacters? - deadlocks? etc. Lack of terse syntax is the least of your worries here, doing these things *correctly* is hard in the shell. Having to type a few extra symbols doesn't make it any harder in any meaningful way, and readable syntax can actually make it simpler to reason about the code. If you say Anything that isn't parsable is automatically sent to the shell, it doesn't sound too bad. But when you say Unparseable junk is implicitly treated as code and sent off to be executed by something which traditionally tends to be forgiving of syntax errors and has the ability to turn your file system into so much garbage, it sounds a tad less appealing. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On Thu, Feb 7, 2013 at 10:46 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Dennis Lee Bieber wrote: Though that is the nice feature of REXX*... Anything that wasn't parsable as a REXX statement was automatically sent to the current command processor. Nice? Are you being sarcastic? What you're describing sounds like a classic Do What I Mean system, which invariably end up being followed by anguished shouts of N, I didn't mean that!!!. If you say Anything that isn't parsable is automatically sent to the shell, it doesn't sound too bad. But when you say Unparseable junk is implicitly treated as code and sent off to be executed by something which traditionally tends to be forgiving of syntax errors and has the ability to turn your file system into so much garbage, it sounds a tad less appealing. You misunderstand. It's actually a very simple rule. Python follows C's principle of accepting that any return value from an expression should be ignored if you don't do anything with it. REXX says that any bare expression used as a statement is implicitly addressed to the default host, which is usually a shell (though I built myself a MUD system where the default would send text to the client, and shell execution required ADDRESS CMD some_command explicitly); it's very simple and doesn't feel like a DWIM system at all. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On Thu, 07 Feb 2013 16:28:17 +1100, Chris Angelico wrote: On Thu, Feb 7, 2013 at 10:46 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Dennis Lee Bieber wrote: Though that is the nice feature of REXX*... Anything that wasn't parsable as a REXX statement was automatically sent to the current command processor. Nice? Are you being sarcastic? What you're describing sounds like a classic Do What I Mean system, which invariably end up being followed by anguished shouts of N, I didn't mean that!!!. If you say Anything that isn't parsable is automatically sent to the shell, it doesn't sound too bad. But when you say Unparseable junk is implicitly treated as code and sent off to be executed by something which traditionally tends to be forgiving of syntax errors and has the ability to turn your file system into so much garbage, it sounds a tad less appealing. You misunderstand. It's actually a very simple rule. Python follows C's principle of accepting that any return value from an expression should be ignored if you don't do anything with it. Return values are safe. They don't do anything, since they are *being ignored*, not being executed as code. You have to explicitly choose to do something with the return value before it does anything. If C said if you don't do anything with the return result of an expression, execute it as code in the shell, would you consider that a desirable principle to follow? def oh_my_stars_and_garters(): return rm -rf / oh_my_stars_and_garters() REXX says that any bare expression used as a statement is implicitly addressed to the default host, which is usually a shell (though I built myself a MUD system where the default would send text to the client, and shell execution required ADDRESS CMD some_command explicitly); it's very simple and doesn't feel like a DWIM system at all. Are you saying that Dennis' description of REXX sending unparsable text to the shell for execution is incorrect? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On Thu, Feb 7, 2013 at 5:50 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 07 Feb 2013 16:28:17 +1100, Chris Angelico wrote: You misunderstand. It's actually a very simple rule. Python follows C's principle of accepting that any return value from an expression should be ignored if you don't do anything with it. Return values are safe. They don't do anything, since they are *being ignored*, not being executed as code. You have to explicitly choose to do something with the return value before it does anything. If C said if you don't do anything with the return result of an expression, execute it as code in the shell, would you consider that a desirable principle to follow? def oh_my_stars_and_garters(): return rm -rf / oh_my_stars_and_garters() Naming a function is safe, too. def earth_shattering(): os.system(rm -rf /) earth_shattering; But putting parentheses after it suddenly makes it dangerous. Wow! Python's pretty risky, right? In REXX, you simply don't *do* that sort of thing. (You'd use the CALL statement, for instance.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 2/4/2013 11:14 PM, Anthony Correia wrote: I need to pick up a language that would cover the Linux platform. I use Powershell for a scripting language on the Windows side of things. Very simple copy files script. Is this the best way to do it? import os objdir = (C:\\temp2) colDir = os.listdir(objdir) for f in colDir: activefile = os.path.join(objdir + \\ + f) print (Removing + activefile + from + objdir) os.remove(activefile) In Powershell I would just do: $colDir = gci -path c:\temp2 ForEach($file in $colDir) Python comes with a shutil module with multiple copy functions. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
Am 05.02.2013 05:14, schrieb Anthony Correia:
I need to pick up a language that would cover the Linux platform. I use
Powershell for a scripting language on the Windows side of things. Very simple
copy files script. Is this the best way to do it?
import os
objdir = (C:\\temp2)
Drop the parens here.
colDir = os.listdir(objdir)
for f in colDir:
activefile = os.path.join(objdir + \\ + f)
The point of os.path.join is exactly that you don't have to spell out
the system-specific file separator. In this case, it gets called with a
single string, which it return as-is.
print (Removing + activefile + from + objdir)
Instead of using + to concat strings, use the format() functionn:
removing {} from {}.format(activefile, objdir)
Also, if you are using Python 2, print is a statement, not a function,
so you could drop the parens here, too. I would not recommend that
though! Instead, from __future__ import print_function and keep using
print() as a function, just like in Python 3.
In general, I would not have stored the result of os.listdir() in a
separate variable but iterated over it directly. For large dirs, it
could also be better to use os.path.walk(), because that doesn't first
build a list and then iterate over the list but iterates over the single
elements directly. This avoids the memory allocation overhead, although
it is unlikely to make a difference in this case and a Premature
Optimization(tm).
Welcome to Python!
Uli
--
http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
- Original Message -
I need to pick up a language that would cover the Linux platform. I
use Powershell for a scripting language on the Windows side of
things. Very simple copy files script. Is this the best way to do
it?
import os
objdir = (C:\\temp2)
colDir = os.listdir(objdir)
for f in colDir:
activefile = os.path.join(objdir + \\ + f)
print (Removing + activefile + from + objdir)
os.remove(activefile)
In Powershell I would just do:
$colDir = gci -path c:\temp2
ForEach($file in $colDir)
--
http://mail.python.org/mailman/listinfo/python-list
Hi,
Is you powershell code printing the file being removed ? does it remove the
file as well ?
Because when you say I would *just* do you seem to imply that the same
actions can be performed with powershell in very few lines.
Anyway, your python code is correct but contain minor issues:
1/ listdir returns all elements in a directory, including subdirectories, you
should filter the list to get only files. os.remove will not remove directories.
2/ activefile = os.path.join(objdir, f) # would be the portable way of joining
path elements
objdir = os.path.join('C:', 'temp2')
for f in [f for _f in os.listdir(objdir) if os.path.isfile(_f)]:
os.remove(os.path.join(objdir, f))
Also note that 'shutil' is a module giving you access to a lot of tools for
copying, deleting creating files/dir.
JM
-- IMPORTANT NOTICE:
The contents of this email and any attachments are confidential and may also be
privileged. If you are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person, use it for
any purpose, or store or copy the information in any medium. Thank you.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
Ulrich Eckhardt wrote: separate variable but iterated over it directly. For large dirs, it could also be better to use os.path.walk(), because that doesn't first build a list and then iterate over the list but iterates over the single elements directly. This avoids the memory allocation overhead, although it is unlikely to make a difference in this case and a Premature Optimization(tm). Not true. os.walk() uses os.listdir() internally. -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
- Original Message - I need to pick up a language that would cover the Linux platform. I use Powershell for a scripting language on the Windows side of things. Very simple copy files script. Is this the best way to do it? Have you seen/checked http://pash.sourceforge.net/ ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
Am 05.02.2013 11:35, schrieb Peter Otten: Ulrich Eckhardt wrote: [...] use os.path.walk(), because that doesn't first build a list and then iterate over the list but iterates over the single elements directly. [...] Not true. os.walk() uses os.listdir() internally. Oh. 8| Thanks for proofreading what I wrote, I must have been confusing it with something else. Thankssorry! Uli -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 2013-02-05, Anthony Correia akcorr...@gmail.com wrote: I need to pick up a language that would cover the Linux platform. Well, you haven't really described what it is you're trying to do, but it looks to me like bash and the usual set of shell utilities (e.g. find) is what you need rather than Python. I use Powershell for a scripting language on the Windows side of things. Very simple copy files script. Is this the best way to do it? That depends. What is it? import os objdir = (C:\\temp2) colDir = os.listdir(objdir) for f in colDir: activefile = os.path.join(objdir + \\ + f) print (Removing + activefile + from + objdir) os.remove(activefile) In Powershell I would just do: $colDir = gci -path c:\temp2 ForEach($file in $colDir) Sorry, I'm a Linux guy. I have no clue what that means. -- Grant Edwards grant.b.edwardsYow! Well, I'm INVISIBLE at AGAIN ... I might as well gmail.compay a visit to the LADIES ROOM ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 2013-02-05, Terry Reedy tjre...@udel.edu wrote: On 2/4/2013 11:14 PM, Anthony Correia wrote: I need to pick up a language that would cover the Linux platform. I use Powershell for a scripting language on the Windows side of things. Very simple copy files script. Is this the best way to do it? import os objdir = (C:\\temp2) colDir = os.listdir(objdir) for f in colDir: activefile = os.path.join(objdir + \\ + f) print (Removing + activefile + from + objdir) os.remove(activefile) In Powershell I would just do: $colDir = gci -path c:\temp2 ForEach($file in $colDir) Python comes with a shutil module with multiple copy functions. Most of the time when I find myself using the shutil module, it means the program should have been written in bash. :) -- Grant Edwards grant.b.edwardsYow! A shapely CATHOLIC at SCHOOLGIRL is FIDGETING gmail.cominside my costume.. -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On Tue, 05 Feb 2013 13:22:02 +, Grant Edwards wrote: On 2013-02-05, Anthony Correia akcorr...@gmail.com wrote: I need to pick up a language that would cover the Linux platform. Well, you haven't really described what it is you're trying to do, but it looks to me like bash and the usual set of shell utilities (e.g. find) is what you need rather than Python. I use Powershell for a scripting language on the Windows side of things. Very simple copy files script. Is this the best way to do it? That depends. What is it? import os objdir = (C:\\temp2) colDir = os.listdir(objdir) for f in colDir: activefile = os.path.join(objdir + \\ + f) print (Removing + activefile + from + objdir) os.remove(activefile) In Powershell I would just do: $colDir = gci -path c:\temp2 ForEach($file in $colDir) Sorry, I'm a Linux guy. I have no clue what that means. Hooray for common sense! Python is great, but it's silly to use Python (unless there is good reason) when a simple shell script will do the job. I think he means (bash speak): for file in whateverdir -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 2013-02-05, Walter Hurry walterhu...@lavabit.com wrote: Sorry, I'm a Linux guy. I have no clue what that means. Hooray for common sense! Python is great, but it's silly to use Python (unless there is good reason) when a simple shell script will do the job. Python is an excellent option for writing shell scripts, particularly if your shell is cmd.exe. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 02/05/2013 01:39 PM, Neil Cerutti wrote: On 2013-02-05, Walter Hurry walterhu...@lavabit.com wrote: Sorry, I'm a Linux guy. I have no clue what that means. Hooray for common sense! Python is great, but it's silly to use Python (unless there is good reason) when a simple shell script will do the job. Python is an excellent option for writing shell scripts, particularly if your shell is cmd.exe. I believe having your shell be cmd.exe qualifies as a good reason! :) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 2013-02-05, Neil Cerutti ne...@norwich.edu wrote: On 2013-02-05, Walter Hurry walterhu...@lavabit.com wrote: Sorry, I'm a Linux guy. I have no clue what that means. Hooray for common sense! Python is great, but it's silly to use Python (unless there is good reason) when a simple shell script will do the job. Python is an excellent option for writing shell scripts, particularly if your shell is cmd.exe. The OP stated explicitly that the target OS was Linux: I need to pick up a language that would cover the Linux platform. I use Powershell for a scripting language on the Windows side of things. Don't get me wrong -- I think Python is great -- but when the target OS is Linux, and what you want to do are file find, move, copy, rename, delete operations, then I still say bash should be what you try first. -- Grant Edwards grant.b.edwardsYow! GOOD-NIGHT, everybody at ... Now I have to go gmail.comadminister FIRST-AID to my pet LEISURE SUIT!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 2013-02-05, Ethan Furman et...@stoneleaf.us wrote: On 02/05/2013 01:39 PM, Neil Cerutti wrote: On 2013-02-05, Walter Hurry walterhu...@lavabit.com wrote: Sorry, I'm a Linux guy. I have no clue what that means. Hooray for common sense! Python is great, but it's silly to use Python (unless there is good reason) when a simple shell script will do the job. Python is an excellent option for writing shell scripts, particularly if your shell is cmd.exe. I believe having your shell be cmd.exe qualifies as a good reason! Except the OP said he wanted to pick a language for Linux. If he has cmd.exe as his shell on Linux, then he's beyond help... -- Grant Edwards grant.b.edwardsYow! I'm a GENIUS! I want at to dispute sentence gmail.comstructure with SUSAN SONTAG!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On Wed, Feb 6, 2013 at 10:00 AM, Grant Edwards invalid@invalid.invalid wrote: On 2013-02-05, Ethan Furman et...@stoneleaf.us wrote: On 02/05/2013 01:39 PM, Neil Cerutti wrote: Python is an excellent option for writing shell scripts, particularly if your shell is cmd.exe. I believe having your shell be cmd.exe qualifies as a good reason! Except the OP said he wanted to pick a language for Linux. If he has cmd.exe as his shell on Linux, then he's beyond help... Python is not an excellent option. It's a bad fit for shell scripting, it just happens to be way better than a weak shell. Having grown up on command.com, I found OS/2's cmd.exe to be a massive improvement, and Windows's cmd.exe to be rather less impressive... but both of them pale into insignificance compared to bash. OS/2 has a better shell scripting language (REXX), but Windows doesn't, and Python ain't it. (Hmm. Google Chrome doesn't put its red squiggly lines under ain't, but it does complain about virtualization. Seems to me something, uhh, ain't right there.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On Tue, Feb 5, 2013 at 3:59 PM, Grant Edwards invalid@invalid.invalid wrote: On 2013-02-05, Neil Cerutti ne...@norwich.edu wrote: On 2013-02-05, Walter Hurry walterhu...@lavabit.com wrote: Sorry, I'm a Linux guy. I have no clue what that means. Hooray for common sense! Python is great, but it's silly to use Python (unless there is good reason) when a simple shell script will do the job. Python is an excellent option for writing shell scripts, particularly if your shell is cmd.exe. The OP stated explicitly that the target OS was Linux: The impression I got was that he was looking for something that would be cross-platform and work in both Windows and Linux. Python is a reasonable choice for that if you're not willing to deal with Cygwin. -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
Chris Angelico wrote:
Python is not an excellent option. It's a bad fit for shell
scripting, it just happens to be way better than a weak shell. Having
grown up on command.com, I found OS/2's cmd.exe to be a massive
improvement, and Windows's cmd.exe to be rather less impressive... but
both of them pale into insignificance compared to bash.
I have to disagree with much of this. bash is a poorly designed language
which, in my opinion, is only good enough for short (under 20 lines)
throw-away scripts.
[begin rant]
bash has terse *and* cryptic syntax even less maintainable than Perl. E.g.
this is, apparently, the right way to get the length of an array called R:
rlen=${#R[@]}
(taken from here:
http://www.bashcookbook.com/bashinfo/source/bash-4.2/examples/functions/array-stuff
so I hope that they know what they're talking about.)
Note that sometimes # begins a comment, and sometimes it doesn't.
This is how you test whether something is not the name of a directory:
[[ -d $dir ]] || {
echo $FUNCNAME: $dir is not a directory 2
return 2
}
http://www.bashcookbook.com/bashinfo/source/bash-4.2/examples/functions/emptydir
Arithmetic requires either calling an external program, or special magic
syntax:
z=`expr $z + 3`
i=$(( i + 1 ))
Spaces are magic -- these two lines do radically different things:
i = j
i=j
There's also a let command, but it's a kludge:
k=$(( i+2 ))
let k=i+2
are equivalent, but
k=$(( i*2 ))
let k=i*2
are not!
bash is even more weakly typed than Perl. As far as I can tell, bash is
completely untyped -- everything is text, all the time, even arrays.
[steve@ando ~]$ cat testarray.sh
colors=('Blue' 'Red')
echo $((colors + 2))
[steve@ando ~]$ sh testarray.sh
2
Quotation marks have magic powers, and the rules for them are so complicated
that working out how to correctly quote expressions is probably the single
most difficult part of bash scripting.
bash teaches bad programming habits, such as reliance on global and
environment variables, and lacks modern (30+ years old) features such as
exception handling, objects, and even proper functions that return a
result. Yes, that's right, bash functions communicate their result by
side-effect.
http://www.linuxjournal.com/content/return-values-bash-functions
Because bash scripts are mostly written by non-programmers, the culture as a
whole has a cargo-cult mentality about it. I'm sure that there are some
people who actually do know bash, it's strengths and weaknesses, well, but
in my experience most people just blindly copy code snippets and recipes
around without really understanding them. As a consequence, we have this:
http://partmaps.org/era/unix/award.html
Almost nothing in bash is portable. Because bash does so little, and relies
on external programs for so much, even if you write the bash parts portably
(which basically means writing for the Bourne shell, which is even more
lacking than bash), you *still* aren't portable because there's no
guarantee that the external programs exist or do what you expect on some
other system.
To do anything meaningful in bash, you need to be an expert on passing work
off to other programs, e.g. sed, awk, grep, tr, cut, ed, ps, dc, wc, ...
any of which may be missing, or have different semantics from what you
expect (ps in particular is notorious for the widely variable command
switches it takes), or output their results in unexpected ways.
Pretty much of all bash scripting is kludge on top of kludge, special
behaviour, small syntax differences making large differences in behaviour,
surprising gotchas, side-effects and magic. If you took the Zen of Python,
and pretty much reversed everything, you might have the Zen of Bash:
Implicit is better than explicit.
Complex is better than simple.
Complicated is better than complex.
Dense is better than sparse.
Readability doesn't count.
Special cases break the rules.
Errors should pass silently.
In the face of ambiguity, guess.
There should be many obscure ways to do it.
Namespaces are terrible, let's make everything global!
I would not hesitate to use Python, or some other high-level language like
Ruby, over bash for anything non-trivial that I cared about. It might not
be as terse and compact as a well-written bash script, but that's a *good*
thing, and a poorly-written bash script is likely to be even more verbose
and difficult to write than a poorly-written Python script.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On Feb 5, 2013 6:00 PM, Steven Dapos;Aprano steve+comp.lang.pyt...@pearwood.info wrote: Chris Angelico wrote: Python is not an excellent option. It's a bad fit for shell scripting, it just happens to be way better than a weak shell. Having grown up on command.com, I found OS/2's cmd.exe to be a massive improvement, and Windows's cmd.exe to be rather less impressive... but both of them pale into insignificance compared to bash. I have to disagree with much of this. bash is a poorly designed language which, in my opinion, is only good enough for short (under 20 lines) throw-away scripts. I agree that Python is usually a great option, but sadly I also have to agree that bash has moved too far in the direction of Perl. However, if you can stick to a Bournish subset of bash, it's really good for some problems, being almost lispish and being very parallel. Error checking in shell needn't be haphazard, even though that's how it's usually done. -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On Tue, 05 Feb 2013 21:01:56 +, Walter Hurry wrote: Hooray for common sense! Python is great, but it's silly to use Python (unless there is good reason) when a simple shell script will do the job. A shell script is only the better option if (almost) the *only* thing the script needs to do is to execute commands. The moment you start trying to process data, it's time to put up with the verbosity of subprocess.Popen() so that you can use a well-designed language for the rest of it. Shells are designed first and foremost for interactive use, and everything else is compromised by that fact. Minimising the number of keystrokes is a great idea for something which will be typed, executed and forgotten. It's an awful idea if you're going to modify the script in six months' time. Making the execution of commands a fundamental language feature is a great idea if that's most of what you do, but not such a great idea if you'll be doing a lot else besides (because most of the available syntax has been consumed by command execution). -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 02/05/2013 08:32 PM, Nobody wrote: A shell script is only the better option if (almost) the *only* thing the script needs to do is to execute commands. The moment you start trying to process data, it's time to put up with the verbosity of subprocess.Popen() so that you can use a well-designed language for the rest of it. Agreed. And most of the time a script in bash is going to do something like: grep blah /from/file | cut -f 1 -d ' ' | uniq | sort Python generators happen to be very efficient at recreating this sort of thing entirely in python. A great presentation that all system programmers should read is found here: http://www.dabeaz.com/generators/ Very cool stuff. Grep is just a generator function. cut is just a generator function, and so on. And it can be pretty darn fast too. -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On Wed, Feb 6, 2013 at 12:55 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Chris Angelico wrote: Python is not an excellent option. It's a bad fit for shell scripting, it just happens to be way better than a weak shell. Having grown up on command.com, I found OS/2's cmd.exe to be a massive improvement, and Windows's cmd.exe to be rather less impressive... but both of them pale into insignificance compared to bash. I have to disagree with much of this. bash is a poorly designed language which, in my opinion, is only good enough for short (under 20 lines) throw-away scripts. [snip rant] Your points are valid, and yet I still can't push Python as a command execution language better than bash scripting. Nobody was right: as soon as you are actually *processing* data, you want something better than bash. If I want to make a simple command that pulls the latest project changes and then shows me those changes, I'm going to write a bash script that does this: git pull --rebase git log --oneline origin/master..master gitk Actually the script's a bit more detailed than that (variable branch, makes a tag 'lastsync' so that I can go back to it later, passes gitk some args so it shows me the commit most likely to be of first interest, etc), but it's still pretty much all command execution. Now maybe if I were using Mercurial, I could script some of that using Python; but that would be a special-case that stems from Mercurial actually having been written in Python, and it doesn't help if you're working with some other set of commands that don't happen to be importable. But what tends to happen at work is that a script like that grows until it hits a couple dozen lines of code, and then it gets transparently rewritten into some other language (change the shebang at the top, nobody needs to know/care that it got a complete rewrite). My weapon of choice for these rewrites is usually Pike, not Python, mainly because we don't currently have any significant amount of Python in our codebase, but either would most likely do. (I haven't looked into subprocess and how portable my code would be across 2.6/2.7/3.3, though.) The fact remains, though, that an applications language is definitely *second choice* to bash scripting when it comes to tasks that involve lots of command execution. It feels silly enough translating this OS/2 batch script: @logon SOME_USER /pSOME_PASS /vl @e:\rexx\load @db2 start database manager @exit into this REXX script: /* */ @logon SOME_USER /pSOME_PASS /vl @e:\rexx\load @db2 start database manager @exit And that's a change I've made myriad times (to \startup.cmd on many an OS/2 boot drive) It's far far worse translating it into Python, Pike, or any other good language. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On Feb 6, 6:55 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: I would not hesitate to use Python, or some other high-level language like Ruby, over bash for anything non-trivial that I cared about. It might not be as terse and compact as a well-written bash script, but that's a *good* thing, and a poorly-written bash script is likely to be even more verbose and difficult to write than a poorly-written Python script. Maybe you should look at scsh or rc http://paganbooks.eu/software/article/rc-duff Heres the author of scsh (which would not be saying much were it not for his uber-geek status) (from http://www.scsh.net/docu/scsh-paper/scsh-paper-Z-H-1.html ) Shell programming terrifies me. There is something about writing a simple shell script that is just much, much more unpleasant than writing a simple C program, or a simple COMMON LISP program, or a simple Mips assembler program. Is it trying to remember what the rules are for all the different quotes? Is it having to look up the multi- phased interaction between filename expansion, shell variables, quotation, backslashes and alias expansion? Maybe it's having to subsequently look up which of the twenty or thirty flags I need for my grep, sed, and awk invocations. Maybe it just gets on my nerves that I have to run two complete programs simply to count the number of files in a directory (ls | wc -l), which seems like several orders of magnitude more cycles than was really needed. -- http://mail.python.org/mailman/listinfo/python-list
Opinion on best practice...
I need to pick up a language that would cover the Linux platform. I use Powershell for a scripting language on the Windows side of things. Very simple copy files script. Is this the best way to do it? import os objdir = (C:\\temp2) colDir = os.listdir(objdir) for f in colDir: activefile = os.path.join(objdir + \\ + f) print (Removing + activefile + from + objdir) os.remove(activefile) In Powershell I would just do: $colDir = gci -path c:\temp2 ForEach($file in $colDir) -- http://mail.python.org/mailman/listinfo/python-list
Re: Opinion on best practice...
On 02/04/2013 09:14 PM, Anthony Correia wrote: I need to pick up a language that would cover the Linux platform. I use Powershell for a scripting language on the Windows side of things. Very simple copy files script. Is this the best way to do it? import os objdir = (C:\\temp2) colDir = os.listdir(objdir) for f in colDir: activefile = os.path.join(objdir + \\ + f) print (Removing + activefile + from + objdir) os.remove(activefile) In Powershell I would just do: $colDir = gci -path c:\temp2 ForEach($file in $colDir) Yes you could do something like that in Python. I know on linux there is a module called shutils that provides more shell file handling abilities to python. Your script as it is listed has a few bugs, though: - os.listdir() walks the current working directory, not necessarily c:\temp2 - instead of using \\ in the os.path.join, you can use os.path.sep to get the current platform's separator character While I do use python for shell scripting, by itself, it's not very good at it. I ended up writing my own wrapper function to run external commands, feed them std-in, and capture standard out and standard error. I wrapped one of the subprocess module functions. Not sure which. I can post the file to the list if anyone wants to see it. Also as I mentioned, on unix machines there is the shutils module. Still, though, sometimes a proper shell like bash or zsh is going to work out better for shell scripting than python. Plus if you're going to be proficient on the Linux command line you need to know their basics anyway. -- http://mail.python.org/mailman/listinfo/python-list
