Python as a scripting language. Alternative to bash script?
in [Python]
|
From: Dave Pawson on 2 Jul 2010 02:26 I'm the OP btw. On 1 July 2010 18:10, Dennis Lee Bieber <wlfraed(a)ix.netcom.com> 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 separator, AND the continued line indicator, leading to lines > that end in , ,) I'd consider a decent* REXX implementation first... > Â Â Â Â Any program line that is not recognized as starting a REXX statement > is automatically passed to the currently defined command processor. And > one could ensure this by just quoting the first word on the line <G> Useful. However, I know Python, never looked at Rexx, so not much use to me. Tks -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk
From: Jerry Rocteur on 2 Jul 2010 06:07 * Dave Pawson <dave.pawson(a)gmail.com> [2010-07-02 08:22]: > I'm the OP btw. > > On 1 July 2010 18:10, Dennis Lee Bieber <wlfraed(a)ix.netcom.com> 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 System Administration: http://www.amazon.com/Python-Unix-Linux-System-Administration/dp/0596515820 I quite like the book, I learned about Ipython from this book and I'm quite glad I did! Jerry
From: Lawrence D'Oliveiro on 5 Jul 2010 02:50 In message <7xpqzbj8st.fsf(a)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/put its arguments somewhere.
From: Lawrence D'Oliveiro on 5 Jul 2010 02:52 In message <Xns9DA77F36B9F6EMithrandirIsAwesome(a)80.93.112.4>, 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 can't seem to pipe compressed audio ImportCmd = \ ( "ffmpeg -v 0 -i <(%(src_video)s)" " %(audio_parms)s -i <(%(src_audio)s)" " -vcodec copy -acodec %(audio_codec)s -y %(dstfile)s" % { "src_video" : "; ".join ( [ "ffmpeg -v 0 -i %(srcfile)s -f image2pipe -vcodec copy" " -y /dev/stdout" % {"srcfile" : ShellEscape(SrcFile)} for SrcFile in SrcFiles ] ), # pipe through compressed video without recompression "src_audio" : "; ".join ( [ "ffmpeg -v 0 -i %(srcfile)s %(audio_parms)s -y /dev/stdout" % { "srcfile" : ShellEscape(SrcFile), "audio_parms" : AudioParms, } for SrcFile in SrcFiles ] ), "dstfile" : ShellEscape(DstFile), "audio_parms" : AudioParms, "audio_codec" : "mp2", # assumption! } )
From: Lawrence D'Oliveiro on 5 Jul 2010 02:56
In message <op.ve06nlvia8ncjz(a)gnudebst>, 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 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 work that way. The command line (or scripting, the difference isn't that important) remains the only workable way to string together complex combinations of simpler operations. |