On 2010-07-24, Lawrence D'Oliveiro wrote:
> In message , Tim Harig wrote:
>
>> On 2010-07-05, Lawrence D'Oliveiro
>> wrote:
>>>
>>> I???ve never come across any system where you could string together
>>> multiple GUI apps, or even multiple GUI operations in the same app, in
>>> any sensible or ef
In message , Michael
Torrie wrote:
> While it's possible to set up pipes and spawn programs in parallel to
> operate on the pipes, in practice it's simpler to tell subprocess.Popen
> to use a shell and then just rely on Bash's very nice syntax for setting
> up the pipeline.
Just be careful about
In message , Tim Harig wrote:
> On 2010-07-05, Lawrence D'Oliveiro
> wrote:
>>
>> I’ve never come across any system where you could string together
>> multiple GUI apps, or even multiple GUI operations in the same app, in
>> any sensible or effective way at all. GUIs just aren???t designed to wor
On Wed, Jul 7, 2010 at 8:31 AM, Michael Torrie wrote:
> On 07/06/2010 09:34 PM, Chris Rebert wrote:
>> On Tue, Jul 6, 2010 at 6:40 AM, Michael Torrie wrote:
>>> While it's possible to set up pipes and spawn programs in parallel to
>>> operate on the pipes, in practice it's simpler to tell subproc
On 07/06/2010 09:34 PM, Chris Rebert wrote:
> On Tue, Jul 6, 2010 at 6:40 AM, Michael Torrie wrote:
>> While it's possible to set up pipes and spawn programs in parallel to
>> operate on the pipes, in practice it's simpler to tell subprocess.Popen
>> to use a shell and then just rely on Bash's ver
John Nagle, 28.06.2010 19:57:
Programs have "argv" and "argc", plus environment variables,
going in. So, going in, there are essentially subroutine parameters.
But all that comes back is an exit code. They should have had
something similar coming back, with arguments to "exit()" returning
the res
On Tue, Jul 6, 2010 at 6:40 AM, Michael Torrie wrote:
> On 07/06/2010 04:12 AM, sturlamolden wrote:
>> On 28 Jun, 19:39, Michael Torrie wrote:
>>> In python I could simply take the output of "ps ax" and use python's
>>> own, superior, cutting routines (using my module):
>>>
>>> (err, stdout, stde
On Tue, Jul 6, 2010 at 1:35 PM, member thudfoo wrote:
> On Tue, Jul 6, 2010 at 6:40 AM, Michael Torrie wrote:
>> On 07/06/2010 04:12 AM, sturlamolden wrote:
>>> On 28 Jun, 19:39, Michael Torrie wrote:
In python I could simply take the output of "ps ax" and use python's
own, superior, c
On Tue, Jul 6, 2010 at 6:40 AM, Michael Torrie wrote:
> On 07/06/2010 04:12 AM, sturlamolden wrote:
>> On 28 Jun, 19:39, Michael Torrie wrote:
>>
>>> In python I could simply take the output of "ps ax" and use python's
>>> own, superior, cutting routines (using my module):
>>>
>>> (err, stdout, s
On 07/06/2010 04:12 AM, sturlamolden wrote:
> On 28 Jun, 19:39, Michael Torrie wrote:
>
>> In python I could simply take the output of "ps ax" and use python's
>> own, superior, cutting routines (using my module):
>>
>> (err, stdout, stderr) = runcmd.run( [ 'ps', 'ax' ] )
>> for x in stdout.split
On 28 Jun, 19:39, Michael Torrie wrote:
> In python I could simply take the output of "ps ax" and use python's
> own, superior, cutting routines (using my module):
>
> (err, stdout, stderr) = runcmd.run( [ 'ps', 'ax' ] )
> for x in stdout.split('\n'):
> print x.strip().split()[0]
Or you just
On 7/5/2010 11:02 AM Tim Harig said...
Automating GUI applications requires interal
access to the program through some kind of interface and, ideally, decent
documention of the interface, something that is missing from many, if
not most, GUIs. Anything else relies on ugly and, generally fragile
On 2010-07-05, Lawrence D'Oliveiro wrote:
> In message , Rhodri James wrote:
>> Classic Unix programming is a matter of stringing a bunch of tools
>> together with pipes to get the output you want. This isn't a great
>> paradigm for GUIs (not without tweaking that hasn't really been done), but
>>
In message , Rhodri James wrote:
> Classic Unix programming is a matter of stringing a bunch of tools
> together with pipes to get the output you want. This isn't a great
> paradigm for GUIs (not without tweaking that hasn't really been done), but
> then again it was never meant to be.
I’ve neve
In message , Mithrandir wrote:
> I think that Python "could" be a alternative to bash and have some
> advantages, but it's a long way off from being fully implemented.
Would you prefer to do the following sort of thing in Python or Bash?
AudioParms = "-f s16le -ar 48000 -ac 2" # because I
In message <7xpqzbj8st@ruckus.brouhaha.com>, Paul Rubin wrote:
> ... and argc/argv were passed to the child process on its stack.
I’ve always felt that to be a misfeature. It means you can’t implement a
self-contained argument-parsing library, it still needs the mainline to
explicitly pass/
* Dave Pawson [2010-07-02 08:22]:
> I'm the OP btw.
>
> On 1 July 2010 18:10, Dennis Lee Bieber wrote:
>
> >> I think that Python "could" be a alternative to bash and have some
> >> advantages, but it's a long way off from being fully implemented.
> >
Take a look at Python for Unix and Linux S
I'm the OP btw.
On 1 July 2010 18:10, Dennis Lee Bieber wrote:
>> I think that Python "could" be a alternative to bash and have some
>> advantages, but it's a long way off from being fully implemented.
>
> While a somewhat klutzier language in aspects (the , is both an
> parameter separat
Michael Torrie wrote in
news:mailman.2313.1277759925.32709.python-l...@python.org:
> On 06/28/2010 02:06 PM, Mithrandir wrote:
>> I can't see Python as an alt. to bash. (As I recall) Python is much
>> more object-oriented than bash, but also there are many commands
>> (such as apt- get, etc.) th
On 6/29/10 4:06 AM, Jorgen Grahn wrote:
On Mon, 2010-06-28, John Nagle wrote:
On 6/28/2010 7:58 AM, Benjamin Kaplan wrote:
How does a program return anything other than an exit code?
Ah, yes, the second biggest design mistake in UNIX.
Programs have "argv" and "argc", plus environme
On Jun 28, 5:48 am, Dave Pawson wrote:
> I've a fairly long bash script and I'm wondering
> how easy it would be to port to Python.
>
> Main queries are:
> Ease of calling out to bash to use something like imageMagick or Java?
> Ease of grabbing return parameters? E.g. convert can return both
> he
On Mon, 2010-06-28, Dave Pawson wrote:
> I've a fairly long bash script and I'm wondering
> how easy it would be to port to Python.
>
> Main queries are:
> Ease of calling out to bash to use something like imageMagick or Java?
> Ease of grabbing return parameters? E.g. convert can return both
> hei
On Mon, 2010-06-28, John Nagle wrote:
> On 6/28/2010 7:58 AM, Benjamin Kaplan wrote:
>> How does a program return anything other than an exit code?
>
> Ah, yes, the second biggest design mistake in UNIX.
>
> Programs have "argv" and "argc", plus environment variables,
> going in. So, going
On Mon, 28 Jun 2010 23:12:47 +0100, Rhodri James wrote:
> On Mon, 28 Jun 2010 18:57:45 +0100, John Nagle wrote:
>
>> On 6/28/2010 7:58 AM, Benjamin Kaplan wrote:
>>> How does a program return anything other than an exit code?
>>
>> Ah, yes, the second biggest design mistake in UNIX.
>>
>>
On Mon, 28 Jun 2010 18:57:45 +0100, John Nagle wrote:
On 6/28/2010 7:58 AM, Benjamin Kaplan wrote:
How does a program return anything other than an exit code?
Ah, yes, the second biggest design mistake in UNIX.
Programs have "argv" and "argc", plus environment variables,
going in.
On 06/28/2010 02:06 PM, Mithrandir wrote:
> I can't see Python as an alt. to bash. (As I recall) Python is much more
> object-oriented than bash, but also there are many commands (such as apt-
> get, etc.) that would need Python equivs. However, I can see Python being
> used as a scripting alt. t
On 6/28/10 1:06 PM, Mithrandir wrote:
Paul Rubin wrote in
news:7xpqzbj8st@ruckus.brouhaha.com:
Re: Python as a scripting language. Alternative to bash script?
That's interesting but I'm having a hard time seeing how it would work.
I think environment variables didn't
Paul Rubin wrote in
news:7xpqzbj8st@ruckus.brouhaha.com:
> Re: Python as a scripting language. Alternative to bash script?
> That's interesting but I'm having a hard time seeing how it would work.
> I think environment variables didn't exist in early versions of Un
John Nagle writes:
>Programs have "argv" and "argc", plus environment variables,
> going in. So, going in, there are essentially subroutine parameters.
> But all that comes back is an exit code. They should have had
> something similar coming back, with arguments to "exit()" returning
> the r
On 06/28/2010 12:05 PM, Dave Pawson wrote:
> On 28 June 2010 18:39, Michael Torrie wrote:
>
>> Sure. I've created a module called runcmd that does 90% of what I
>> want (easy access to stdout, stderr, error code). I've attached
>> it to this e-mail. Feel free to use it; this post puts my code
On 28 June 2010 18:39, Michael Torrie wrote:
> On 06/28/2010 05:48 AM, Dave Pawson wrote:
>> Main queries are: Ease of calling out to bash to use something like
>> imageMagick or Java? Ease of grabbing return parameters? E.g. convert
>> can return both height and width of an image. Can this be ret
On 6/28/2010 7:58 AM, Benjamin Kaplan wrote:
How does a program return anything other than an exit code?
Ah, yes, the second biggest design mistake in UNIX.
Programs have "argv" and "argc", plus environment variables,
going in. So, going in, there are essentially subroutine parameters.
On 06/28/2010 05:48 AM, Dave Pawson wrote:
> Main queries are: Ease of calling out to bash to use something like
> imageMagick or Java? Ease of grabbing return parameters? E.g. convert
> can return both height and width of an image. Can this be returned to
> the Python program? Can Python access th
On 06/28/2010 06:08 PM, Dave Pawson wrote:
> Thanks for the replies (and Benjamin).
> Not met with the subprocess idea.
>
> On 28 June 2010 16:29, D'Arcy J.M. Cain wrote:
>
>>> Main queries are:
>>> Ease of calling out to bash to use something like imageMagick or Java?
>>
>> You don't need to ca
Thanks for the replies (and Benjamin).
Not met with the subprocess idea.
On 28 June 2010 16:29, D'Arcy J.M. Cain wrote:
>> Main queries are:
>> Ease of calling out to bash to use something like imageMagick or Java?
>
> You don't need to call bash to call an external program. Check out the
> sub
On Mon, 28 Jun 2010 12:48:51 +0100
Dave Pawson wrote:
> I've a fairly long bash script and I'm wondering
> how easy it would be to port to Python.
That's too big a question without seeing more of what your script
does. I will try to suggest some direction though.
First, if you have a complicate
On Mon, Jun 28, 2010 at 4:48 AM, Dave Pawson wrote:
> I've a fairly long bash script and I'm wondering
> how easy it would be to port to Python.
>
> Main queries are:
> Ease of calling out to bash to use something like imageMagick or Java?
Easiest way is os.system, most flexible way is subprocess
I've a fairly long bash script and I'm wondering
how easy it would be to port to Python.
Main queries are:
Ease of calling out to bash to use something like imageMagick or Java?
Ease of grabbing return parameters? E.g. convert can return both
height and width of an image. Can this be returned to t
38 matches
Mail list logo
