Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #38159 > unrolled thread

Opinion on best practice...

Back to article view | Back to comp.lang.python

Contents

  Opinion on best practice... Anthony Correia <akcorreia@gmail.com> - 2013-02-04 20:14 -0800
    Re: Opinion on best practice... Michael Torrie <torriem@gmail.com> - 2013-02-04 23:04 -0700
    Re: Opinion on best practice... Terry Reedy <tjreedy@udel.edu> - 2013-02-05 02:56 -0500
      Re: Opinion on best practice... Grant Edwards <invalid@invalid.invalid> - 2013-02-05 13:23 +0000
    Re: Opinion on best practice... Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2013-02-05 08:56 +0100
      Re: Opinion on best practice... Peter Otten <__peter__@web.de> - 2013-02-05 11:35 +0100
        Re: Opinion on best practice... Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2013-02-05 14:05 +0100
    Re: Opinion on best practice... Grant Edwards <invalid@invalid.invalid> - 2013-02-05 13:22 +0000
      Re: Opinion on best practice... Walter Hurry <walterhurry@lavabit.com> - 2013-02-05 21:01 +0000
        Re: Opinion on best practice... Neil Cerutti <neilc@norwich.edu> - 2013-02-05 21:39 +0000
          Re: Opinion on best practice... Ethan Furman <ethan@stoneleaf.us> - 2013-02-05 14:07 -0800
            Re: Opinion on best practice... Grant Edwards <invalid@invalid.invalid> - 2013-02-05 23:00 +0000
              Re: Opinion on best practice... Chris Angelico <rosuav@gmail.com> - 2013-02-06 10:35 +1100
                Re: Opinion on best practice... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-06 12:55 +1100
                  Re: Opinion on best practice... Dan Stromberg <drsalists@gmail.com> - 2013-02-05 18:14 -0800
                  Re: Opinion on best practice... Chris Angelico <rosuav@gmail.com> - 2013-02-06 17:16 +1100
                  Re: Opinion on best practice... rusi <rustompmody@gmail.com> - 2013-02-05 23:32 -0800
                  Re: Opinion on best practice... Grant Edwards <invalid@invalid.invalid> - 2013-02-06 15:18 +0000
                  Re: Opinion on best practice... Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-06 12:37 -0500
                    Re: Opinion on best practice... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-07 10:46 +1100
                      Re: Opinion on best practice... Chris Angelico <rosuav@gmail.com> - 2013-02-07 16:28 +1100
                        Re: Opinion on best practice... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-07 06:50 +0000
                          Re: Opinion on best practice... Chris Angelico <rosuav@gmail.com> - 2013-02-07 18:49 +1100
                            Re: Opinion on best practice... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-08 09:49 +1100
                              Re: Opinion on best practice... Chris Angelico <rosuav@gmail.com> - 2013-02-08 17:54 +1100
                              Re: Opinion on best practice... Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-08 12:41 -0500
                          Re: Opinion on best practice... Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-07 13:54 -0500
                            Re: Opinion on best practice... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-08 09:58 +1100
                              Re: Opinion on best practice... Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-08 13:29 -0500
                              Re: Opinion on best practice... Chris Angelico <rosuav@gmail.com> - 2013-02-09 11:28 +1100
                  Re: Opinion on best practice... John Ladasky <john_ladasky@sbcglobal.net> - 2013-02-08 19:10 -0800
              Re: Opinion on best practice... Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-06 00:33 -0500
                Re: Opinion on best practice... Anssi Saari <as@sci.fi> - 2013-02-06 15:30 +0200
          Re: Opinion on best practice... Grant Edwards <invalid@invalid.invalid> - 2013-02-05 22:59 +0000
            Re: Opinion on best practice... Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-05 17:05 -0700
              Re: Opinion on best practice... Grant Edwards <invalid@invalid.invalid> - 2013-02-06 15:04 +0000
            Re: Opinion on best practice... Neil Cerutti <neilc@norwich.edu> - 2013-02-06 14:20 +0000
              Re: Opinion on best practice... Grant Edwards <invalid@invalid.invalid> - 2013-02-06 15:11 +0000
        Re: Opinion on best practice... Nobody <nobody@nowhere.com> - 2013-02-06 03:32 +0000
          Re: Opinion on best practice... Michael Torrie <torriem@gmail.com> - 2013-02-05 22:07 -0700

Page 2 of 2 — ← Prev page 1 [2]

#38330

On Thu, Feb 7, 2013 at 10:46 AM, Steven D'Aprano
<steve+comp.lang.python@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 "Noooo, 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

[toc] | [prev] | [next] | [standalone]

#38334

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.python@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 "Noooo, 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

[toc] | [prev] | [next] | [standalone]

#38336

On Thu, Feb 7, 2013 at 5:50 PM, Steven D'Aprano
<steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#38379

Chris Angelico wrote:

> On Thu, Feb 7, 2013 at 5:50 PM, Steven D'Aprano
> <steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#38425

On Fri, Feb 8, 2013 at 9:49 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Chris Angelico wrote:
> 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.

A bare expression IS explicitly calling for code execution. That's
simply the way the language is. If you don't want the return value to
be sent to the host, you either assign it to a variable, or use CALL
(if it's a function call).

> 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.

Anything that doesn't parse is a syntax error. It's only expression
results that go to the host (shell).

> 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.

If it was meant to be a name, then it'll be in an expression, which -
see above - is an explicit request for it to be handled by the host.
The only thing that'll trip you up there is misspelling a language
keyword:

iff blah blah blah blah

which will be sent to the host instead of being an 'IF' statement.

ChrisA

[toc] | [prev] | [next] | [standalone]

#38468

On Fri, 08 Feb 2013 09:49:02 +1100, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:

> 
> 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've not used it in years, but yes... Since on the Amiga many
applications opened a "rexxport" they were candidates for "current
command processor". REXX implementations on Windows and Linux aren't as
flexible -- for the most part the only viable command processor is
spawning a shell to handle one statement (a la Python's os.system() ).

	On the Amiga, one could script the systems text editor by using
something similar to (my manuals are in storage):

/* */
address EDITOR
open "somefile.txt"
3d
i
date('n')
<esc>
save
address COMMAND
copy somefile.txt df0:

(I don't recall the notation used to actually escape out of insert mode.

Translated:

	Define the editor as the command processor
	Editor open file command
	Move down three lines
	Enter insert mode
	Insert current date (date is the REXX data function, what is
inserted is the return value from calling date()
	Exit insert mode
	Save the file
	Revert to the normal command shell
	Use normal shell command to copy the file to the first floppy drive.

	It's the interactive nature seen in the editor portion that is not
easy to perform using Python -- even with subprocess.Popen() and the
various read/write operations.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#38359

On 07 Feb 2013 06:50:07 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:

> 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()
>

	Return values wouldn't be sent to the shell... The function call was
parseable as language syntax.
 
> 
> Are you saying that Dennis' description of REXX sending unparsable text 
> to the shell for execution is incorrect?

E:\UserData\Wulfraed\My Documents>type test.rx
/* */
say time('n')
'say' time('n')
echo time('n')
'echo' time('n')
'echo' "time('n')"
echo "time('n')"
what = 'ho'
'ec' || what time('n')
ec || what time('n')
time('n')
say Now Calling "time()"
call time 'n'
say "time() was called"


E:\UserData\Wulfraed\My Documents>regina test.rx
13:50:06
'say' is not recognized as an internal or external command,
operable program or batch file.
     3 *-* 'say' time('n')
       +++ RC=1 +++
13:50:06
13:50:06
time('n')
time('n')
13:50:06
13:50:06
The filename, directory name, or volume label syntax is incorrect.
    11 *-* time('n')
       +++ RC=1 +++
NOW CALLING time()
time() was called

E:\UserData\Wulfraed\My Documents>

	Line 1 (treating the /**/ as line 0) is the REXX "say" command,
outputting the result of calling the REXX time() function.

	Line 2 quotes the "say", making it a string, and not a parseable
REXX statement; Windows command shell produces an error.

	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

	Line 4 quotes "echo" but is otherwise the same

	Lines 5 and 6 quote the "time()" call -- making that a string.

	Lines 7-9 illustrate creating lines from string expressions.

	Line 10 is treating the result of an internal function as the
command to be executed. So yes, REXX does not throw away function return
values -- you must catch them; if you don't want the return value, then
you need to "call" the function explicitly, shown in lines 11-13.

	Plain REXX didn't have equivalents to "import", but could call
"subprograms" by just naming them on a statement... Making REXX closer
to BASH, cmd.exe, PowerShell, VMS DCL... Whereas Python is closer to
BASIC -- a byte-code compiled/interpreted language.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#38381

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

[toc] | [prev] | [next] | [standalone]

#38473

On Fri, 08 Feb 2013 09:58:42 +1100, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:

> 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.
>
	You have to remember -- REXX was not created to be a stand-alone
programming language, as Python. It was created (in the late 70s early
80s) to be a "better" "shell" scripting language on IBM mainframes in
place of JCL and similar ("shell" in quotes as neither the interactive
command line nor submitted batch files were considered to run in
"shells"). Being able to transparently make use of the parent command
processor (or switching to a different command processor -- have the
script preprocess some data files, for example, then invoke the system
editor, switch to the editor as command processor, and edit a file based
upon what contents are in the preprocessed data).

	Common practice is to quote the first word of any thing being sent
to the command processor -- to make it more explicit and to avoid
conflicts with REXX keywords. Hypothetically, if "DO" were the command
to invoke some system command (dump object file?):

	DO sourcefile

would generate a syntax error as it doesn't match the REXX "DO" loop
syntax (as I recall, I originally indicated that stuff that doesn't
parse as a REXX /statement/ was sent to the command -- this parses as a
REXX loop with a syntax error); whereas

	'DO' sourcefile

is a string, and will be sent to the command processor. The emphasis is
on "statement". Statements basically fall into

	keyword blah blah blah
or
	variable = blah  blah blah

E:\UserData\Wulfraed\My Documents>type test.rx
/* */
operation.1 = 'date'
operation.3 = 'time'
do i = 1 to 4
        say operation.i
        operation.i '/t'
end
call operation
E:\UserData\Wulfraed\My Documents>type operation.4
/* */
say inside "operation.4"

E:\UserData\Wulfraed\My Documents>type operation.rx
/* */
say inside "operation.rx"

E:\UserData\Wulfraed\My Documents>regina test.rx
date
Fri 02/08/2013
OPERATION.2
'OPERATION.2' is not recognized as an internal or external command,
operable program or batch file.
     6 *-*  operation.i '/t'
       +++ RC=1 +++
time
01:28 PM
OPERATION.4
INSIDE operation.rx

E:\UserData\Wulfraed\My Documents>

(Note: OPERATION.4 brings up a Windows requester that it doesn't know
how to execute that file type -- but the file was found, so no REXX
error; the CALL operation finds operation.rx, and executes it as a
subprogram)


	If the line doesn't begin with a keyword or of the form "variable
=", then first translations are done for any word in the line that
matches a variable or function name (variables are replaced by their
value, functions are called and replaced by their return value), and
whatever is left of the line is passed to the command processor.

	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.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#38482

On Sat, Feb 9, 2013 at 5:29 AM, Dennis Lee Bieber <wlfraed@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

[toc] | [prev] | [next] | [standalone]

#38492

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.

[toc] | [prev] | [next] | [standalone]

#38256

On Wed, 6 Feb 2013 10:35:40 +1100, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:


> better shell scripting language (REXX), but Windows doesn't, and
> Python ain't it.
>
	Win7 includes PowerShell, and it can be downloaded for WinXP.

	Granted, PowerShell also incorporates a security system that might
make running scripts a bit of a pain <G> (I think the default is that it
will only run scripts with known "signatures"; but can be set to allow
local machine sourced scripts to run without checking).

	PowerShell is meant to be used for administrative level scripting,
replacing such things as WSH.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#38275

Dennis Lee Bieber <wlfraed@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.

[toc] | [prev] | [next] | [standalone]

#38240

On 2013-02-05, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2013-02-05, Walter Hurry <walterhurry@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.edwards        Yow! GOOD-NIGHT, everybody
                                  at               ... Now I have to go
                              gmail.com            administer FIRST-AID to my
                                                   pet LEISURE SUIT!!

[toc] | [prev] | [next] | [standalone]

#38247

On Tue, Feb 5, 2013 at 3:59 PM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-02-05, Neil Cerutti <neilc@norwich.edu> wrote:
>> On 2013-02-05, Walter Hurry <walterhurry@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.

[toc] | [prev] | [next] | [standalone]

#38282

On 2013-02-06, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Tue, Feb 5, 2013 at 3:59 PM, Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2013-02-05, Neil Cerutti <neilc@norwich.edu> wrote:
>>> On 2013-02-05, Walter Hurry <walterhurry@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.edwards        Yow! I feel like I'm
                                  at               in a Toilet Bowl with a
                              gmail.com            thumbtack in my forehead!!

[toc] | [prev] | [next] | [standalone]

#38276

On 2013-02-05, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-02-05, Neil Cerutti <neilc@norwich.edu> wrote:
>> On 2013-02-05, Walter Hurry <walterhurry@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

[toc] | [prev] | [next] | [standalone]

#38283

On 2013-02-06, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2013-02-05, Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2013-02-05, Neil Cerutti <neilc@norwich.edu> wrote:
>>> On 2013-02-05, Walter Hurry <walterhurry@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.edwards        Yow! If Robert Di Niro
                                  at               assassinates Walter Slezak,
                              gmail.com            will Jodie Foster marry
                                                   Bonzo??

[toc] | [prev] | [next] | [standalone]

#38252

On Tue, 05 Feb 2013 21:01:56 +0000, 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).

[toc] | [prev] | [next] | [standalone]

#38255

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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web