I've to call to many functions with the format:

>>> run("cmd")

were "cmd" is a command with its arguments to pass them to the shell
and run it, i.e.

>>>  run("pwd")
or
>>> run("ls /home")

Does anybody knows any library to help me to avoid the use of the main
quotes, and brackets?

I would to use anything as:

$ ls /home => run("ls /home")

or, at least

run pwd => run("pwd")

On 2010-01-28, Joan Miller <peloko45@gmail.com> wrote:
> I've to call to many functions with the format:
>
>>>> run("cmd")

Check the docs on os.system().


-- 
Josh "dutchie" Holland <jrh@joshh.co.uk>
http://www.joshh.co.uk/
http://twitter.com/jshholland
http://identi.ca/jshholland

On 28 ene, 19:16, Josh Holland <j...@joshh.co.uk> wrote:
> On 2010-01-28, Joan Miller <pelok...@gmail.com> wrote:
>
> > I've to call to many functions with the format:
>
> >>>> run("cmd")
>
> Check the docs on os.system().
No. I've a function that uses subprocess to run commands on the same
shell and so substitute to bash scrips. But a script full of run
("shell_command --with --arguments") is too verbose.

Joan Miller wrote:
> On 28 ene, 19:16, Josh Holland <j...@joshh.co.uk> wrote:
>> On 2010-01-28, Joan Miller <pelok...@gmail.com> wrote:
>>
>>> I've to call to many functions with the format:
>>>>>> run("cmd")
>> Check the docs on os.system().
> No. I've a function that uses subprocess to run commands on the same
> shell and so substitute to bash scrips. But a script full of run
> ("shell_command --with --arguments") is too verbose.

So rewrite the script to read the commands from a file and execute them
one by one?

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC                 http://www.holdenweb.com/
UPCOMING EVENTS:        http://holdenweb.eventbrite.com/

On 1/28/2010 2:24 PM, Joan Miller wrote:
> On 28 ene, 19:16, Josh Holland<j...@joshh.co.uk>  wrote:
>> On 2010-01-28, Joan Miller<pelok...@gmail.com>  wrote:
>>
>>> I've to call to many functions with the format:
>>
>>>>>> run("cmd")
>>
>> Check the docs on os.system().
> No. I've a function that uses subprocess to run commands on the same
> shell and so substitute to bash scrips. But a script full of run
> ("shell_command --with --arguments") is too verbose.

I'm suspicious of your original intent. Essentially, you want to write 
code in which a literal string, such as ...

   ls -l

.... is *not* enclosed in quotes. Why run the risk of creating confusion 
(in other people who look at your code, in syntax-checking tools, etc.) 
between variables and literals?

But I'm in sympathy with your desire to make the code as clean as 
possible and to minimize the number of times you have to type a quote 
character. My suggestions:

1. Create a function (say, "Run") that encapsulates as much of the 
syntax as possible: os.system(), subprocess.call(), string-splitting, 
whatever. So an invocation would look like this:

   Run("ls -l *.txt")

(I think you've already done this step.)

2. Find a text editor that supports keyboard macros, so that a single 
keystroke turns this text line:

   ls -l *.txt

.... into this one:

   Run("ls -l *.txt")

HTH,
John

On 28 ene, 19:54, Steve Holden <st...@holdenweb.com> wrote:
> Joan Miller wrote:
> > On 28 ene, 19:16, Josh Holland <j...@joshh.co.uk> wrote:
> >> On 2010-01-28, Joan Miller <pelok...@gmail.com> wrote:
>
> >>> I've to call to many functions with the format:
> >>>>>> run("cmd")
> >> Check the docs on os.system().
> > No. I've a function that uses subprocess to run commands on the same
> > shell and so substitute to bash scrips. But a script full of run
> > ("shell_command --with --arguments") is too verbose.
>
> So rewrite the script to read the commands from a file and execute them
> one by one?
>
I had thinked about that but the problem is that I would that were
mixed with python code, so can be get the output from a system command
and manipulate it from python

On 28 ene, 19:58, John Posner <jjpos...@optimum.net> wrote:
> On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> > On 28 ene, 19:16, Josh Holland<j...@joshh.co.uk> =A0wrote:
> >> On 2010-01-28, Joan Miller<pelok...@gmail.com> =A0wrote:
>
> >>> I've to call to many functions with the format:
>
> >>>>>> run("cmd")
>
> >> Check the docs on os.system().
> > No. I've a function that uses subprocess to run commands on the same
> > shell and so substitute to bash scrips. But a script full of run
> > ("shell_command --with --arguments") is too verbose.
>
> I'm suspicious of your original intent. Essentially, you want to write
> code in which a literal string, such as ...
>
> =A0 =A0ls -l
>
> ... is *not* enclosed in quotes. Why run the risk of creating confusion
> (in other people who look at your code, in syntax-checking tools, etc.)
> between variables and literals?
Yes but to that code could be prepend a sign as '$' to be identified
and so be parsed.

>
> But I'm in sympathy with your desire to make the code as clean as
> possible and to minimize the number of times you have to type a quote
> character. My suggestions:
>
> 1. Create a function (say, "Run") that encapsulates as much of the
> syntax as possible: os.system(), subprocess.call(), string-splitting,
> whatever. So an invocation would look like this:
>
> =A0 =A0Run("ls -l *.txt")
>
> (I think you've already done this step.)
Yes, I made a funtion very cool to call to system commands, that works
well with pipes and passes the variables (i.e. "LANG=3DC grep -e 'foo' /
home")

> 2. Find a text editor that supports keyboard macros, so that a single
> keystroke turns this text line:
>
> =A0 =A0ls -l *.txt
>
> ... into this one:
>
> =A0 =A0Run("ls -l *.txt")
This is not what I'm looking for. I'm supposing that could be solved
with a DSL or a macro library, any?

On Jan 28, 12:13=A0pm, Joan Miller <pelok...@gmail.com> wrote:
> On 28 ene, 19:58, John Posner <jjpos...@optimum.net> wrote:
>
>
>
> > On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> > > On 28 ene, 19:16, Josh Holland<j...@joshh.co.uk> =A0wrote:
> > >> On 2010-01-28, Joan Miller<pelok...@gmail.com> =A0wrote:
>
> > >>> I've to call to many functions with the format:
>
> > >>>>>> run("cmd")
>
> > >> Check the docs on os.system().
> > > No. I've a function that uses subprocess to run commands on the same
> > > shell and so substitute to bash scrips. But a script full of run
> > > ("shell_command --with --arguments") is too verbose.
>
> > I'm suspicious of your original intent. Essentially, you want to write
> > code in which a literal string, such as ...
>
> > =A0 =A0ls -l
>
> > ... is *not* enclosed in quotes. Why run the risk of creating confusion
> > (in other people who look at your code, in syntax-checking tools, etc.)
> > between variables and literals?
>
> Yes but to that code could be prepend a sign as '$' to be identified
> and so be parsed.
>
>
>
> > But I'm in sympathy with your desire to make the code as clean as
> > possible and to minimize the number of times you have to type a quote
> > character. My suggestions:
>
> > 1. Create a function (say, "Run") that encapsulates as much of the
> > syntax as possible: os.system(), subprocess.call(), string-splitting,
> > whatever. So an invocation would look like this:
>
> > =A0 =A0Run("ls -l *.txt")
>
> > (I think you've already done this step.)
>
> Yes, I made a funtion very cool to call to system commands, that works
> well with pipes and passes the variables (i.e. "LANG=3DC grep -e 'foo' /
> home")
>
> > 2. Find a text editor that supports keyboard macros, so that a single
> > keystroke turns this text line:
>
> > =A0 =A0ls -l *.txt
>
> > ... into this one:
>
> > =A0 =A0Run("ls -l *.txt")
>
> This is not what I'm looking for. I'm supposing that could be solved
> with a DSL or a macro library, any?

Python is not perl.

Thank God/Guido.

On Jan 29, 6:58=A0am, John Posner <jjpos...@optimum.net> wrote:
> On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> > On 28 ene, 19:16, Josh Holland<j...@joshh.co.uk> =A0wrote:
> >> On 2010-01-28, Joan Miller<pelok...@gmail.com> =A0wrote:
>
> >>> I've to call to many functions with the format:
>
> >>>>>> run("cmd")
>
> >> Check the docs on os.system().
> > No. I've a function that uses subprocess to run commands on the same
> > shell and so substitute to bash scrips. But a script full of run
> > ("shell_command --with --arguments") is too verbose.
>
> I'm suspicious of your original intent. Essentially, you want to write
> code in which a literal string, such as ...
>
> =A0 =A0ls -l
>
> ... is *not* enclosed in quotes. Why run the risk of creating confusion
> (in other people who look at your code, in syntax-checking tools, etc.)
> between variables and literals?
>
> But I'm in sympathy with your desire to make the code as clean as
> possible and to minimize the number of times you have to type a quote
> character. My suggestions:
>
> 1. Create a function (say, "Run") that encapsulates as much of the
> syntax as possible: os.system(), subprocess.call(), string-splitting,
> whatever. So an invocation would look like this:
>
> =A0 =A0Run("ls -l *.txt")
>
> (I think you've already done this step.)
>
> 2. Find a text editor that supports keyboard macros, so that a single
> keystroke turns this text line:
>
> =A0 =A0ls -l *.txt
>
> ... into this one:
>
> =A0 =A0Run("ls -l *.txt")
>
> HTH,
> John

I can't see you avoiding quotes etc, but extending on John's comment,
the obvious next step would be to run everything in a loop i.e. place
all the commands into a list and create a loop that ran each command
in the list.

Almost all editors support macros - most editors support some form of
language sensitive editing (NOT the prompt call parameters style but
rather help with the syntax via a 'form' style of fill-in) that will
allow you to reduce typing effort. But macros would be the first and
easiest choice for this activity.

Peter

On 28 ene, 20:20, Peter <peter.milli...@gmail.com> wrote:
> On Jan 29, 6:58=A0am, John Posner <jjpos...@optimum.net> wrote:
>
>
>
> > On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> > > On 28 ene, 19:16, Josh Holland<j...@joshh.co.uk> =A0wrote:
> > >> On 2010-01-28, Joan Miller<pelok...@gmail.com> =A0wrote:
>
> > >>> I've to call to many functions with the format:
>
> > >>>>>> run("cmd")
>
> > >> Check the docs on os.system().
> > > No. I've a function that uses subprocess to run commands on the same
> > > shell and so substitute to bash scrips. But a script full of run
> > > ("shell_command --with --arguments") is too verbose.
>
> > I'm suspicious of your original intent. Essentially, you want to write
> > code in which a literal string, such as ...
>
> > =A0 =A0ls -l
>
> > ... is *not* enclosed in quotes. Why run the risk of creating confusion
> > (in other people who look at your code, in syntax-checking tools, etc.)
> > between variables and literals?
>
> > But I'm in sympathy with your desire to make the code as clean as
> > possible and to minimize the number of times you have to type a quote
> > character. My suggestions:
>
> > 1. Create a function (say, "Run") that encapsulates as much of the
> > syntax as possible: os.system(), subprocess.call(), string-splitting,
> > whatever. So an invocation would look like this:
>
> > =A0 =A0Run("ls -l *.txt")
>
> > (I think you've already done this step.)
>
> > 2. Find a text editor that supports keyboard macros, so that a single
> > keystroke turns this text line:
>
> > =A0 =A0ls -l *.txt
>
> > ... into this one:
>
> > =A0 =A0Run("ls -l *.txt")
>
> > HTH,
> > John
>
> I can't see you avoiding quotes etc, but extending on John's comment,
> the obvious next step would be to run everything in a loop i.e. place
> all the commands into a list and create a loop that ran each command
> in the list.
Yes, but could be necessary that were mixed with python code.

> Almost all editors support macros - most editors support some form of
> language sensitive editing (NOT the prompt call parameters style but
> rather help with the syntax via a 'form' style of fill-in) that will
> allow you to reduce typing effort. But macros would be the first and
> easiest choice for this activity.
The goal of my program is substitute to bash scripts, so the macros in
editors are irrelevant fo this one.

On 28 ene, 20:34, Joan Miller <pelok...@gmail.com> wrote:
> On 28 ene, 20:20, Peter <peter.milli...@gmail.com> wrote:
>
> > On Jan 29, 6:58=A0am, John Posner <jjpos...@optimum.net> wrote:
>
> > > On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> > > > On 28 ene, 19:16, Josh Holland<j...@joshh.co.uk> =A0wrote:
> > > >> On 2010-01-28, Joan Miller<pelok...@gmail.com> =A0wrote:
>
> > > >>> I've to call to many functions with the format:
>
> > > >>>>>> run("cmd")
>
> > > >> Check the docs on os.system().
> > > > No. I've a function that uses subprocess to run commands on the sam=
e
> > > > shell and so substitute to bash scrips. But a script full of run
> > > > ("shell_command --with --arguments") is too verbose.
>
> > > I'm suspicious of your original intent. Essentially, you want to writ=
e
> > > code in which a literal string, such as ...
>
> > > =A0 =A0ls -l
>
> > > ... is *not* enclosed in quotes. Why run the risk of creating confusi=
on
> > > (in other people who look at your code, in syntax-checking tools, etc=
..)
> > > between variables and literals?
>
> > > But I'm in sympathy with your desire to make the code as clean as
> > > possible and to minimize the number of times you have to type a quote
> > > character. My suggestions:
>
> > > 1. Create a function (say, "Run") that encapsulates as much of the
> > > syntax as possible: os.system(), subprocess.call(), string-splitting,
> > > whatever. So an invocation would look like this:
>
> > > =A0 =A0Run("ls -l *.txt")
>
> > > (I think you've already done this step.)
>
> > > 2. Find a text editor that supports keyboard macros, so that a single
> > > keystroke turns this text line:
>
> > > =A0 =A0ls -l *.txt
>
> > > ... into this one:
>
> > > =A0 =A0Run("ls -l *.txt")
>
> > > HTH,
> > > John
>
> > I can't see you avoiding quotes etc, but extending on John's comment,
> > the obvious next step would be to run everything in a loop i.e. place
> > all the commands into a list and create a loop that ran each command
> > in the list.
>
> Yes, but could be necessary that were mixed with python code.
>
> > Almost all editors support macros - most editors support some form of
> > language sensitive editing (NOT the prompt call parameters style but
> > rather help with the syntax via a 'form' style of fill-in) that will
> > allow you to reduce typing effort. But macros would be the first and
> > easiest choice for this activity.
>
> The goal of my program is substitute to bash scripts, so the macros in
> editors are irrelevant fo this one.

I think that the best solution that I've is to build a program that
parses the script to convert *$ command* to run("command") before of
be called by python.

On Jan 28, 10:20=A0am, Joan Miller <pelok...@gmail.com> wrote:
> I've to call to many functions with the format:
>
> >>> run("cmd")
>
> were "cmd" is a command with its arguments to pass them to the shell
> and run it, i.e.
>
>
>
> >>> =A0run("pwd")
> or
> >>> run("ls /home")
>
> Does anybody knows any library to help me to avoid the use of the main
> quotes, and brackets?
>
> I would to use anything as:
>
> $ ls /home =3D> run("ls /home")
>
> or, at least
>
> run pwd =3D> run("pwd")

How about this?

def pwd(): return run("pwd")

pwd()

def ls(l=3DFalse, files=3D()):
    args =3D []
    if l: args.insert(0, '-l')
    args.append(files)
    return run("ls", args)

ls(l=3DTrue, "/foo")

On 28 ene, 21:40, Jonathan Gardner <jgard...@jonathangardner.net>
wrote:
> On Jan 28, 10:20=A0am, Joan Miller <pelok...@gmail.com> wrote:
>
>
>
> > I've to call to many functions with the format:
>
> > >>> run("cmd")
>
> > were "cmd" is a command with its arguments to pass them to the shell
> > and run it, i.e.
>
> > >>> =A0run("pwd")
> > or
> > >>> run("ls /home")
>
> > Does anybody knows any library to help me to avoid the use of the main
> > quotes, and brackets?
>
> > I would to use anything as:
>
> > $ ls /home =3D> run("ls /home")
>
> > or, at least
>
> > run pwd =3D> run("pwd")
>
> How about this?
>
> def pwd(): return run("pwd")
>
> pwd()
>
> def ls(l=3DFalse, files=3D()):
> =A0 =A0 args =3D []
> =A0 =A0 if l: args.insert(0, '-l')
> =A0 =A0 args.append(files)
> =A0 =A0 return run("ls", args)
>
> ls(l=3DTrue, "/foo")

There would be to make a function for each system command to use so it
would be too inefficient, and follow the problem with the quotes.

The best is make a parser into a compiled language

On 1/28/2010 3:45 PM, Joan Miller wrote:
> On 28 ene, 20:34, Joan Miller<pelok...@gmail.com>  wrote:
>> On 28 ene, 20:20, Peter<peter.milli...@gmail.com>  wrote:
>>
>>> On Jan 29, 6:58 am, John Posner<jjpos...@optimum.net>  wrote:
>>
>>>> On 1/28/2010 2:24 PM, Joan Miller wrote:
>>
>>>>> On 28 ene, 19:16, Josh Holland<j...@joshh.co.uk>    wrote:
>>>>>> On 2010-01-28, Joan Miller<pelok...@gmail.com>    wrote:
>>
>>>>>>> I've to call to many functions with the format:
>>
>>>>>>>>>> run("cmd")
>>
>>>>>> Check the docs on os.system().
>>>>> No. I've a function that uses subprocess to run commands on the same
>>>>> shell and so substitute to bash scrips. But a script full of run
>>>>> ("shell_command --with --arguments") is too verbose.
>>
>>>> I'm suspicious of your original intent. Essentially, you want to write
>>>> code in which a literal string, such as ...
>>
>>>>     ls -l
>>
>>>> ... is *not* enclosed in quotes. Why run the risk of creating confusion
>>>> (in other people who look at your code, in syntax-checking tools, etc.)
>>>> between variables and literals?
>>
>>>> But I'm in sympathy with your desire to make the code as clean as
>>>> possible and to minimize the number of times you have to type a quote
>>>> character. My suggestions:
>>
>>>> 1. Create a function (say, "Run") that encapsulates as much of the
>>>> syntax as possible: os.system(), subprocess.call(), string-splitting,
>>>> whatever. So an invocation would look like this:
>>
>>>>     Run("ls -l *.txt")
>>
>>>> (I think you've already done this step.)
>>
>>>> 2. Find a text editor that supports keyboard macros, so that a single
>>>> keystroke turns this text line:
>>
>>>>     ls -l *.txt
>>
>>>> ... into this one:
>>
>>>>     Run("ls -l *.txt")
>>
>>>> HTH,
>>>> John
>>
>>> I can't see you avoiding quotes etc, but extending on John's comment,
>>> the obvious next step would be to run everything in a loop i.e. place
>>> all the commands into a list and create a loop that ran each command
>>> in the list.
>>
>> Yes, but could be necessary that were mixed with python code.
>>
>>> Almost all editors support macros - most editors support some form of
>>> language sensitive editing (NOT the prompt call parameters style but
>>> rather help with the syntax via a 'form' style of fill-in) that will
>>> allow you to reduce typing effort. But macros would be the first and
>>> easiest choice for this activity.
>>
>> The goal of my program is substitute to bash scripts, so the macros in
>> editors are irrelevant fo this one.
>
> I think that the best solution that I've is to build a program that
> parses the script to convert *$ command* to run("command") before of
> be called by python.

I believe you're working on Linux, so how about using "sed"? Here's a 
(prettified) BASH transcript of a sed script (edit.sed) transforming a 
6-line text file (myprog.py). The text file has both Python statements 
and "special commands", which have "$ " at the beginning of the line.

 >>> cat myprog.py
print "hello"
$ ls -l
r = range(10)
$ grep foo bar.data
pass
print "bye"


 >>> cat edit.sed
s/^\$ \(.*\)/Run("\1")/


 >>> sed -f edit.sed data.txt
print "hello"
Run("ls -l")
r = range(10)
Run("grep foo bar.data")
pass
print "bye"

-John

On Jan 28, 2:16=A0pm, Joan Miller <pelok...@gmail.com> wrote:
>
> There would be to make a function for each system command to use so it
> would be too inefficient, and follow the problem with the quotes.
>
> The best is make a parser into a compiled language
>

Yeah, you could do that. Or you can simply rely on /bin/sh to do the
parsing and everything else for you. No need to re-invent the wheel. I
don't think Python will ever beat sh as a shell replacement.

When people say that Python is great for some situations, but not so
much for others, I think they thought of running commands like this as
"other",

Joan Miller <pelok...@gmail.com> wrote:
> Does anybody knows any library to help me to avoid the use of the main
> quotes, and brackets?
> I would to use anything as:
> $ ls /home => run("ls /home")

It's not a library, but IPython[1] provides a lot of what you're
after:

IPython 0.9.1 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints
more.

In [1]: ls /home
bb/  dcallan/  ehornsby/  ftp/	uqamartl/  uqckorte/  uqmtrev2/

In [2]: path = '/home'

In [3]: ls $path
bb/  dcallan/  ehornsby/  ftp/	uqamartl/  uqckorte/  uqmtrev2/

In [4]: output = !ls $path

In [5]: output
Out[5]: SList (.p, .n, .l, .s, .grep(), .fields(), sort() available):
0: bb
1: dcallan
2: ehornsby
3: ftp
4: uqamartl
5: uqckorte
6: uqmtrev2

In [6]: output[6]
Out[6]: 'uqmtrev2'

You'll need to run your scripts with IPython, so this may not be a
solution if you plan on distributing them.

[1] http://ipython.scipy.org/

On Thu, 28 Jan 2010 11:24:28 -0800 (PST), Joan Miller
<peloko45@gmail.com> declaimed the following in
gmane.comp.python.general:

> On 28 ene, 19:16, Josh Holland <j...@joshh.co.uk> wrote:
> > On 2010-01-28, Joan Miller <pelok...@gmail.com> wrote:
> >
> > > I've to call to many functions with the format:
> >
> > >>>> run("cmd")
> >
> > Check the docs on os.system().
> No. I've a function that uses subprocess to run commands on the same
> shell and so substitute to bash scrips. But a script full of run
> ("shell_command --with --arguments") is too verbose.

	I shall blaspheme, and suggest that maybe the language you want to
use is REXX (ooREXX or Regina).

	By default, ANY statement that can not be confused for a REXX
language statement is sent to the currently defined command handler
(Which on most OSs is equivalent to Python's os.system() call; the late
Amiga, and IBM's mainframe OS had features that support defining other
applications as command handlers).

	A common practice is to put quotes about the first word of the
command to ensure it gets treated as external command.

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

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> On Thu, 28 Jan 2010 11:24:28 -0800 (PST), Joan Miller:
> > On 28 ene, 19:16, Josh Holland <j...@joshh.co.uk> wrote:
> > > Check the docs on os.system().
> > No. I've a function that uses subprocess to run commands on the same
> > shell and so substitute to bash scrips. But a script full of run
> > ("shell_command --with --arguments") is too verbose.
>
> 	I shall blaspheme, and suggest that maybe the language you want
> to use is REXX (ooREXX or Regina).

Heh. That isn't blasphemy, because no true Pythonista [0] would claim
Python to be the god of that domain.

It's no sin to say that Python isn't a good choice for specific things;
and “I want to write programs by indistinguishably mixing statements
with external system calls” is one of them, IMO.


[0] fully aware of <URL:http://rationalwiki.com/wiki/No_True_Scotsman>,
    thanks in advance.

-- 
 \      “Natural catastrophes are rare, but they come often enough. We |
  `\   need not force the hand of nature.” —Carl Sagan, _Cosmos_, 1980 |
_o__)                                                                  |
Ben Finney

On Thu, Jan 28, 2010 at 9:44 PM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Thu, 28 Jan 2010 11:24:28 -0800 (PST), Joan Miller
> <peloko45@gmail.com> declaimed the following in
> gmane.comp.python.general:
>
> > On 28 ene, 19:16, Josh Holland <j...@joshh.co.uk> wrote:
> > > On 2010-01-28, Joan Miller <pelok...@gmail.com> wrote:
> > >
> > > > I've to call to many functions with the format:
> > >
> > > >>>> run("cmd")
> > >
> > > Check the docs on os.system().
> > No. I've a function that uses subprocess to run commands on the same
> > shell and so substitute to bash scrips. But a script full of run
> > ("shell_command --with --arguments") is too verbose.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0I shall blaspheme, and suggest that maybe the =
language you want to
> use is REXX (ooREXX or Regina).

Sounds like the REXX designers already got the blaspheming covered
when they came up with such an inelegant-sounding feature...

> =C2=A0 =C2=A0 =C2=A0 =C2=A0By default, ANY statement that can not be conf=
used for a REXX
> language statement is sent to the currently defined command handler
> (Which on most OSs is equivalent to Python's os.system() call; the late
> Amiga, and IBM's mainframe OS had features that support defining other
> applications as command handlers).
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0A common practice is to put quotes about the f=
irst word of the
> command to ensure it gets treated as external command.

Cheers,
Chris
--
http://blog.rebertia.com

On 28 ene, 23:36, Jonathan Gardner <jgard...@jonathangardner.net>
wrote:
> On Jan 28, 2:16=A0pm, Joan Miller <pelok...@gmail.com> wrote:
>
>
>
> > There would be to make a function for each system command to use so it
> > would be too inefficient, and follow the problem with the quotes.
>
> > The best is make a parser into a compiled language
>
> Yeah, you could do that. Or you can simply rely on /bin/sh to do the
> parsing and everything else for you. No need to re-invent the wheel. I
> don't think Python will ever beat sh as a shell replacement.
>
> When people say that Python is great for some situations, but not so
> much for others, I think they thought of running commands like this as
> "other",

I started to working on this project (Scripy [1]) because I wanted to
hacking cryptsetup in my ubuntu. The funcionts to manage its
initialization are in bash and it goes to be non-maintainable code,
cryptic and very hard to debug (as whatever bash script of medium
size). Here you have the beast:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/cryptsetup/karmi=
c/annotate/head%3A/debian/cryptdisks.functions

Using Scripy I can debug easily the commands run from the shell, and
log all if I would.

Now, thanks to Scripy I've created a script for easily disks
partitioning [2] using a simple cofiguration in YAML [3]. The great
thing is that I can add volumes and encrypted partitions :)

The only problem is that it's too verbose but I could rename *run()*
by a simple function as *_()* or *r()*


[1] http://bitbucket.org/ares/scripy/src/
[2] http://bitbucket.org/ares/scripypartition/src/tip/lib/scripy/part/disk.=
py#cl-22
[3] http://bitbucket.org/ares/scripypartition/src/tip/bin/init_crypto.py#cl=
-46

On 28 ene, 22:57, John Posner <jjpos...@optimum.net> wrote:
> On 1/28/2010 3:45 PM, Joan Miller wrote:
>
>
>
> > On 28 ene, 20:34, Joan Miller<pelok...@gmail.com> =A0wrote:
> >> On 28 ene, 20:20, Peter<peter.milli...@gmail.com> =A0wrote:
>
> >>> On Jan 29, 6:58 am, John Posner<jjpos...@optimum.net> =A0wrote:
>
> >>>> On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> >>>>> On 28 ene, 19:16, Josh Holland<j...@joshh.co.uk> =A0 =A0wrote:
> >>>>>> On 2010-01-28, Joan Miller<pelok...@gmail.com> =A0 =A0wrote:
>
> >>>>>>> I've to call to many functions with the format:
>
> >>>>>>>>>> run("cmd")
>
> >>>>>> Check the docs on os.system().
> >>>>> No. I've a function that uses subprocess to run commands on the sam=
e
> >>>>> shell and so substitute to bash scrips. But a script full of run
> >>>>> ("shell_command --with --arguments") is too verbose.
>
> >>>> I'm suspicious of your original intent. Essentially, you want to wri=
te
> >>>> code in which a literal string, such as ...
>
> >>>> =A0 =A0 ls -l
>
> >>>> ... is *not* enclosed in quotes. Why run the risk of creating confus=
ion
> >>>> (in other people who look at your code, in syntax-checking tools, et=
c.)
> >>>> between variables and literals?
>
> >>>> But I'm in sympathy with your desire to make the code as clean as
> >>>> possible and to minimize the number of times you have to type a quot=
e
> >>>> character. My suggestions:
>
> >>>> 1. Create a function (say, "Run") that encapsulates as much of the
> >>>> syntax as possible: os.system(), subprocess.call(), string-splitting=
,
> >>>> whatever. So an invocation would look like this:
>
> >>>> =A0 =A0 Run("ls -l *.txt")
>
> >>>> (I think you've already done this step.)
>
> >>>> 2. Find a text editor that supports keyboard macros, so that a singl=
e
> >>>> keystroke turns this text line:
>
> >>>> =A0 =A0 ls -l *.txt
>
> >>>> ... into this one:
>
> >>>> =A0 =A0 Run("ls -l *.txt")
>
> >>>> HTH,
> >>>> John
>
> >>> I can't see you avoiding quotes etc, but extending on John's comment,
> >>> the obvious next step would be to run everything in a loop i.e. place
> >>> all the commands into a list and create a loop that ran each command
> >>> in the list.
>
> >> Yes, but could be necessary that were mixed with python code.
>
> >>> Almost all editors support macros - most editors support some form of
> >>> language sensitive editing (NOT the prompt call parameters style but
> >>> rather help with the syntax via a 'form' style of fill-in) that will
> >>> allow you to reduce typing effort. But macros would be the first and
> >>> easiest choice for this activity.
>
> >> The goal of my program is substitute to bash scripts, so the macros in
> >> editors are irrelevant fo this one.
>
> > I think that the best solution that I've is to build a program that
> > parses the script to convert *$ command* to run("command") before of
> > be called by python.
>
> I believe you're working on Linux, so how about using "sed"? Here's a
> (prettified) BASH transcript of a sed script (edit.sed) transforming a
> 6-line text file (myprog.py). The text file has both Python statements
> and "special commands", which have "$ " at the beginning of the line.
>
> =A0>>> cat myprog.py
> print "hello"
> $ ls -l
> r =3D range(10)
> $ grep foo bar.data
> pass
> print "bye"
>
> =A0>>> cat edit.sed
> s/^\$ \(.*\)/Run("\1")/
>
> =A0>>> sed -f edit.sed data.txt
> print "hello"
> Run("ls -l")
> r =3D range(10)
> Run("grep foo bar.data")
> pass
> print "bye"
>
> -John

Yes, this would a well solution. Simple and fast to build.

On 29 ene, 05:44, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
> On Thu, 28 Jan 2010 11:24:28 -0800 (PST), Joan Miller
> <pelok...@gmail.com> declaimed the following in
> gmane.comp.python.general:
>
> > On 28 ene, 19:16, Josh Holland <j...@joshh.co.uk> wrote:
> > > On 2010-01-28, Joan Miller <pelok...@gmail.com> wrote:
>
> > > > I've to call to many functions with the format:
>
> > > >>>> run("cmd")
>
> > > Check the docs on os.system().
> > No. I've a function that uses subprocess to run commands on the same
> > shell and so substitute to bash scrips. But a script full of run
> > ("shell_command --with --arguments") is too verbose.
>
> =A0 =A0 =A0 =A0 I shall blaspheme, and suggest that maybe the language yo=
u want to
> use is REXX (ooREXX or Regina).
>
> =A0 =A0 =A0 =A0 By default, ANY statement that can not be confused for a =
REXX
> language statement is sent to the currently defined command handler
> (Which on most OSs is equivalent to Python's os.system() call; the late
> Amiga, and IBM's mainframe OS had features that support defining other
> applications as command handlers).
>
> =A0 =A0 =A0 =A0 A common practice is to put quotes about the first word o=
f the
> command to ensure it gets treated as external command.
I prefer Python since that has a great standard library where I get a
well logging system between another things. In addition, the main
intended audience will be for system administrators who many of them
already have used it.

On Thu, 28 Jan 2010 22:14:09 -0800, Chris Rebert <clp2@rebertia.com>
declaimed the following in gmane.comp.python.general:

> Sounds like the REXX designers already got the blaspheming covered
> when they came up with such an inelegant-sounding feature...
>
	Ah, but on the original OS, and on the Amiga, it was quite an
elegant feature...

	It meant any application that implemented a REXX command host
interface could be scripted by a REXX program -- AND that script was not
tied to just one application. It made REXX a multi-application scripting
language.

	One could, fairly easily, script operations that could pull
paragraphs out of a word processor, and paste them into a page layout
program, using what was the equivalent of command line statements unique
to each.

	I've not used REXX in some years -- Python is a cleaner syntax for
pure programming (REXX uses a "," as the continuation character, which
makes for weird statements when one continues a comma separated sequence
of parameters over multiple lines)... OTOH, my first real Python program
(on something predating 1.5.2) was a simple outgoing SMTPd on the Amiga
-- and I used REXX as the spooling mechanism from the client. If I'd
gotten fancier, I'd have had it going direct (since [forgive me, I've
forgotten your name] the person who ported Python to the Amiga DID
implement a REXX interface module).
-- 
	Wulfraed	 Dennis Lee Bieber		 KD6MOG
	wlfraed@ix.netcom.com	HTTP://wlfraed.home.netcom.com/

In article <mailman.1585.1264743912.28905.python-list@python.org>,
Dennis Lee Bieber  <wlfraed@ix.netcom.com> wrote:
>
>	I shall blaspheme, and suggest that maybe the language you want to
>use is REXX (ooREXX or Regina).
>
>	By default, ANY statement that can not be confused for a REXX
>language statement is sent to the currently defined command handler
>(Which on most OSs is equivalent to Python's os.system() call; the late
>Amiga, and IBM's mainframe OS had features that support defining other
>applications as command handlers).

How is that different from bash scripting?
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

import antigravity

Joan Miller wrote:
> On 28 ene, 21:40, Jonathan Gardner <jgard...@jonathangardner.net>
> wrote:
>   
>> On Jan 28, 10:20 am, Joan Miller <pelok...@gmail.com> wrote:
>>
>>
>>
>>     
>>> I've to call to many functions with the format:
>>>       
>>>>>> run("cmd")
>>>>>>             
>>> were "cmd" is a command with its arguments to pass them to the shell
>>> and run it, i.e.
>>>       
>>>>>>  run("pwd")
>>>>>>             
>>> or
>>>       
>>>>>> run("ls /home")
>>>>>>             
>>> Does anybody knows any library to help me to avoid the use of the main
>>> quotes, and brackets?
>>>       
>>> I would to use anything as:
>>>       
>>> $ ls /home => run("ls /home")
>>>       
>>> or, at least
>>>       
>>> run pwd => run("pwd")
>>>       
>> How about this?
>>
>> def pwd(): return run("pwd")
>>
>> pwd()
>>
>> def ls(l=False, files=()):
>>     args = []
>>     if l: args.insert(0, '-l')
>>     args.append(files)
>>     return run("ls", args)
>>
>> ls(l=True, "/foo")
>>     
>
> There would be to make a function for each system command to use so it
> would be too inefficient, and follow the problem with the quotes.
>
> The best is make a parser into a compiled language
>   
'disagree.

Best is to have a text file outside your program, in which you define 
commands and symbolic names for those commands.

Then you have a python module which reads these commands and names, and 
creates functions that invoke them via the specified name.

This way you get concise syntax, don't have to type as much boilerplate, 
and don't add line noise.

Mixing two languages as though they were the same language greatly 
increases the complexity of the original language with little gain.

Consider PowerShell - it's almost like two different languages smushed 
together, and you have to know how a command was implemented to know how 
to read it.

Also, what if someday The Powers That Be (the python language core 
designers) decide they need to use $ for something?  I hope they won't, 
but if they do, your preprocessor might make quite a mess of it.

Ben Finney wrote:
> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>
>   
>> On Thu, 28 Jan 2010 11:24:28 -0800 (PST), Joan Miller:
>>     
>>> On 28 ene, 19:16, Josh Holland <j...@joshh.co.uk> wrote:
>>>       
>>>> Check the docs on os.system().
>>>>         
>>> No. I've a function that uses subprocess to run commands on the same
>>> shell and so substitute to bash scrips. But a script full of run
>>> ("shell_command --with --arguments") is too verbose.
>>>       
>> 	I shall blaspheme, and suggest that maybe the language you want
>> to use is REXX (ooREXX or Regina).
>>     
>
> Heh. That isn't blasphemy, because no true Pythonista [0] would claim
> Python to be the god of that domain.
>
> It's no sin to say that Python isn't a good choice for specific things;
> and “I want to write programs by indistinguishably mixing statements
> with external system calls” is one of them, IMO
>From 
http://stromberg.dnsalias.org/~dstromberg/debugging-with-syscall-tracers.html#terminology

    A quick note on terminology: open() is typically a system call.
    fopen is probably never a system call - instead, it is a function in
    the C library that wraps open(), making open() easier to use. Then
    there's the system() function - like fopen(), it isn't really a
    system call, despite its name. Rather, it is a C library function
    that typically will wrap the fork() and exec*() system calls.

Dan Stromberg <drsalists@gmail.com> writes:

> Ben Finney wrote:
> > It's no sin to say that Python isn't a good choice for specific
> > things; and “I want to write programs by indistinguishably mixing
> > statements with external system calls” is one of them, IMO

> > From 
> http://stromberg.dnsalias.org/~dstromberg/debugging-with-syscall-tracers.html#terminology
>
>    A quick note on terminology: open() is typically a system call.
[…]

That is a different use of “system call”. I used it in the ‘os.system’
sense: meaning “invoke an external OS command as a child of this
process”.

-- 
 \           “I was in a bar the other night, hopping from barstool to |
  `\     barstool, trying to get lucky, but there wasn't any gum under |
_o__)                                       any of them.” —Emo Philips |
Ben Finney

On 3 Feb 2010 08:38:47 -0800, aahz@pythoncraft.com (Aahz) declaimed the
following in gmane.comp.python.general:

> In article <mailman.1585.1264743912.28905.python-list@python.org>,
> Dennis Lee Bieber  <wlfraed@ix.netcom.com> wrote:
> >
> >	I shall blaspheme, and suggest that maybe the language you want to
> >use is REXX (ooREXX or Regina).
> >
> >	By default, ANY statement that can not be confused for a REXX
> >language statement is sent to the currently defined command handler
> >(Which on most OSs is equivalent to Python's os.system() call; the late
> >Amiga, and IBM's mainframe OS had features that support defining other
> >applications as command handlers).
> 
> How is that different from bash scripting?

	Uhm... Does a bash script support inlining statements from some
other language?

	Python's shutil library essentially disappears in REXX as one can
plug in the native command line statement for those functions.
-- 
	Wulfraed	 Dennis Lee Bieber		 KD6MOG
	wlfraed@ix.netcom.com	HTTP://wlfraed.home.netcom.com/

In article <mailman.1885.1265261952.28905.python-list@python.org>,
Dennis Lee Bieber  <wlfraed@ix.netcom.com> wrote:
>On 3 Feb 2010 08:38:47 -0800, aahz@pythoncraft.com (Aahz) declaimed the
>following in gmane.comp.python.general:
>> In article <mailman.1585.1264743912.28905.python-list@python.org>,
>> Dennis Lee Bieber  <wlfraed@ix.netcom.com> wrote:
>>>
>>>	I shall blaspheme, and suggest that maybe the language you want to
>>>use is REXX (ooREXX or Regina).
>>>
>>>	By default, ANY statement that can not be confused for a REXX
>>>language statement is sent to the currently defined command handler
>>>(Which on most OSs is equivalent to Python's os.system() call; the late
>>>Amiga, and IBM's mainframe OS had features that support defining other
>>>applications as command handlers).
>> 
>> How is that different from bash scripting?
>
>	Uhm... Does a bash script support inlining statements from some
>other language?
>
>	Python's shutil library essentially disappears in REXX as one can
>plug in the native command line statement for those functions.


But in bash scripting, you'd just use rsync or cp or rm -- maybe an
example would make clearer how REXX differs from bash.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

import antigravity

On 4 Feb 2010 16:18:04 -0800, aahz@pythoncraft.com (Aahz) declaimed the
following in gmane.comp.python.general:

> 
> But in bash scripting, you'd just use rsync or cp or rm -- maybe an
> example would make clearer how REXX differs from bash.

	I suspect the only really good examples would have to written under
OS/VMS (where it originated, written to be a more powerful & friendlier
replacement for the EXEC scripting language) or AmigaOS -- to
demonstrate the switching interaction of command handlers. REXX
implementations for Windows and Linux pretty much only support the
"shell" as a command handler, whereas the two named OS could address
editors (and on the Amiga, word processors, desktop publishing programs,
terminal emulators/comm programs, system editor).

	My Amiga's been in storage since Win95 days, so this is a fictitious
example based on the reference manuals.

address command	/* use normal command shell to process commands */
file = 'some.file'
'run ed' file	/* start ED editor in background, editing 'file'*/
address ED	/* send commands to the ED instance */
'b'		/* go to bottom of file */
'i /text to be inserted before bottom line/'
't'		/* to to top */
'a /text inserted after first line/'
find = 'needle'
replace = 'thorn'
'rpe /' || find || '/' || replace '/'
'x'	/* save & exit */
address command
'type' file		/* type file to screen */
'filenote' file "edited via AREXX script"

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

In article <mailman.1944.1265367378.28905.python-list@python.org>,
Dennis Lee Bieber  <wlfraed@ix.netcom.com> wrote:
>On 4 Feb 2010 16:18:04 -0800, aahz@pythoncraft.com (Aahz) declaimed the
>following in gmane.comp.python.general:
>> 
>> But in bash scripting, you'd just use rsync or cp or rm -- maybe an
>> example would make clearer how REXX differs from bash.
>
>	I suspect the only really good examples would have to written under
>OS/VMS (where it originated, written to be a more powerful & friendlier
>replacement for the EXEC scripting language) or AmigaOS -- to
>demonstrate the switching interaction of command handlers. REXX
>implementations for Windows and Linux pretty much only support the
>"shell" as a command handler, whereas the two named OS could address
>editors (and on the Amiga, word processors, desktop publishing programs,
>terminal emulators/comm programs, system editor).
>
>	My Amiga's been in storage since Win95 days, so this is a fictitious
>example based on the reference manuals.
>
>address command	/* use normal command shell to process commands */
>file = 'some.file'
>'run ed' file	/* start ED editor in background, editing 'file'*/
>address ED	/* send commands to the ED instance */
>'b'		/* go to bottom of file */
>'i /text to be inserted before bottom line/'
>'t'		/* to to top */
>'a /text inserted after first line/'
>find = 'needle'
>replace = 'thorn'
>'rpe /' || find || '/' || replace '/'
>'x'	/* save & exit */
>address command
>'type' file		/* type file to screen */
>'filenote' file "edited via AREXX script"

IOW, kinda like AppleScript?
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

import antigravity

On 5 Feb 2010 08:23:57 -0800, aahz@pythoncraft.com (Aahz) declaimed the
following in gmane.comp.python.general:

> IOW, kinda like AppleScript?

	Never seen AppleScript... Suspect REXX predates it. 

	Oh, definitely -- wikipedia gives AppleScript a fall 1993 release.
My ARexx manual is dated 1987 -- six years earlier; and IBM's release
was around 1982
-- 
	Wulfraed	 Dennis Lee Bieber		 KD6MOG
	wlfraed@ix.netcom.com	HTTP://wlfraed.home.netcom.com/