Re: bash vs. python scripts - which one is better?
On 2007-08-21 17:50:53 -0600, Bob Proulx wrote: Vincent Lefevre wrote: vin:~ bash [EMAIL PROTECTED]:~$ touch exists [EMAIL PROTECTED]:~$ [ ! -a exists ] || echo found [EMAIL PROTECTED]:~$ /usr/bin/[ ! -a exists ] || echo found found You are running afoul of -a ambiguity. Stop that. Do you mean AND such as -a intends? I didn't mean any specific behavior. I just noted that /usr/bin/[ and [ bash builtin are not compatible. Use -e if you want to test for simple file existence. Of course, but I also have to live with scripts (not written by me) that use '-a' (and of course, I cannot really in advance if '-a' is used or not). That's the real world. :( Now, what about the following test, which does not test file existence? [EMAIL PROTECTED]:~$ [ true -a \( ! -a \) ] echo OK bash: [: `)' expected, found ] [EMAIL PROTECTED]:~$ /usr/bin/[ true -a \( ! -a \) ] echo OK [EMAIL PROTECTED]:~$ This is unspecified by POSIX, but test(1) has its own documentation. If you prefer, the bash builtin breaks the compatibility with test(1) even if it is non-standard. Are you sure that [ $foo = ] isn't POSIX sh? IMHO, it is perfectly valid (note: the quotes are important). POSIX defines this okay but as I was noting the traditional use was to use the X to prevent the old test from parsing it as an option. In the traditional environment this was not protected by the new POSIX requirement to count the number of program arguments provided. OK, I now understand. I read somewhere else that the cause was empty strings. Even in a POSIX environment, there's still a problem if $foo is '!' (if I'm not mistaken, this is an unspecified results case). I still prefer to use -z and -n instead. Yes. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-21 09:55:46 -0700, David Brodbeck wrote: Linux is the only *nix-ish OS I've used where /bin/sh and bash are synonymous. ;) You probably haven't used it, but under Mac OS X too: prunille:~ uname -a Darwin prunille.vinc17.org 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh powerpc PowerMac7,3 Darwin prunille:~ sh --version GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.0) Copyright (C) 2002 Free Software Foundation, Inc. (This is the default, I didn't change anything.) -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-22 13:53:34 +0200, Vincent Lefevre wrote: Now, what about the following test, which does not test file existence? [EMAIL PROTECTED]:~$ [ true -a \( ! -a \) ] echo OK bash: [: `)' expected, found ] [EMAIL PROTECTED]:~$ /usr/bin/[ true -a \( ! -a \) ] echo OK [EMAIL PROTECTED]:~$ This is unspecified by POSIX, but test(1) has its own documentation. If you prefer, the bash builtin breaks the compatibility with test(1) even if it is non-standard. Well, if fact, no need to use -a: [EMAIL PROTECTED]:~$ /usr/bin/[ \( ! -e \) ] echo OK [EMAIL PROTECTED]:~$ [ \( ! -e \) ] echo OK bash: [: `)' expected, found ] -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Aug 22, 2007, at 4:57 AM, Vincent Lefevre wrote: On 2007-08-21 09:55:46 -0700, David Brodbeck wrote: Linux is the only *nix-ish OS I've used where /bin/sh and bash are synonymous. ;) You probably haven't used it, but under Mac OS X too: prunille:~ uname -a Darwin prunille.vinc17.org 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh powerpc PowerMac7,3 Darwin prunille:~ sh --version GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.0) Copyright (C) 2002 Free Software Foundation, Inc. (This is the default, I didn't change anything.) Huh, sure enough. I actually do use MacOS X, but I never thought to check. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Aug 20, 2007, at 9:46 PM, Vincent Lefevre wrote: I suppose they have their own sh. Because bash is also under active development (and has broken scripts several times in the past). Yeah, FreeBSD ships its own, less featureful (but more compact!) version of sh, with bash available as a port. /bin/sh is used as the standard command interpreter. [EMAIL PROTECTED]:~$ ls -l /bin/sh -r-xr-xr-x 1 root wheel 105740 Jan 11 2007 /bin/sh* [EMAIL PROTECTED]:~$ ls -l /usr/local/bin/bash -rwxr-xr-x 2 root wheel 448996 Apr 18 16:27 /usr/local/bin/bash* Linux is the only *nix-ish OS I've used where /bin/sh and bash are synonymous. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python init (was: bash vs. python scripts - which one is better?)
On Aug 20, 2007, at 10:45 PM, Steve Lamb wrote: When it comes to Python in a role of system initialization there are some very simple things one can do that would dramatically increase load times. First off the pre-compiling of modules that Python does means subsequent boots would not have to go through that step. One could ship the distribution with those modules pre-compiled and only edits from that point out would be compiled on their first run. Hmmm... Now, that's a problem! During the early part of the boot process the root filesystem is read-only until it's been fsck'ed. There's no safe place to put the compiled modules. Not to mention that moving 10 MB of Python from /usr/bin and /usr/lib to /bin and /lib would increase the size of the root filesystem by 10%-20% on embedded systems -- where the size of things that must be in flash is a critical resource. Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Tue, Aug 21, 2007 at 09:55:46AM -0700, David Brodbeck wrote: On Aug 20, 2007, at 9:46 PM, Vincent Lefevre wrote: I suppose they have their own sh. Because bash is also under active development (and has broken scripts several times in the past). Yeah, FreeBSD ships its own, less featureful (but more compact!) version of sh, with bash available as a port. /bin/sh is used as the standard command interpreter. [EMAIL PROTECTED]:~$ ls -l /bin/sh -r-xr-xr-x 1 root wheel 105740 Jan 11 2007 /bin/sh* [EMAIL PROTECTED]:~$ ls -l /usr/local/bin/bash -rwxr-xr-x 2 root wheel 448996 Apr 18 16:27 /usr/local/bin/bash* Linux is the only *nix-ish OS I've used where /bin/sh and bash are synonymous. ;) This can be changed ;) ls -l /bin/sh lrwxrwxrwx 1 root root 9 2007-03-23 02:30 /bin/sh - /bin/dash Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: bash vs. python scripts - which one is better?
Vincent Lefevre wrote: Bob Proulx wrote: The test command was originally not a shell built-in. It was an external standalong /bin/test command. For performance reasons it has I don't think it is for performance reasons. Have you ever seen any noticeable performance gain? I don't think there would be much performance difference but I have not benchmarked it. However I accept that 20 years ago it was included for that reason and that it may have been significant then. vin:~ bash [EMAIL PROTECTED]:~$ touch exists [EMAIL PROTECTED]:~$ [ ! -a exists ] || echo found [EMAIL PROTECTED]:~$ /usr/bin/[ ! -a exists ] || echo found found You are running afoul of -a ambiguity. Stop that. Do you mean AND such as -a intends? Use -e if you want to test for simple file existence. However most of the time it is better to use -f or -r or -x or whatever you are actually testing for. I think that [ has been added as a builtin to the bash shell in order to add features... that break compatibility! Test was added to the shell well before bash came along. But better to use the one = so that it is portable. I prefer using an underscore to hide it more but 'X' is the tradition. if [ _$foo = _ ] I was talking traditional test style here. I break with tradition in my scripts and use _ instead of X so that they are lower profile. Are you sure that [ $foo = ] isn't POSIX sh? IMHO, it is perfectly valid (note: the quotes are important). POSIX defines this okay but as I was noting the traditional use was to use the X to prevent the old test from parsing it as an option. In the traditional environment this was not protected by the new POSIX requirement to count the number of program arguments provided. I still prefer to use -z and -n instead. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
David Brodbeck wrote: Vincent Lefevre wrote: I suppose they have their own sh. Because bash is also under active development (and has broken scripts several times in the past). Yeah, FreeBSD ships its own, less featureful (but more compact!) version of sh, with bash available as a port. /bin/sh is used as the standard command interpreter. And also because of the license. *BSD uses a BSD license and needs a /bin/sh that is compatible with it while Bash uses a GPL license which is not. This creates a problem for *BSD. Linux is the only *nix-ish OS I've used where /bin/sh and bash are synonymous. ;) Not synonymous, just the most prevalent from the distros. It can be changed and any bugs found in other packages that use bash features without properly calling bash reported. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Bob writes: Not synonymous, just the most prevalent from the distros. It can be changed and any bugs found in other packages that use bash features without properly calling bash reported. Note that when bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible while conforming to the POSIX standard. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python init (was: bash vs. python scripts - which one is better?)
On Tue, Aug 21, 2007 at 02:07:23PM -0400, Rick Thomas wrote: On Aug 20, 2007, at 10:45 PM, Steve Lamb wrote: When it comes to Python in a role of system initialization there are some very simple things one can do that would dramatically increase load times. First off the pre-compiling of modules that Python does means subsequent boots would not have to go through that step. One could ship the distribution with those modules pre-compiled and only edits from that point out would be compiled on their first run. Hmmm... Now, that's a problem! During the early part of the boot process the root filesystem is read-only until it's been fsck'ed. There's no safe place to put the compiled modules. You don't have to wait until the scripts run to compile the modules. A helper script could be provided to be run after any edit of the file(s) which would simply parse a list of modules to compile and just import them which automatically compiles them. If that script is shebanged with python -OO which would produce .pyo files instead of .pyc. For individual files, the person editing them could run python interactively and import it. Not to mention that moving 10 MB of Python from /usr/bin and /usr/lib to /bin and /lib would increase the size of the root filesystem by 10%-20% on embedded systems -- where the size of things that must be in flash is a critical resource. True. However, perhaps that 10 MB can be shrunk with some careful tweaking. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Hi Ron, On 8/20/07, Ron Johnson [EMAIL PROTECTED] wrote: Thanks for the links. You surely know how to find something. I find this much more comfortable than eg. typing: rx mp3conv.rexx 256kbps ~/mp3/work Even better: I run this script from within my dir util (DirOpus == Konqueror), so I don't have to type anything. Your geek cred just dropped. Substantially. Why, just tell me why? Because you want to point and click instead of run a script. (Even if it's easier, that doesn't matter.) That just ain't fair ;-) You completely ignored the fact that I wrote a complex script to accomplish a boring task. I think you should give me some creds for that. I propose just enough to return to the level I've been dropped from :- Greetings, Manon.
Re: bash vs. python scripts - which one is better?
Hi Bob, On 8/20/07, Bob Proulx [EMAIL PROTECTED] wrote: Thanks. I copied this to my 'Bash-howto'. I would hate to see you record this in your howto with == without knowing that == is a bash specific feature. :-) Well, actually it ain't that hard. I know from C that = assigns a value to a variable and == compares the value of that variable to something else. So I only have to remember not to use == in Bash and if I forget how to do it correct, than I check my 'Bash-howto'. Greetings, Manon.
Re: bash vs. python scripts - which one is better?
Hi Douglas, On 8/19/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: However, I don't understand the concept of compeletly controlling and editor from a script. Everything I can do by accessing a menu item or hitting some keys, I can do from within a script, and even more. I still haven't found any Linux editor as versatile as GoldEd. If I could, I wrote my own :-( Furthermore I have complete control over menu layout and keyboard shortcuts. I can put every menu item wherever I want and make it do whatever I want. I could even write my own menu, deleting all default settings. Same applies to keyboard shortcuts. Greetings, Manon.
Re: bash vs. python scripts - which one is better?
Hi Anthony, On 8/20/07, Anthony M Simonelli [EMAIL PROTECTED] wrote: How about Zenity? I've used it before to provide a GUI interface to some of my simple bash scripts. Thanks for the tip. Gonna check this out too. Greetings, Manon.
Re: bash vs. python scripts - which one is better?
On Aug 19, 2007, at 2:40 PM, Steve Lamb wrote: Besides, until operating systems start having init scripts written in Perl or Python, being able to write shell scripts is going to be an essential system administration skill. ;) Quite frankly they should now. Any time I've had to throw something into init scripts I've done it in Python. The last example was a script to determine whether my laptop was running Debian under VMWare or natively and if natively which dock it was plugged into. That was 7 years ago. :) I suspect they don't for two reasons -- one is that if you use bash, the system can boot without /usr, whereas if you use Python, /usr becomes critical to getting the system up. (Either that, or you'd have to move all the modules and libraries that Python depends on onto the root filesystem. Bash has relatively few dependencies.) The other is that the load time for bash is shorter. Everyone complains that their system boots too slowly as it is. ;) There are also maintenance issues with incorporating a complex language that's under active development as a critical part of an operating system. FreeBSD dropped Perl from their base system because base Perl became such a pain to maintain. They were essentially put in the position of having to fork Perl to maintain any sort of stable target, and that was more work than they wanted to take on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/07 11:39, Manon Metten wrote: Hi Ron, On 8/20/07, Ron Johnson [EMAIL PROTECTED] wrote: Thanks for the links. You surely know how to find something. I find this much more comfortable than eg. typing: rx mp3conv.rexx 256kbps ~/mp3/work Even better: I run this script from within my dir util (DirOpus == Konqueror), so I don't have to type anything. Your geek cred just dropped. Substantially. Why, just tell me why? Because you want to point and click instead of run a script. (Even if it's easier, that doesn't matter.) That just ain't fair ;-) You completely ignored the fact that I wrote a complex script to accomplish a boring task. I think you should give me some creds for that. I propose just enough to return to the level I've been dropped from Good point. You've got (most of) your geek cred back. ;) - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGyd2QS9HxQb37XmcRAoUmAJ9an6bp5Zg/UhHR/cA81iOHIoTMZACeP/Q9 wlS0EZ2tVKsC1mCPrT2fafM= =gLZ5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Sun, Aug 19, 2007 at 11:03:50PM -0500, Anthony M Simonelli wrote: On Sun, 2007-08-19 at 14:35 -0500, Ron Johnson wrote: Python + Tcl/Tk should be easier than Python + Gtk. Even simpler would be bash + dialog or it's GUI companion gtkdialog. How about Zenity? I've used it before to provide a GUI interface to some of my simple bash scripts. Here's my samples from my notes directory. There's one for curses and one that does a couple of ways of using dialog, the latter way uses a dialog module I wrote and include at the end. The module takes care of packing the strings that go to the dialog command line making the main program line clean and neat. Disclaimer: I've only used this a couple of times since most of my stuff uses normal text i/o. Doug. -- curses: #!/usr/bin/env python # from p 416 in python 2.1 bible. import curses try: MainWindow=curses.initscr() MainWindow.addstr(1,3, Hello, curses.A_BOLD | curses.A_UNDERLINE ) MainWindow.refresh() curses.echo() MainWindow.getch() finally: curses.endwin() Dialog: #!/usr/bin/python -O Tests the Dialog examples, in python, using different ways # Import statements import os import dialog # Constants DIALOG= /usr/bin/dialog # Definition of classes and functions # Main Function if (__name__==__main__): # message box Dialog_title=' --title Message Box' Dialog_options=' --clear' Dialog_box_options=' --msgbox' Dialog_text=' Hi, this is a simple message box. You can use this to' Dialog_text+=' display any message you like. The box will remain until' Dialog_text+=' you press the ENTER key.' Dialog_height=' 10' Dialog_width=' 41' Dialog_CMD=DIALOG + Dialog_title + Dialog_options + Dialog_box_options + Dialog_text Dialog_CMD+=Dialog_height + Dialog_width os.system(Dialog_CMD) #input box Dialog_CMD=DIALOG + ' --title InputBox --clear --inputbox \ Hi, this is an input dialog box. You can use this to ask questions \ that require the user to input a string as the answer. You can \ input strings longer than the width of the input box, in that case, the \ input field will be automatially scrolled. You can use BACKSPACE to \ correct errors.\ \ Try entering your name below: \ 16 51' #rc=os.system(Dialog_CMD) # rc is 0 since dialog exited OK. we need to see stderr #use os.popen (or if necesary popen4) w,rc=os.popen4(Dialog_CMD) del w print rc.read() del rc ## file selector doesn't work right ## now try dialog module hello=dialog.Dialog() # message box hello.title='--title Message Box ' hello.boxtype='--msgbox ' hello.text='Message box using dialog class ' hello.height='10 ' hello.width='41 ' w,r=os.popen4(hello.show()) print r.read() Here's the dialog module: #dialog.py Module wrapper for /usr/bin/dialog. See man page. Options for dialog are attributes of a dialog instance. e.g. instead of adding --title, do: obj.title=' --title This is the title ' Remember to include a trailing space in each attribute method pack() returns the complete dialog to run using: Dialog_CMD=dialog.show() w,r = os.popen4(Dialog_CMD) This allows access to stdin and stdout/stderr. Guage bars, for example, read from stdin until get EOF. class Dialog: Object version of Dialog: attributes same as Dialog's options def __init__(self): self.DIALOG = /usr/bin/dialog # common options self.aspect='' self.backtitle='' self.beep='' self.beepafter='' self.begin='' self.cancellabel='' self.clear='' self.crwrap='' self.defaultno='' self.defaultitem='' self.helpbutton='' self.helplabel='' self.itemhelp='' self.maxinput='' self.nokill='' self.nocancel='' self.noshadow='' self.oklabel='' self.printmaxsize='' self.printsize='' self.separateoutput='' self.separatewidget='' self.shadow='' self.sleep='' self.stdout='' self.tabcorrect='' self.tablen='' self.timeout='' self.title='' self.trim='' # box type and box options #this is only the type, e.g. obj.box_type='infobox' self.boxtype='' self.text='' self.height='' self.width='' self.boxoptions='' #this is other box
Python init (was: bash vs. python scripts - which one is better?)
David Brodbeck wrote: The other is that the load time for bash is shorter. Everyone complains that their system boots too slowly as it is. ;) Microscopically. On the other hand it has been my experience that it isn't the load time of bash that is the problem, it is the constant fork/exec to other applications to perform the work that is the problem. I haven't done it recently with Python but back when I was coding Perl professionally often the best optimization step I could make for shell was to rewrite into Perl just to cut out the thousands upon thousands of forks/exec that the shell scripts would perform to do simple tasks. When it comes to Python in a role of system initialization there are some very simple things one can do that would dramatically increase load times. First off the pre-compiling of modules that Python does means subsequent boots would not have to go through that step. One could ship the distribution with those modules pre-compiled and only edits from that point out would be compiled on their first run. Also the entire init structure only requires one load of Python and not dozens ala Bash. I often employ this simple technique when I want to build a script with discrete modules which I want to have run by simply having their presence in the directory: mods = os.listdir(moddir) for mod in mods: pathname = os.path.splitext(os.path.absdir(os.path.join(moddir, mod)))[0] inmod = __import__(pathname) inmod.main() That is a simplistic, non-ordered method of importing and running modules by just having them in the directory. The only requirement is that the module have a callable method called main(). By putting some simple sort logic in front of the for loop one can quickly and easily replicate the init logic as it is now and never once step out of a single instance of Python. There are also maintenance issues with incorporating a complex language that's under active development as a critical part of an operating system. FreeBSD dropped Perl from their base system because base Perl became such a pain to maintain. They were essentially put in the position of having to fork Perl to maintain any sort of stable target, and that was more work than they wanted to take on. But.. I thought nothing was ever dropped from Perl. . In all seriousness I can see that that could be an issue. I don't see it as insurmountable. Maybe the right method or mindset is not yet there? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-18 22:33:57 -0400, Douglas A. Tutty wrote: I guess a problem is the lack of definition of 'clean coding'. I don't consider one-liners as clean code. One-liners *can* be clean code. I have lots of very clean and readable one-liners in my Makefiles. Also, I like the following one (very useful): diff [EMAIL PROTECTED],-4] ([EMAIL PROTECTED] [EMAIL PROTECTED]) ([EMAIL PROTECTED] [EMAIL PROTECTED]) It may seem obfuscated, but it's quite clear once one knows the language. Probably more than if you wrote it in Python. Terse yes but they lack the visual flow that I need when I need to revamp code a year later. One-liners are more of a challenge to do in python since indentation has an impact on syntax. Yes, try including Python in Makefiles. :) -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-19 12:56:51 -0700, David Brodbeck wrote: It certainly has its warts. In particular, Bash's test (aka [) operator has pitfalls. Testing for an empty variable, for example, is awkward. If you do: if [ $foo == ] Bash will complain about missing arguments. Yes, bash sucks. See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421591 zsh has fewer problems. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-19 21:23:12 -0600, Bob Proulx wrote: Manon Metten wrote: David Brodbeck wrote: It certainly has its warts. In particular, Bash's test (aka [) operator has pitfalls. The test command was originally not a shell built-in. It was an external standalong /bin/test command. For performance reasons it has I don't think it is for performance reasons. Have you ever seen any noticeable performance gain? been incorporated into the shell but the interface can't change or it would break compatibility. Sure: vin:~ bash [EMAIL PROTECTED]:~$ touch exists [EMAIL PROTECTED]:~$ [ ! -a exists ] || echo found [EMAIL PROTECTED]:~$ /usr/bin/[ ! -a exists ] || echo found found [EMAIL PROTECTED]:~$ I think that [ has been added as a builtin to the bash shell in order to add features... that break compatibility! But better to use the one = so that it is portable. I prefer using an underscore to hide it more but 'X' is the tradition. if [ _$foo = _ ] Are you sure that [ $foo = ] isn't POSIX sh? IMHO, it is perfectly valid (note: the quotes are important). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-19 18:26:38 -0400, Douglas A. Tutty wrote: if [ $foo == ] Yeah, and the spaces between the [ $ and the ] are critical too; I just forget in what way. Yes, because of tokenization. But tokenization is a notion that exists in every language. Now, unlike in Python (with its indentation rules), the *amount* of space is not significant. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-20 10:38:32 -0700, David Brodbeck wrote: There are also maintenance issues with incorporating a complex language that's under active development as a critical part of an operating system. FreeBSD dropped Perl from their base system because base Perl became such a pain to maintain. They were essentially put in the position of having to fork Perl to maintain any sort of stable target, and that was more work than they wanted to take on. I suppose they have their own sh. Because bash is also under active development (and has broken scripts several times in the past). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python init (was: bash vs. python scripts - which one is better?)
On 2007-08-20 19:45:19 -0700, Steve Lamb wrote: There are also maintenance issues with incorporating a complex language that's under active development as a critical part of an operating system. FreeBSD dropped Perl from their base system because base Perl became such a pain to maintain. They were essentially put in the position of having to fork Perl to maintain any sort of stable target, and that was more work than they wanted to take on. But.. I thought nothing was ever dropped from Perl. . Nothing was dropped from Perl. It seems that the main problem concerning FreeBSD is that Perl was growing quite fast (e.g. more and more features, not needed in the FreeBSD base), and of course, installing an incomplete version of Perl would lead to problems. See http://kerneltrap.org/node/178. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-19 23:03:50 -0500, Anthony M Simonelli wrote: How about Zenity? I've used it before to provide a GUI interface to some of my simple bash scripts. It seems that the UI::Dialog Perl module allows to use the same interface to various dialog backends (including zenity). This is particularly useful if one cannot always use X (e.g. because of a remote connection by SSH or work on a PDA). I haven't tried it, though. But I think it should be interesting. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Hi Douglas, On 8/19/07, Douglas A. Tutty [EMAIL PROTECTED] almost wrote: Perhaps the OP can restate her needs and we can help her make a reasoned choice without it becoming a religious issue. OK. I have a hard time to remember all those command line options. So whenever I have to accomplish a task multiple times, I write a script for it in ARexx. Arexx is also capable of opening windows to request user input, eg. a window with some options. I could not find this possibility in Linux/Rexx. So I was looking for another language and found Python capable of doing so. Here's an example: I've written a script in ARexx for creating mp3 files. It has a couple of modes: Scale - 192kbps - 256kbps - Cancel. So when I run this script, it opens a small window with these four options and I just have to pick the one I need. Then it opens another window to select the directory where I have my .aiff files stored (it defaults to ~/mp3/work). I find this much more comfortable than eg. typing: rx mp3conv.rexx 256kbps ~/mp3/work Even better: I run this script from within my dir util (DirOpus == Konqueror), so I don't have to type anything. But I have a second question: Is there a programmable text editor available (with a nice GUI - not something like emacs where I have to remember all those ctrl+shift+left-alt+m commands) that I can completely control from within a Python script? Greetings, Manon.
Re: bash vs. python scripts - which one is better?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/07 14:12, Manon Metten wrote: [snip] Here's an example: I've written a script in ARexx for creating mp3 files. It has a couple of modes: Scale - 192kbps - 256kbps - Cancel. So when I run this script, it opens a small window with these four options and I just have to pick the one I need. Then it opens another window to select the directory where I have my .aiff files stored (it defaults to ~/mp3/work). Python + Tcl/Tk should be easier than Python + Gtk. Even simpler would be bash + dialog or it's GUI companion gtkdialog. I find this much more comfortable than eg. typing: rx mp3conv.rexx 256kbps ~/mp3/work Even better: I run this script from within my dir util (DirOpus == Konqueror), so I don't have to type anything. Your geek cred just dropped. Substantially. But that's ok. Really. Honestly, we won't snicker about you while sipping pretentious and outrageously expensive microbrew. I swear. But I have a second question: Is there a programmable text editor available (with a nice GUI - not something like emacs where I have to remember all those ctrl+shift+left-alt+m commands) that I can completely control from within a Python script? Complete control? I don't know. But gedit (sorry, a GNOME app) lets you access at least some of the window and editor. Greetings, Manon. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGyJuRS9HxQb37XmcRAtU3AJ9BtQZpWz5RN4v8WHCvdNG1m/LOowCbBtEf O7p+k+uAUOpxmzOWg5Ngz0A= =F7Mx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Hi Ron, On 8/19/07, Ron Johnson [EMAIL PROTECTED] wrote: Python + Tcl/Tk should be easier than Python + Gtk. Thanks. Even simpler would be bash + dialog or it's GUI companion gtkdialog. Could you mail me some examples you wrote, please? I find this much more comfortable than eg. typing: rx mp3conv.rexx 256kbps ~/mp3/work Even better: I run this script from within my dir util (DirOpus == Konqueror), so I don't have to type anything. Your geek cred just dropped. Substantially. Why, just tell me why? But that's ok. Really. Honestly, we won't snicker about you while sipping pretentious and outrageously expensive microbrew. I swear. Beware, Big Brother's watching you :-) Greetings, Manon.
Re: bash vs. python scripts - which one is better?
On Aug 18, 2007, at 12:20 PM, Douglas A. Tutty wrote: Also, I find that some of the bash constructs are cryptic by their nature with no clean work-arounds. They are likely perfectly clear to a proficient bash coder but the finer points are lost on me. It certainly has its warts. In particular, Bash's test (aka [) operator has pitfalls. Testing for an empty variable, for example, is awkward. If you do: if [ $foo == ] Bash will complain about missing arguments. Instead, you have to do something like this: if [ x$foo == x ] which works, but makes no sense the first time you see it. The file- testing features of test are quite powerful and extensive, though -- there are few languages where it's quite so easy to test conditions like, 'is this a directory?'. Bash is great if you need to glue together a bunch of existing utilities to do something. You can pipe output directly from one utility to another with an ease that doesn't exist in most other languages, which tend to make it complicated to launch other processes. Doing complex tasks with a series of simple utilities is sort of what Unix is all about. Besides, until operating systems start having init scripts written in Perl or Python, being able to write shell scripts is going to be an essential system administration skill. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Hi David, On 8/19/07, David Brodbeck [EMAIL PROTECTED] wrote: It certainly has its warts. In particular, Bash's test (aka [) operator has pitfalls. Testing for an empty variable, for example, is awkward. If you do: if [ $foo == ] Bash will complain about missing arguments. Instead, you have to do something like this: if [ x$foo == x ] which works, but makes no sense the first time you see it. The file- testing features of test are quite powerful and extensive, though -- there are few languages where it's quite so easy to test conditions like, 'is this a directory?'. Thanks. I copied this to my 'Bash-howto'. Greetings, Manon.
Re: bash vs. python scripts - which one is better?
On Sun, Aug 19, 2007 at 09:12:52PM +0200, Manon Metten wrote: But I have a second question: Is there a programmable text editor available (with a nice GUI - not something like emacs where I have to remember all those ctrl+shift+left-alt+m commands) that I can completely control from within a Python script? Hi Manon, I've never needed an editor widget (I've only written one non-curses app). What does the python IDLE use since it is written in python. wxPython probably has an editor widget that will work. My Python bible lists wxEditor and wxPyEditor, and more featured still is wxStyledTextCtrl. If you like KDE, you could look at the python-qt widget set. However, I don't understand the concept of compeletly controlling and editor from a script. Vim (and perhaps gVim) can probably do it but I don't know. I use vim so that I don't have to use emacs (poor memory from learning disability) but I don't do scripts. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
David Brodbeck wrote: In particular, Bash's test (aka [) operator has pitfalls. Testing for an empty variable, for example, is awkward. If you do: if [ $foo == ] Yeah, prefer: if not foo: do something -- there are few languages where it's quite so easy to test conditions like, 'is this a directory?'. Bash undoubtedly is more concise than this but I'd contend it is no easier. import os if os.path.isdir(somedir): print It's a dir, Jim! Bash is great if you need to glue together a bunch of existing utilities to do something. You can pipe output directly from one utility to another with an ease that doesn't exist in most other languages, which tend to make it complicated to launch other processes. Doing complex tasks with a series of simple utilities is sort of what Unix is all about. I contend that is more a was than an is. Shell filled a niche years ago that now has largely shrunk to special cases. So far in this thread there have been two example total of where a shell script might be better for more than 2 minutes over a proper scripting language. Generally by the time any shell script starts piping 2-3 things I just convert it to Python and get it done far easier and far faster. Mainly because I don't have to jump through the hoops the warts above present. Besides, until operating systems start having init scripts written in Perl or Python, being able to write shell scripts is going to be an essential system administration skill. ;) Quite frankly they should now. Any time I've had to throw something into init scripts I've done it in Python. The last example was a script to determine whether my laptop was running Debian under VMWare or natively and if natively which dock it was plugged into. That was 7 years ago. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Sun, Aug 19, 2007 at 02:40:19PM -0700, Steve Lamb wrote:
David Brodbeck wrote:
In particular, Bash's test (aka [)
operator has pitfalls. Testing for an empty variable, for example, is
awkward. If you do:
if [ $foo == ]
Yeah, and the spaces between the [ $ and the ] are critical too; I
just forget in what way.
Yeah, prefer:
if not foo:
do something
-- there are few languages where it's quite so easy to test conditions
like, 'is this a directory?'.
Bash undoubtedly is more concise than this but I'd contend it is no
easier.
import os
if os.path.isdir(somedir):
print It's a dir, Jim!
Best of all, at 2:00 a.m. a year from now, its perfectly clear what
if os.path.isdir(somedir):
means.
Bash is great if you need to glue together a bunch of existing utilities
to do something. You can pipe output directly from one utility to
another with an ease that doesn't exist in most other languages, which
tend to make it complicated to launch other processes. Doing complex
tasks with a series of simple utilities is sort of what Unix is all about.
Right, but debugging a long piece of plumbing can take a while.
I contend that is more a was than an is. Shell filled a niche years
ago that now has largely shrunk to special cases. So far in this thread
there have been two example total of where a shell script might be better
for more than 2 minutes over a proper scripting language. Generally by the
time any shell script starts piping 2-3 things I just convert it to Python
and get it done far easier and far faster. Mainly because I don't have to
jump through the hoops the warts above present.
Besides, until operating systems start having init scripts written in
Perl or Python, being able to write shell scripts is going to be an
essential system administration skill. ;)
Anything after /usr is mounted (perhaps runlevel 2) could be in python.
The init scripts for rcS.d should be carefully written to be
understandable by non-bash gurus.
Check out the very first initscript, S01glibc.sh (exerpts below). It
may as well be written in assembler for all I can understand how it
compares kernel versions.
Doug.
if [ `uname -s` = Linux ]; then
# glibc kernel version check: KERNEL_VERSION_CHECK
kernel_compare_versions () {
verA=$(($(echo $1 | sed 's/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \*
1 + \2 \* 100 + \3/')))
verB=$(($(echo $3 | sed 's/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \*
1 + \2 \* 100 + \3/')))
test $verA -$2 $verB
}
exit_check () {
sleep 5
exit 1
}
# Test to make sure z 255, in x.y.z-n form of kernel version
# Also make sure we don't trip on x.y.zFOO-n form
#kernel_rev=$(uname -r | tr -- - . | cut -d. -f3 | tr -d '[:alpha:]')
kernel_rev=$(uname -r | sed 's/\([0-9]*\.[0-9]*\.\)\([0-9]*\)\(.*\)/\2/')
if [ $kernel_rev -ge 255 ]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/07 14:48, Manon Metten wrote: Hi Ron, On 8/19/07, Ron Johnson [EMAIL PROTECTED] wrote: Python + Tcl/Tk should be easier than Python + Gtk. Thanks. Even simpler would be bash + dialog or it's GUI companion gtkdialog. Could you mail me some examples you wrote, please? I've never had to write any. Google lists a lot of examples and tutorials, though. Here are some that I quickly found by searching for linux+dialog+command. http://www.linuxjournal.com/article/2460 http://www.freeos.com/guides/lsst/ http://www.freeos.com/guides/lsst/ch04sec6.html http://www.freeos.com/guides/lsst/ch04sec7.html https://cepserver.tce.edu/pipermail/glugot/2005-August/000393.html http://www.linux.com/articles/55389 http://ayaz.wordpress.com/2006/08/15/dialog-using-dialog-boxes-to-interact-with-users-on-a-linux-console/ I find this much more comfortable than eg. typing: rx mp3conv.rexx 256kbps ~/mp3/work Even better: I run this script from within my dir util (DirOpus == Konqueror), so I don't have to type anything. Your geek cred just dropped. Substantially. Why, just tell me why? Because you want to point and click instead of run a script. (Even if it's easier, that doesn't matter.) But that's ok. Really. Honestly, we won't snicker about you while sipping pretentious and outrageously expensive microbrew. I swear. Beware, Big Brother's watching you :-) :) - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGyMWVS9HxQb37XmcRAijVAJ97+/n8kGleOMFE0SWiNIqFqqxtnACgluDQ 0vRNq0UiTT1pra/i576O3fQ= =Kmkr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Manon Metten wrote:
David Brodbeck wrote:
It certainly has its warts. In particular, Bash's test (aka [)
operator has pitfalls.
The test command was originally not a shell built-in. It was an
external standalong /bin/test command. For performance reasons it has
been incorporated into the shell but the interface can't change or it
would break compatibility. That is a core reason why the shell single
bracket test operator has warts and why the new double bracket test
operator was created.
Testing for an empty variable, for example,
is awkward. If you do:
if [ $foo == ]
Bash will complain about missing arguments.
Careful! == is valid bash but is not valid POSIX sh. In Bash the
double equal can be used as a synonym for the single equal but not in
POSIX shell.
Instead, you have to do something like this:
if [ x$foo == x ]
But better to use the one = so that it is portable. I prefer using an
underscore to hide it more but 'X' is the tradition.
if [ _$foo = _ ]
which works, but makes no sense the first time you see it.
Right. I prefer using the test -n or -z options. This is effectively
an external command so still needs to be quoted though. But I find
this much more clear on casual reading.
if [ -z $foo ]
Use double brackets to get the new internal to the shell test not
needing quoting.
if [[ -z $foo ]]
However this does not actually say if the variable is set but only if
it is zero length. If it is important if the variable is set but set
to an empty string then things get more obscure.
if [[ ${foo+set} != set ]]; then echo foo is not set; fi
Thanks. I copied this to my 'Bash-howto'.
I would hate to see you record this in your howto with == without
knowing that == is a bash specific feature. :-)
Bob
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Sun, 2007-08-19 at 14:35 -0500, Ron Johnson wrote: Python + Tcl/Tk should be easier than Python + Gtk. Even simpler would be bash + dialog or it's GUI companion gtkdialog. How about Zenity? I've used it before to provide a GUI interface to some of my simple bash scripts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Hi Steve, Thanks for sharing your valuable experience. I've decided to first become more familiar with Bash and then I'll give Python a try. If it don't like it, I can always try something else. But ATM I think Python will be the best option. I've seen some code on the net that looks pretty clean and some examples that enable me to achieve what I want. Manon.
Re: bash vs. python scripts - which one is better?
On Sat, Aug 18, 2007 at 08:52:45PM +0200, Manon Metten wrote: Thanks for sharing your valuable experience. I've decided to first become more familiar with Bash and then I'll give Python a try. If it don't like it, I can always try something else. But ATM I think Python will be the best option. I've seen some code on the net that looks pretty clean and some examples that enable me to achieve what I want. I think you've hit the nail on the head. While the coding of both bash and pyhthon _can_ be made clear, bash allows some cryptic short-cuts that are rather common whereas python enforces clean coding. Also, I find that some of the bash constructs are cryptic by their nature with no clean work-arounds. They are likely perfectly clear to a proficient bash coder but the finer points are lost on me. In short, I use bash for things like dos .bat files; a sequential list of commands. Once something requires looping or decisions, I go straight for python. To complete the sequence, if python is too slow at something, I recode the relevant functions in Fortran. I did that a lot on my 486 but never on my Athlon64. :) Doug -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/18/07 14:20, Douglas A. Tutty wrote: On Sat, Aug 18, 2007 at 08:52:45PM +0200, Manon Metten wrote: Thanks for sharing your valuable experience. I've decided to first become more familiar with Bash and then I'll give Python a try. If it don't like it, I can always try something else. But ATM I think Python will be the best option. I've seen some code on the net that looks pretty clean and some examples that enable me to achieve what I want. I think you've hit the nail on the head. While the coding of both bash and pyhthon _can_ be made clear, bash allows some cryptic short-cuts that are rather common whereas python enforces clean coding. Also, I Eh. I've written enough cryptic Python and lucid C bash to know that Python does *not* enforce clean coding. Maybe Ada does, but I doubt it. find that some of the bash constructs are cryptic by their nature with no clean work-arounds. They are likely perfectly clear to a proficient bash coder but the finer points are lost on me. In short, I use bash for things like dos .bat files; a sequential list of commands. Once something requires looping or decisions, I go straight for python. To complete the sequence, if python is too slow at What a waste. bash is *great* for looping thru lists. (Perfect? No. But still great.) something, I recode the relevant functions in Fortran. I did that a lot on my 486 but never on my Athlon64. :) - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGx3N8S9HxQb37XmcRAsALAKDJ+zR3/7+otHe6p3w62XC+Qa/3rwCfWmsU gaYdAd+LayYcoAZCsJVjM1s= =SiDQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Ron Johnson wrote: I've written enough cryptic Python and lucid C bash to know that Python does *not* enforce clean coding. I don't think anyone has ever claimed that. What a waste. bash is *great* for looping thru lists. (Perfect? No. But still great.) So is Python with the added benefit of not having to defeat globbing at every step of the way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Aug 18, 2007, at 5:28 PM, Steve Lamb wrote: Ron Johnson wrote: I've written enough cryptic Python and lucid C bash to know that Python does *not* enforce clean coding. I don't think anyone has ever claimed that. What a waste. bash is *great* for looping thru lists. (Perfect? No. But still great.) So is Python with the added benefit of not having to defeat globbing at every step of the way. Is this discussion REALLY still going on? Use whatever you like. As I said in my original reply to the question. LOL! Back and forth, back and forth, a program could have been written in both languages by now to do whatever anyone wanted. -- Nate Duehr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/18/07 18:28, Steve Lamb wrote: Ron Johnson wrote: I've written enough cryptic Python and lucid C bash to know that Python does *not* enforce clean coding. I don't think anyone has ever claimed that. Doug Tutty did this afternoon. (You conveniently snipped that part out of your reply.) http://lists.debian.org/debian-user/2007/08/msg01743.html whereas python enforces clean coding. What a waste. bash is *great* for looping thru lists. (Perfect? No. But still great.) So is Python with the added benefit of not having to defeat globbing at every step of the way. Sure, not having to worry about globbing rules can be handy. But there's still a large set of problems that can quickly be solved by a one-line bash for/done loop. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGx50cS9HxQb37XmcRAqpsAKCnNE49IWQZYEchgLvWmgH8pN5YnwCdF46l roC7LT7bwk7Gs/1HZjffKvc= =KP+R -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Sat, Aug 18, 2007 at 08:30:04PM -0500, Ron Johnson wrote: On 08/18/07 18:28, Steve Lamb wrote: Ron Johnson wrote: I've written enough cryptic Python and lucid C bash to know that Python does *not* enforce clean coding. I don't think anyone has ever claimed that. Doug Tutty did this afternoon. (You conveniently snipped that part out of your reply.) http://lists.debian.org/debian-user/2007/08/msg01743.html whereas python enforces clean coding. What a waste. bash is *great* for looping thru lists. (Perfect? No. But still great.) So is Python with the added benefit of not having to defeat globbing at every step of the way. Sure, not having to worry about globbing rules can be handy. But there's still a large set of problems that can quickly be solved by a one-line bash for/done loop. I guess a problem is the lack of definition of 'clean coding'. I don't consider one-liners as clean code. Terse yes but they lack the visual flow that I need when I need to revamp code a year later. One-liners are more of a challenge to do in python since indentation has an impact on syntax. As for which language is best, the answer is none. Any language can probably do anything, but for any problem one may be easier than another. It will likely be the one you are more generally good at. I find sh to be more cryptic than python so I turn to it sooner, which leads over time to me becoming more and more comfortable with python. So for problems that are best solved with some disposable code, it comes down to in which language in which you produce functional code the fastest and easiest. Perhaps the OP can restate his needs and we can help him make a reasoned choice without it becoming a religious issue. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/18/07 21:33, Douglas A. Tutty wrote: [snip] I guess a problem is the lack of definition of 'clean coding'. I don't consider one-liners as clean code. Terse yes but they lack the visual flow that I need when I need to revamp code a year later. One-liners are more of a challenge to do in python since indentation has an impact on syntax. As for which language is best, the answer is none. Any language can probably do anything, but for any problem one may be easier than another. It will likely be the one you are more generally good at. I find sh to be more cryptic than python so I turn to it sooner, which leads over time to me becoming more and more comfortable with python. So for problems that are best solved with some disposable code, it comes down to in which language in which you produce functional code the fastest and easiest. While I write lots of bash code, I don't have lots of .sh files hanging around $HOME, but there are lots of .py files. Anything I *know* is one-off I try to do in bash (usually making my xterm very wide!), whereas stuff that I'll be doing repetitively (even if not frequently) gets written in python. Perhaps the OP can restate his needs and we can help him make a reasoned choice without it becoming a religious issue. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGx66QS9HxQb37XmcRAlOZAJ4ryFWnomJ2k9797gBuCGqW9mN1LQCcDsLk TF4aIgaKZb+9mE+gPpQOcEE= =HzxP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Tue, Aug 14, 2007 at 09:17:46AM -0700, Bob McGowan wrote: Steven R. wrote: On Tue, Aug 07, 2007 at 04:03:05PM -0700, Andrew Sackville-West wrote: So what's the right way to do this? I hacked one together the other day: IFS=$'\t\n'; for i in `find . -iname \*m4a`; do faad... blah blah blah and I knew it was a hack because setting $IFS just seems bad... possible unintended consquences, but it worked. I have seen something like the following: find | while read FILE; do echo $FILE done I missed the original postings (on vacation;). But, regarding IFS, a couple of notes: 1. In The UNIX Programming Environment, Kernighan and Pike, this variable is used without any caveats, in several of the example scripts. 2. In all cases, the idiom used is: ifs=$IFS IFS='' # whatever you need for your particular problem. ...# your code IFS=$ifs ...# any other processing that needs to be done This guarantees that the original value, whatever it is, is restored and used for normal processing. I guess there's nothing really wrong with mucking about with IFS. It certainly made it easy to do what I needed to do, and I guess that's a good thing. The problem I see though is that its not clear what it does. Starting a script, or even a block within a script, by changing IFS is cryptic at best. I've always felt and been taught to avoid using side effects and I think this definitely falls into this category because it is not clear from reading the code that changing IFS does anything. ANd if you are reading through some code and pull out some looping structure to use for some other purpose and don't know to grab the changed IFS as well, then the code will behave in a different and possibly unpredictable manner. THere was a protracted thread a while back on dealing with spaces in file names and such... I really should go back and read it. A signature.asc Description: Digital signature
Re: bash vs. python scripts - which one is better?
On Sat, 11 Aug 2007 00:52:18 - BartlebyScrivener [EMAIL PROTECTED] wrote: from http://docs.python.org/tut/node3.html If you're a professional software developer, you may have to work with several C/C++/Java libraries but find the usual write/compile/test/re- compile cycle is too slow. This I don't understand. My cycle goes like this: Muck around in source code, flick to xterm, press Up Enter and see the result. The Up of course just invokes the last command which is always either ./script or make ./program. For not-too-big C programs (say, a couple k lines) the make step doesn't take up appreciable time, so the write/test cycle is pretty much equally fast for script and C programs (C++ is a lot slower because the system includes are huge, and maybe the compiling process itself is more complex.) So, no, for small to medium programs the development cycle of a compiled language (at least of C) isn't necessarily slower than that of a scripted (interpreted) language. --D. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Tue, Aug 07, 2007 at 04:03:05PM -0700, Andrew Sackville-West wrote: So what's the right way to do this? I hacked one together the other day: IFS=$'\t\n'; for i in `find . -iname \*m4a`; do faad... blah blah blah and I knew it was a hack because setting $IFS just seems bad... possible unintended consquences, but it worked. I have seen something like the following: find | while read FILE; do echo $FILE done -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-13 14:40:57 -0700, David Brodbeck wrote: On Aug 13, 2007, at 11:31 AM, Vincent Lefevre wrote: There's a big difference: GCC is useless for the end user. And I don't think that old GCC versions are really necessary. They are if you need to compile old software. Some stuff just won't build with newer GCC versions. But 1. Such software is not from Debian. 2. Such software probably uses non-standard features, in which case this is not GCC's fault or the fault of the C language. FYI, GCC 4 still supports KR (pre-standard) C constructs (-traditional and -traditional-cpp options) and trigraphs (-trigraphs option). 3. You do not need GCC at run time: you can install old GCC versions on some machine compile old software there, and use it on other machines, even those that don't have enough disk space for GCC. Also, your end users are clearly different than mine. My users compile stuff pretty frequently, often crusty old software used by some research project or other. I also compile things frequently, even not recent software, but I have never had any problem with GCC 4.x (except bugs, of course, but they end up in being fixed, and every software has bugs anyway). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-14 09:32:44 -0400, Steven R. wrote: On Tue, Aug 07, 2007 at 04:03:05PM -0700, Andrew Sackville-West wrote: So what's the right way to do this? I hacked one together the other day: IFS=$'\t\n'; for i in `find . -iname \*m4a`; do faad... blah blah blah and I knew it was a hack because setting $IFS just seems bad... possible unintended consquences, but it worked. I have seen something like the following: find | while read FILE; do echo $FILE done which is almost as bad, as filenames can have \n characters in them. That's why find has -print0... Unfortunately the read builtin doesn't seem to support this feature (or anyone knows how to use its -d option to declare \0 as the delimiter?). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Hi, personally I'd say they both equally powerfull in general (I think both a touring complete which makes them both full grown programming languages - correct me if i'm wrong) depending on the job i use one over the other. If it would be a python script only spawning OS processes it might be a lot easier with bash. on the other hand if there's number/string parsing involved i can do a lot better with python YMMV. /martin On 8/14/07, Vincent Lefevre [EMAIL PROTECTED] wrote: On 2007-08-14 09:32:44 -0400, Steven R. wrote: On Tue, Aug 07, 2007 at 04:03:05PM -0700, Andrew Sackville-West wrote: So what's the right way to do this? I hacked one together the other day: IFS=$'\t\n'; for i in `find . -iname \*m4a`; do faad... blah blah blah and I knew it was a hack because setting $IFS just seems bad... possible unintended consquences, but it worked. I have seen something like the following: find | while read FILE; do echo $FILE done which is almost as bad, as filenames can have \n characters in them. That's why find has -print0... Unfortunately the read builtin doesn't seem to support this feature (or anyone knows how to use its -d option to declare \0 as the delimiter?). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Martin Marcher [EMAIL PROTECTED] http://www.mycorners.com https://www.xing.com/profile/Martin_Marcher http://www.linkedin.com/in/martinmarcher http://www.studivz.net/profile.php?ids=9f83ea8c5996b8ec http://www.amazon.de/gp/registry/wishlist/3KDAGCL2NKOIM/ref=reg_hu-wl_goto-registry/302-4432803-5146435?ie=UTF8sort=date-added
Re: bash vs. python scripts - which one is better?
Steven R. wrote: On Tue, Aug 07, 2007 at 04:03:05PM -0700, Andrew Sackville-West wrote: So what's the right way to do this? I hacked one together the other day: IFS=$'\t\n'; for i in `find . -iname \*m4a`; do faad... blah blah blah and I knew it was a hack because setting $IFS just seems bad... possible unintended consquences, but it worked. I have seen something like the following: find | while read FILE; do echo $FILE done I missed the original postings (on vacation;). But, regarding IFS, a couple of notes: 1. In The UNIX Programming Environment, Kernighan and Pike, this variable is used without any caveats, in several of the example scripts. 2. In all cases, the idiom used is: ifs=$IFS IFS='' # whatever you need for your particular problem. ...# your code IFS=$ifs ...# any other processing that needs to be done This guarantees that the original value, whatever it is, is restored and used for normal processing. -- Bob McGowan smime.p7s Description: S/MIME Cryptographic Signature
Re: bash vs. python scripts - which one is better?
On Aug 11, 2007, at 12:09 PM, Vincent Lefevre wrote: Concerning python, one still has 5 different versions (python2.1, python2.2, python2.3, python2.4, python2.5) in currently supported Debian versions! Yeah, and old GCC versions have to be kept around, too, for similar reasons. It's annoying but not impossible to deal with. I admit I was a bit startled when Python apparently changed module formats between two *minor* release numbers, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-13 09:18:46 -0700, David Brodbeck wrote: On Aug 11, 2007, at 12:09 PM, Vincent Lefevre wrote: Concerning python, one still has 5 different versions (python2.1, python2.2, python2.3, python2.4, python2.5) in currently supported Debian versions! Yeah, and old GCC versions have to be kept around, too, for similar reasons. There's a big difference: GCC is useless for the end user. And I don't think that old GCC versions are really necessary. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Aug 13, 2007, at 11:31 AM, Vincent Lefevre wrote: There's a big difference: GCC is useless for the end user. And I don't think that old GCC versions are really necessary. They are if you need to compile old software. Some stuff just won't build with newer GCC versions. Also, your end users are clearly different than mine. My users compile stuff pretty frequently, often crusty old software used by some research project or other. One of my systems has four versions of GCC installed, but that's probably overkill; one from each major version (2.x, 3.x, and 4.x) would probably be sufficient. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Vincent Lefevre wrote: On 2007-08-11 11:34:48 -0700, Steve Lamb wrote: Really? Tell that to the Perl 4 programmers. Perl 4 is obsolete and no longer used, and has complete disappeared from Debian a long time ago. I'm not the one who used Never. Concerning python, one still has 5 different versions (python2.1, python2.2, python2.3, python2.4, python2.5) in currently supported Debian versions! And yet my main reference book is for version 1.5.2 without problems. The only difference is that when I finally got around to using the documents that came with the distribution (ahhh, 2 monitors, finally) I learned a lot of new ways to do things. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Vincent Lefevre wrote: Imagine a filename contains: ' `some command` Yes, because you get: echo '' `ls -l`' I get? *I* get? Pst, look up above. *YOU* decided say Imagine a filename contains: ' `some command` Quoted right there. which is not valid. Try with: So now you're modifying what you wrote, tsk, tsk. Which is why I strayed away from Perl into Python land. This is a very subjective argument. One *can* write readable Perl scripts. Also remember TIMTOWTDI. One can, yes. And I remember TIMTOWTDI which is the antithesis of writing readable code. I was hip deep in Perl code for several years. I found that the only way to write readable Perl was to throw half of the language out and stick to a strict subset of the language so as to be consistent. Nope. The first thing I do when I get an account is to install a recent version of zsh, so that zsh is always installed, but not necessarily python! :) Love to see you do that on a restricted gaming box. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-11 00:44:17 -0700, Steve Lamb wrote: Vincent Lefevre wrote: Imagine a filename contains: ' `some command` Yes, because you get: echo '' `ls -l`' I get? *I* get? Pst, look up above. *YOU* decided say Imagine a filename contains: ' `some command` Quoted right there. I said contains, not is. You should get a dictionary. which is not valid. Try with: So now you're modifying what you wrote, tsk, tsk. No, I've given a filename that *contains* ' `some command`. Which is why I strayed away from Perl into Python land. This is a very subjective argument. One *can* write readable Perl scripts. Also remember TIMTOWTDI. One can, yes. And I remember TIMTOWTDI which is the antithesis of writing readable code. No, it's up to the programmer to write readable code. I was hip deep in Perl code for several years. I found that the only way to write readable Perl was to throw half of the language out and stick to a strict subset of the language so as to be consistent. A part of the language is a bit obsolete. Some features are deprecated (but can be useful for some one-liners). Unlike Python, nothing is removed from Perl, so that old Perl scripts can still run and there is no need for N versions on the disk. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/10/07 23:43, Stefan Monnier wrote: Haskell defines TABs as being 8 spaces apart and I expect Python to do the same. Python should do it because Haskell does it?? Not because Haskell is so influential, but because the same causes tend to result in the same effects. I didn't notice this before, but should have: Hard-coded definition of ^I? That's... that's... stunning. (BTW, Python has tabnanny and string.expandtabs() to assist people with mismatching tab issues.) - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGveskS9HxQb37XmcRAmdXAKDN6Q4WocYb2ceubkDVqkm755FFcgCeOKne U6A9oCzfTQpLPEh/UF8blbY= =mZZO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Vincent Lefevre wrote: A part of the language is a bit obsolete. Some features are deprecated (but can be useful for some one-liners). Unlike Python, nothing is removed from Perl, so that old Perl scripts can still run and there is no need for N versions on the disk. Really? Tell that to the Perl 4 programmers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-11 11:34:48 -0700, Steve Lamb wrote: Really? Tell that to the Perl 4 programmers. Perl 4 is obsolete and no longer used, and has complete disappeared from Debian a long time ago. Perl 5 has been there since 13 years (about the same time python 1.0 was released). Concerning python, one still has 5 different versions (python2.1, python2.2, python2.3, python2.4, python2.5) in currently supported Debian versions! -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Saturday 11 August 2007, Vincent Lefevre wrote: On 2007-08-11 11:34:48 -0700, Steve Lamb wrote: Really? Tell that to the Perl 4 programmers. Perl 4 is obsolete and no longer used, and has complete disappeared from Debian a long time ago. Perl 5 has been there since 13 years (about the same time python 1.0 was released). Concerning python, one still has 5 different versions (python2.1, python2.2, python2.3, python2.4, python2.5) in currently supported Debian versions! Oh well. Fundamental stuff hasn't changed much, and the only things that have gotten changed have been warned about for quite awhile. Not a big deal, ESPECIALLY since this started as a beginner conversation. He wouldn't *possibly* run into any of these issues. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Vincent Lefevre wrote:
Not every system has bash. If this is for compatibility, you can learn
POSIX sh, but e.g. Solaris /bin/sh is not a POSIX sh. For this reason
and because POSIX sh is limited (you can't execute a command and have
a timeout on it),
Here is a method for doing a timeout. I'm not arguing against
the claim that sh is limited, nor am I claiming that the method
presented here is robust (it doesn't work well if the function
has already completed, for example), but this certainly demonstrates
that it is possible to execute a command with a timeout.
#!/bin/sh
# A function which never completes.
foo() {
echo Never returns! $$
while true; do
sleep 1;
done
}
# Execute the commands with the specified timeout.
timeout() {
local timeout=$1
shift
local cmd=$@
echo $cmd
$cmd
sleep $timeout
kill %%
}
# Execute foo, but terminate it after 1 second.
timeout 1 foo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-12 00:57:22 +0100, William Pursell wrote: Here is a method for doing a timeout. I'm not arguing against the claim that sh is limited, nor am I claiming that the method presented here is robust (it doesn't work well if the function has already completed, for example), but this certainly demonstrates that it is possible to execute a command with a timeout. [...] The timeout function keeps waiting even after the command has completed (when it has completed before the timeout, which is the normal case), and this is a real efficiency problem. Of course, I think that one can replace your sleep $timeout by a loop that would poll every second, but this is rather inelegant and possibly inefficient. Moreover, there is a possible race condition; I suppose that this can also be solved by trapping SIGCHLD. Also, if one wants to interrupt the script by Ctrl-C for instance, this doesn't work well (the command is not killed). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Vincent Lefevre wrote: Braces are not a problem: they are kept in a copy-paste, and if for some reason a brace is missing (because you did a mistake), then you'll get a syntax error Unless, of course, you are programming in C with that pesky... if foo; bar; ...problem. In Python, you may need to re-indent (correctly!) all what you've copy-pasted, and if you forget an indentation, the syntax will still be valid. Which is not that hard. Have you done it? Doubt it. I have, many times. Say I'm 3 levels deep and paste something 2 levels deep. Like this: for foo in bar: if foo 200: print baz else: print spam First off, that's an error in Python. Don't believe me? if '1': ... if '2': ... for foo in bar: ... if foo 200: File stdin, line 4 if foo 200: ^ IndentationError: unindent does not match any outer indentation level Secondly, as I stated earlier, any programmer's editor will be able to indent by blocks. I know vim and idle can, pretty sure emacs can as well for those of that sect. So you mark the four lines and indent twice. Viola, you have a working script! The secret is that while the block may not match the indentation of your code it pretty much will be consistent to itself. If it isn't you have far more problems than a simple block alignment. Also, as I said, would you really trust someone who doesn't reindent their code so they can read it even if they are cut and pasting code with braces? In languages like Perl, the indentation can automatically be done by the editor (and checked by the developer in real time), and after a copy-paste, the indentation can be fixed automatically, without any ambiguity. Presumed ambiguity. There is no ambiguity here. The code runs as it is indented, not how the computer sees it vs. how the human reads it. If you need to paste code from web pages (that could be mailing-list archives, for instance), whitespace can have already changed by generic tools. Still not a problem. Like I said, I've been doing this for years and so far the gains from significant whitespace have far outstripped the exceedingly rare times it ever was a problem for me. I chose that phrasing because I feel like it must have been a problem at least once but can't recall a single time. It is that insignificant. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Vincent Lefevre wrote: On 2007-08-09 09:48:54 -0700, Steve Lamb wrote: The same in Python but with far greater functionality: and a security hole! And the one liner stopped this how, exactly? I mean it was globbing the file fer pete's sake! result = os.system(lame -h -b 160 '%s' '%s' % (file, mp3)) Imagine a filename contains: ' `some command` Ok, I'll imagine that. import os foo = ' `ls -l` os.system(echo '%s' % foo) sh: -c: line 0: unexpected EOF while looking for matching `'' sh: -c: line 1: syntax error: unexpected end of file 512 But of course this is a red herring on your part because we're starting this discussion from the point of wanting to do a process to files we, presumably, have vetted. But remember that when you use system (available in many languages), this is a shell that will be started behind, with all the problems of a shell. Yes, which is why I tend to go native as much as possible. A feat far easier in Python than Shell. :P In Perl, when one calls system with more than one element in the list, this calls execvp instead of doing a conventional system. Now, I assume that Python also has some way to call execvp. http://python.active-venture.com/lib/os-process.html In portable POSIX sh, yes. But with superior shells such as zsh, this is trivial. However, for complex transformations, though this can often be written with few characters, this is completely unreadable! (See for instance, the advanced zsh completion functions.) Which is why I strayed away from Perl into Python land. And while zsh is fairly ubiquitous in Linux/BSD land it is still shell with the problems that come with it. BTW, in case you feel I am coming from Bash land with my anti-shell sentiments... [EMAIL PROTECTED]:~} grep grey /etc/passwd grey:x:1000:1007:Steve Lamb:/home/grey:/bin/zsh ...been on zsh for years. I love its far superior completion and command history. Won't code in it, however, not as long as #!/bin/env python is around. And the joy of it is that if a box has zsh chances are high it'll have python, too. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Nate Duehr wrote: Steve Lamb wrote: Quick, take your one liner, have it traverse an entire directory tree converting all the wavs (regardless of capitalization) to mp3s, oggs and flac, sorting all 4 into their own directory trees. To make your point, you'd need to do all of the above in one line of Python code. What a fanboi... Quick, write a one-liner while I take 20 minutes to write a real program! Uh, no, fanboi. I never said it had to remain a one liner. In fact, that was my point. One liners rarely stay that way. And when you venture past your very narrow mindset you find the problems in shell. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/10/07 09:18, s. keeling wrote: Ron Johnson [EMAIL PROTECTED]: Just remember to tell you editor to inserts spaces as tab and set the tab width to something reasonable like 4. E, yuck! It's code like that which makes me happy for emacs: C-x h# mark entire buffer M-x untabify # replace tab chars with spaces I despise tabs. EVE does something similar: DO CONV TAB - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGvIncS9HxQb37XmcRAklwAJ46MPVRWpkA3NUWcpmKzYEm3yxZJwCeK0AL I9EGZ+OhX97E5wmKd0PFl14= =o+Ci -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
ss11223 [EMAIL PROTECTED]: On Aug 10, 10:30 am, s. keeling [EMAIL PROTECTED] wrote: Ron Johnson [EMAIL PROTECTED]: Just remember to tell you editor to inserts spaces as tab and set the tab width to something reasonable like 4. E, yuck! It's code like that which makes me happy for emacs: C-x h# mark entire buffer M-x untabify # replace tab chars with spaces Check out the expand command. It's easier to script when you need to do some directories full of files. Absolutely. I created a jaw-dropping moment for a manager and about fifteen developers with that one once. They thought they were going to have to spend the next two weeks cleaning up SQL code that had been maintained for years by various people using various editors, some of which used tabs and others not. I fixed it for them with an expand one liner. Hear me roar, or yodel like Tarzan. :-) -- Any technology distinguishable from magic is insufficiently advanced. (*)http://blinkynet.net/comp/uip5.html Linux Counter #80292 - -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Aug 10, 2007, at 12:19 AM, Steve Lamb wrote: Uh, no, fanboi. I never said it had to remain a one liner. In fact, that was my point. One liners rarely stay that way. And when you venture past your very narrow mindset you find the problems in shell. And when you venture past yours, you'll find that ALL programming languages have SERIOUS flaws in them... and that most can get this particular relatively simple job done, just fine, with fairly similar amounts of effort by someone who is sufficiently skilled in that particular language. In other words, if it takes you only 15 minutes to write something to do the job in Python, because you enjoy Python, someone else will also just as easily (to them) write the same program with the same results in shell, or Perl, or zsh's flavor of shell or whatever. Some other folks can write the thing just as easily and quickly (from their perspective) in REXX, C, whatever else you can think of -- in this case, something that can make system calls to the outside heavy- hitter conversion software that's really doing the hard work. It doesn't matter -- at all -- what you choose, if you're comfortable with your choice. Even if you're not good with a particular language or any language, starting the project and ignoring the constant clamor of the hoards of people spending their time arguing about which language is better, you'll get far more done than they ever will accomplish. It's just something for coders (who are human and have different tastes) to argue incessantly over, and for some to evangelize as religion. You appear to have found the God of Python meets your every need, and you bow down and submit your reverent respect for the sacrament of Whitespace, as all who follow the Python path, must. The original poster seemed worried that he only knows a couple of (perhaps) obscure languages. If those languages can't make system calls, he'll have to learn something new. But the hardest concept to pass to folks staring at that mountain is that the underlying concepts of variables, loops, conditionals, etc etc etc... don't change! I'll give you one thing Steve, you were one of the only people to publish code samples. Nicely done on that. But I truly believe (after watching these debates go on literally for over a decade in many cases) that the choice of language is personal, and more a preference than something people can articulate properly in terms of better. Something I like might be a much better way to eplain it. I think it matters little, for such a small and simple program, what language is used. The OP just needs to try a few and see what they like. -- Nate Duehr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Aug 10, 10:30 am, s. keeling [EMAIL PROTECTED] wrote: Ron Johnson [EMAIL PROTECTED]: Just remember to tell you editor to inserts spaces as tab and set the tab width to something reasonable like 4. E, yuck! It's code like that which makes me happy for emacs: C-x h# mark entire buffer M-x untabify # replace tab chars with spaces I despise tabs. Check out the expand command. It's easier to script when you need to do some directories full of files. Stuart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Nate Duehr wrote: And when you venture past yours, you'll find that ALL programming languages have SERIOUS flaws in them... and that most can get this particular relatively simple job done, just fine, with fairly similar amounts of effort by someone who is sufficiently skilled in that particular language. Which was never my point. As expressed several times now. Please stop ignoring it. In other words, if it takes you only 15 minutes to write something to do the job in Python, because you enjoy Python, someone else will also just as easily (to them) write the same program with the same results in shell, or Perl, or zsh's flavor of shell or whatever. Sorry, I seriously doubt that. It doesn't matter -- at all -- what you choose, if you're comfortable with your choice. Even if you're not good with a particular language or any language, starting the project and ignoring the constant clamor of the hoards of people spending their time arguing about which language is better, you'll get far more done than they ever will accomplish. Difference is the OP was requesting opinions. You don't like mine. Great, we got it. You appear to have found the God of Python meets your every need, and you bow down and submit your reverent respect for the sacrament of Whitespace, as all who follow the Python path, must. Sorry, no, that is where you are wrong. I am correcting the misconceptions that other people have about whitespace and also giving my hard earned experience in scripting several different languages on many different platforms. However if you think for one second that I think others should conform to my ideals then you missed my final message to the OP. - Manon Metten wrote: But I think the scope of regina-rexx is somewhat limited compared to python. But for the moment I can use it and gradually learn bash, python, perl or whatever suits me. In all honesty, that is the best thing to do. Go with what you know and expand into what you prefer from there. - Hardly sounds like someone pushing his ideals on others. There's a fine line between expressing an opinion, correcting misconceptions and believing that others are truly wrong in what they do. I've done two of the three and neither is the one you think I've done. The original poster seemed worried that he only knows a couple of (perhaps) obscure languages. If those languages can't make system calls, he'll have to learn something new. But the hardest concept to pass to folks staring at that mountain is that the underlying concepts of variables, loops, conditionals, etc etc etc... don't change! Nope, they don't. But at the same token there are measurable and quantifiable differences in the effectiveness of coding practices and the effect a language has on how quickly one can hammer out code. I'll give you one thing Steve, you were one of the only people to publish code samples. Nicely done on that. Two or three, actually. But I truly believe (after watching these debates go on literally for over a decade in many cases) that the choice of language is personal, That it is. But when there are skewed perceptions about what comes into a language then one can miss great opportunities which might better suit their personal feel of what a language should or should not do. I think it matters little, for such a small and simple program, what language is used. The OP just needs to try a few and see what they like. But that's just it. The OP did not mention what use he had for his language. You're looking at the narrow scope of oh, someone wants to convert files from A to B. That is not what was asked. What was asked was a general case of which is better, bash or Python. Both are fully capable of handling the quick and dirty cases that shell does a passable job at. That is why the example of converting a file from A to B came about. But of those two choices only Python can go on to do a great many other things. Given the general case with no specific information are you going to recommend the simplistic and idiosyncratic, limited use shell scripting language or are you going to recommend the language which can handle anything shell does just as well, can also be used for near-native programming of graphical, cross-platform applications, has been used as a scripting languages for games as well as the main programming language for games themselves? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Ron Johnson [EMAIL PROTECTED]: Just remember to tell you editor to inserts spaces as tab and set the tab width to something reasonable like 4. E, yuck! It's code like that which makes me happy for emacs: C-x h# mark entire buffer M-x untabify # replace tab chars with spaces I despise tabs. -- Any technology distinguishable from magic is insufficiently advanced. (*)http://blinkynet.net/comp/uip5.html Linux Counter #80292 - -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Thursday 09 August 2007, Manon Metten wrote: Hi Florian, On 8/8/07, Florian Kulzer [EMAIL PROTECTED] wrote: http://www.tldp.org/LDP/Bash-Beginners-Guide/html/index.html http://www.comp.leeds.ac.uk/Perl/start.html http://hetland.org/writing/instant-python.html Thanks for the links. They are very useful. Although I did already some reading of Bash-Beginners-Guide I still find it hard to understand. But I think I gradually will make some progress. Greetings, Manon. The point is: pick one and learn it. Doesn't matter which. When you have gained some knowledge, you won't have to ask such pointless questions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Thursday 09 August 2007, Nelson Castillo wrote: On 8/9/07, David Brodbeck [EMAIL PROTECTED] wrote: On Aug 9, 2007, at 10:19 AM, Steve Lamb wrote: Actually, it isn't. At no time have I ever had any problems with Python code which would not also be an issue in other code as well. The only difference being you have to be careful about indention in one case, braces in the other. Still, after dealing with all the nightmares of things like 'make' that care about tabs vs. spaces, etc., I'm inclined to shy away from languages where whitespace is critically important. Whitespace is so fragile. I make trailing spaces and TABS visible in vim. I know it's hard to keep conventions when you work with a team. http://wiki.freaks-unidos.net/weblogs/arhuaco/visible-spaces-in-vim Great tip. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Aug 7, 1:50 pm, Manon Metten [EMAIL PROTECTED] wrote: - Which one is easiest to learn? - Which one is more powerful? - Can I execute /bin commands from within a python script Sorry if someone else already pointed to the Python Tutorial, but the very beginning tries to address when you might want to use Python instead of a shell script. Written by Guido his own self. I'm fairly new to both Python and Linux and after about a year or so of both I would say that Python is easier to learn and more powerful, but it's silly not to learn the ins and outs of commands like FIND and GREP which, when used properly, often start becoming scripts. I would say learn both, and spend your time deciding WHEN to use which, not choosing between them. from http://docs.python.org/tut/node3.html If you do much work on computers, eventually you find that there's some task you'd like to automate. For example, you may wish to perform a search-and-replace over a large number of text files, or rename and rearrange a bunch of photo files in a complicated way. Perhaps you'd like to write a small custom database, or a specialized GUI application, or a simple game. If you're a professional software developer, you may have to work with several C/C++/Java libraries but find the usual write/compile/test/re- compile cycle is too slow. Perhaps you're writing a test suite for such a library and find writing the testing code a tedious task. Or maybe you've written a program that could use an extension language, and you don't want to design and implement a whole new language for your application. Python is just the language for you. You could write a Unix shell script or Windows batch files for some of these tasks, but shell scripts are best at moving around files and changing text data, not well-suited for GUI applications or games. You could write a C/C++/Java program, but it can take a lot of development time to get even a first-draft program. Python is simpler to use, available on Windows, MacOS X, and Unix operating systems, and will help you get the job done more quickly. rd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-09 23:37:52 -0700, Steve Lamb wrote: Vincent Lefevre wrote: On 2007-08-09 09:48:54 -0700, Steve Lamb wrote: The same in Python but with far greater functionality: and a security hole! And the one liner stopped this how, exactly? Because the result of a parameter expansion or filename generation is not interpreted by the shell (unless explicitly told). result = os.system(lame -h -b 160 '%s' '%s' % (file, mp3)) Imagine a filename contains: ' `some command` Ok, I'll imagine that. import os foo = ' `ls -l` os.system(echo '%s' % foo) sh: -c: line 0: unexpected EOF while looking for matching `'' sh: -c: line 1: syntax error: unexpected end of file 512 Yes, because you get: echo '' `ls -l`' which is not valid. Try with: foo = ' `ls -l` ' so that you get: echo '' `ls -l` '' In portable POSIX sh, yes. But with superior shells such as zsh, this is trivial. However, for complex transformations, though this can often be written with few characters, this is completely unreadable! (See for instance, the advanced zsh completion functions.) Which is why I strayed away from Perl into Python land. This is a very subjective argument. One *can* write readable Perl scripts. Also remember TIMTOWTDI. And while zsh is fairly ubiquitous in Linux/BSD land it is still shell with the problems that come with it. BTW, in case you feel I am coming from Bash land with my anti-shell sentiments... [EMAIL PROTECTED]:~} grep grey /etc/passwd grey:x:1000:1007:Steve Lamb:/home/grey:/bin/zsh ...been on zsh for years. I love its far superior completion and command history. Won't code in it, Well, for some kinds of code (e.g. those dealing with a sequence of external utilities), it is better to write a shell script, otherwise this would mean a sequence of system or equivalent. For instance, here's my script to update Mutt: #!/usr/bin/env zsh # Usage: update-mutt cvs or hg update options source ~/.zshenv source ~/.zalias set -e set -x cd ~/software/mutt rm -rf mutt if [[ -d mutt-hg ]] then if host dev.mutt.org /dev/null; then # To create the mutt-hg directory: # hg clone http://dev.mutt.org/hg/mutt mutt-hg pushd mutt-hg hg pull hg update $@ popd else # Not necessarily a fatal error since the Mutt source could have # been updated previously (e.g., before a PPP deconnection). echo Warning! Mutt source cannot be updated by hg pull. 2 fi cp -R mutt-hg mutt else if host cvs.mutt.org /dev/null; then pushd mutt-cvs cvs update $@ popd else # Not necessarily a fatal error since the Mutt source could have # been updated previously (e.g., before a PPP deconnection). echo Warning! Mutt source cannot be updated by CVS. 2 fi cp -R mutt-cvs mutt fi cd mutt patch -p1 ~/wd/src/patches/mutt/mutt.patch cp ~/wd/fr.po/mutt po/fr.po prepmutt make -j2 make install You can see most commands that have no native equivalent in non-shell languages: hg, cvs, patch, prepmutt, make (and probably even cp). however, not as long as #!/bin/env python is around. And the joy of it is that if a box has zsh chances are high it'll have python, too. ;) Nope. The first thing I do when I get an account is to install a recent version of zsh, so that zsh is always installed, but not necessarily python! :) Of course, one could also compile python, but with its different versions which are not compatible, this is annoying, and it takes too much space on PDAs (my Zaurus has perl and zsh, but not python). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-09 23:48:03 -0700, Steve Lamb wrote: Vincent Lefevre wrote: Braces are not a problem: they are kept in a copy-paste, and if for some reason a brace is missing (because you did a mistake), then you'll get a syntax error Unless, of course, you are programming in C with that pesky... if foo; bar; ...problem. Of course, you need to be careful on what you copy-paste. Problems can also happen with: foo1; foo2; foo3; if you want to move these three lines, but if you forget the 3rd one. Now, concerning the C language, there's a reason why it is recommended to always use braces even when they aren't needed... In Python, you may need to re-indent (correctly!) all what you've copy-pasted, and if you forget an indentation, the syntax will still be valid. Which is not that hard. Have you done it? Doubt it. I have, many times. Say I'm 3 levels deep and paste something 2 levels deep. Like this: for foo in bar: if foo 200: print baz else: print spam OK, not in every case. But there are cases where it is still valid. For instance, if you have: for foo in bar: print blah1 print blah2 and you want to paste: if foo 200: print baz else: print spam so that you get: for foo in bar: print blah1 if foo 200: print baz else: print spam print blah2 which is valid, isn't it? You need to re-indent to: for foo in bar: print blah1 if foo 200: print baz else: print spam print blah2 and it's too easy to get this wrong. And if you want to check a posteriori that you (or someone else) did it right, standard tools like diff -w (useful if other languages) won't give you any valuable information. Secondly, as I stated earlier, any programmer's editor will be able to indent by blocks. This is useful. However when the blocks are large (e.g. if they don't fit in the screen), it's easy to make a mistake. I know vim and idle can, pretty sure emacs can as well for those of that sect. The problem with Emacs is that the mark changes too easily. So, this is not reliable (I always check my changes with diff / diff -w). Also, as I said, would you really trust someone who doesn't reindent their code so they can read it even if they are cut and pasting code with braces? No, but again, changes made by someone can easily be checked with diff -w. Personally, I have all my codes automatically re-indented. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Haskell defines TABs as being 8 spaces apart and I expect Python to do the same. Python should do it because Haskell does it?? Not because Haskell is so influential, but because the same causes tend to result in the same effects. Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 2007-08-08 18:52:11 +0200, Manon Metten wrote: Hi Nelson, On 8/8/07, Nelson Castillo [EMAIL PROTECTED] wrote: Why did you switch from Perl to Python? I found the code I wrote easier to understand. But as I said before, I still use Perl for some tasks. OK. I forgot to mention Perl in my initial question. But if the code is easier to understand I guess I better try to learn Python first. Well, I find Perl easier to understand. The problem may be with some programmers who don't know how to write readable code... Now, the thing I really hate concerning python is that it is sensitive to indentation; this means that some operations like copy-paste or inserting a loop can easily destroy code. And diff -b or diff -w can't be used reliably. Also you need to take other things into account: * What the language can express and what you need (e.g. closures, etc.). * The stability of the language (i.e. if features are removed or added to new versions). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Vincent Lefevre wrote: Why not zsh (more powerful than bash) or perl? Because to some Perl is horrible compared to Python. for FILE in *.wav; do lame -h -b 160 $FILE $FILE.mp3; done Correct me if I'm wrong but wouldn't I just end up with with a bunch of files named blahblah.wav.mp3? [EMAIL PROTECTED]:/misc/Music$ for FILE in *.mp3; do echo $FILE.mp3; done Eric Cartman-ComeSailAway.mp3.mp3 Happy Rhodes - Summer.mp3.mp3 Happy Rhodes - The Wretches Gone Awry.mp3.mp3 Happy Rhodes - When The Rain Came Down.mp3.mp3 Johnny Lang - Breakin' Me.mp3.mp3 johnny lang - hit the ground running (1).mp3.mp3 Johnny Lang - Matchbox.mp3.mp3 Johnny Lang - Still Raining.mp3.mp3 Johnny Lang - sugarman.mp3.mp3 So now we have to strip stuff out of the filename which involves at least a call to cut (properly escaped, of course). Meh, even simple examples in shell should be avoided. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Thu, 9 Aug 2007, Steve Lamb wrote: Vincent Lefevre wrote: Why not zsh (more powerful than bash) or perl? Because to some Perl is horrible compared to Python. for FILE in *.wav; do lame -h -b 160 $FILE $FILE.mp3; done Correct me if I'm wrong but wouldn't I just end up with with a bunch of files named blahblah.wav.mp3? [EMAIL PROTECTED]:/misc/Music$ for FILE in *.mp3; do echo $FILE.mp3; done Eric Cartman-ComeSailAway.mp3.mp3 Happy Rhodes - Summer.mp3.mp3 Happy Rhodes - The Wretches Gone Awry.mp3.mp3 Happy Rhodes - When The Rain Came Down.mp3.mp3 Johnny Lang - Breakin' Me.mp3.mp3 johnny lang - hit the ground running (1).mp3.mp3 Johnny Lang - Matchbox.mp3.mp3 Johnny Lang - Still Raining.mp3.mp3 Johnny Lang - sugarman.mp3.mp3 So now we have to strip stuff out of the filename which involves at least a call to cut (properly escaped, of course). Meh, even simple examples in shell should be avoided. It has nothing to do with shell, python, perl or what ever. You would still have rename the file extention: for FILE in *wav ; do lame -h -b 160 $FILE `echo $FILE |sed s/.wav/.mp3/g ` ; done -+- 8 out of 10 Owners who Expressed a Preference said Their Cats Preferred Techno. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Manon Metten wrote:
- Which one is easiest to learn?
Between Bash and Python, Python.
- Which one is more powerful?
Python.
- Can I execute /bin commands from within a python script
(something like mkdir or ls)?
Yes, though for those examples you don't need to. The os library gives
you the ability to do the above and much more. There is also a module called
shutil which provides the basic functionality of different shell utilities
available natively in Python. I have rarely had to resort to calling
something in shell to do anything shell can do.
Or should I learn bash scripting anyway?
Learn enough to be able to parse it and convert it to your language of
choice. There are exceptions, of course, but by and large it has been my
experience that any place you're required to use shell Python is also
available and a far better choice. As an example here is the shell example
given earlier:
for FILE in *.wav; do lame -h -b 160 $FILE $FILE.mp3; done
The same in Python but with far greater functionality:
import os
for file in os.listdir('.'):
root, ext = os.path.splitext(file)
if ext.lower() == 'wav':
mp3 = root + '.mp3'
result = os.system(lame -h -b 160 '%s' '%s' % (file, mp3))
if result:
print '%s not converted' % file
Longer, yes. Easier to follow? Most certainly. Superior, no doubt. The
shell example would miss WAV, Wav, wAv, etc. Secondly the only place we need
to escape the variable is when we need shell to do some work, namely the call
to lame. Finally we don't end up with '.wav.mp3' files all over the place.
We can check the results easily and handle failures gracefully. Can all of
that be done in shell? Certainly. Is it worth doing in shell? Not hardly.
I don't use shell even for one liners these days because of the errors
introduced by globbing and spaces in filenames. Yes, if one keeps them in
mind when writing shell then they aren't /too/ much of a problem. But in a
proper language like Python (Perl, Ruby, take your pick) one doesn't have to
keep it in mind *at all* except when dealing with shell. Not to mention the
native methods for dealing with some issues, like stripping the extension from
the root of a file, are trivial in Python while an exercise in frustration in
pure shell.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Hi Florian, On 8/8/07, Florian Kulzer [EMAIL PROTECTED] wrote: http://www.tldp.org/LDP/Bash-Beginners-Guide/html/index.html http://www.comp.leeds.ac.uk/Perl/start.html http://hetland.org/writing/instant-python.html Thanks for the links. They are very useful. Although I did already some reading of Bash-Beginners-Guide I still find it hard to understand. But I think I gradually will make some progress. Greetings, Manon.
Re: bash vs. python scripts - which one is better?
On Thu, Aug 09, 2007 at 09:25:20 -0700, Steve Lamb wrote:
Vincent Lefevre wrote:
Why not zsh (more powerful than bash) or perl?
Because to some Perl is horrible compared to Python.
for FILE in *.wav; do lame -h -b 160 $FILE $FILE.mp3; done
Correct me if I'm wrong but wouldn't I just end up with with a bunch of
files named blahblah.wav.mp3?
[...]
So now we have to strip stuff out of the filename which involves at least
a call to cut (properly escaped, of course). Meh, even simple examples in
shell should be avoided.
You don't need to use cut; bash can do it directly if you use
${FILE%wav}mp3 as the output filename in the for loop.
--
Regards,| http://users.icfo.es/Florian.Kulzer
Florian |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Hi Vincent, On 8/9/07, Vincent Lefevre [EMAIL PROTECTED] wrote: zsh is more powerful, e.g. recursive globbing, MULTIOS, more powerful parameter expansion, tied parameters... In fact, zsh is better mainly for interactive use (better completion mechanisms, multiline editor). I'll take a look at their website. Well, I find Perl easier to understand. The problem may be with some programmers who don't know how to write readable code... Now, the thing I really hate concerning python is that it is sensitive to indentation; this means that some operations like copy-paste or inserting a loop can easily destroy code. And diff -b or diff -w can't be used reliably. Well, that's a major disadvantage to me too. Also you need to take other things into account: * What the language can express and what you need (e.g. closures, etc.). OK. On my Amiga I had not so much choice, so in many cases, I had to do some work-around in order to achieve what I wanted. But in Linux, waw, it is so comprehensive that the choices are somewhat overwhelming. Thanks for your reply, Manon.
Re: bash vs. python scripts - which one is better?
Jeff D wrote: It has nothing to do with shell, python, perl or what ever. You would still have rename the file extention: Yes, you would. And therein lies the point. One liners often aren't. Quite often something comes up and whoops, need to do this and then d'oh, need to do that and pretty soon that one liner is taking up 3 lines on the screen and would be far easier to read if it were written in a text file. I prefer to just skip the whoops, need to add this step prior to getting to the text file and just write in a language that is far better suited to the task. For extremely small operations I lose a small amount of time. For anything barely above the most basic complexity I gain time. Not only that but I gain a metric buttload of functionality for a minimum of trouble. Quick, take your one liner, have it traverse an entire directory tree converting all the wavs (regardless of capitalization) to mp3s, oggs and flac, sorting all 4 into their own directory trees. For me I just need to change my small script into a function, wrap it inside os.walk() and have calls to os.makedirs() and shutil.copy() to do all the work. Several more minutes of work and I can add in checks for the same files with different names, prompt the user to pick a name to use, convert that one and delete the rest. Then for my final trick I can wrap it all up as a library, still retaining its ability to run as a stand alone script, and import it into other Python scripts. That is where shell falls down. A decent tinkerer starts with a this'd be neat few lines of code and expands it to a dozen, several dozen, hundreds of lines of code. I have not found a person who would argue that shell is viable outside a dozen or so lines of code; at least not when there are alternatives like Python, Perl or Ruby laying around to be used. It is that capacity to keep adding, and adding, and adding, growing it larger, splitting it into parts, reusing all those parts that shell simply cannot do as effectively as languages designed to do that from the get go. Real world example. At work there was a daily reports process that I wanted to automate. Since we're working on Windows conventional shell was right out. So I convinced them to install Python on that machine. In the 10 months since that time the original report-filing script has exploded into 3 discrete libraries, 3 main scripts which call approximately 8 other scripts (which are usable stand alone). It does everything from report-filing to account verification and a baby-DB query. It all grew from a simple 2kb script which was replacing a badly broken batch file to the current size in excess of 40kb of Python code. Note that none of the functionality in it today was planned from the first day. I would have tore my hair out doing the simplest things in shell much less when the time came to rewrite all of that from shell to Python. Better that I started in Python and grew from there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Manon Metten wrote: Well, I find Perl easier to understand. The problem may be with some programmers who don't know how to write readable code... Now, the thing I really hate concerning python is that it is sensitive to indentation; this means that some operations like copy-paste or inserting a loop can easily destroy code. And diff -b or diff -w can't be used reliably. Well, that's a major disadvantage to me too. Actually, it isn't. At no time have I ever had any problems with Python code which would not also be an issue in other code as well. The only difference being you have to be careful about indention in one case, braces in the other. Besides, let's face it, if there is a person who puts code into place and then doesn't make the indention make sense to ensure they did the job properly is that someone who's opinion we're going to trust when it comes to decent coding practices? Most people are going to make the indention match *anyway*. Since pretty much every programmer's editor comes with de/indent a block of text there is no problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Hi Steve,
On 8/9/07, Steve Lamb [EMAIL PROTECTED] wrote:
Or should I learn bash scripting anyway?
Learn enough to be able to parse it and convert it to your language of
choice.
That's a valuable advice. It'll save me a lot of time and yet I'll be able
to achieve what I want.
import os
for file in os.listdir('.'):
root, ext = os.path.splitext(file)
if ext.lower() == 'wav':
mp3 = root + '.mp3'
result = os.system(lame -h -b 160 '%s' '%s' % (file, mp3))
if result:
print '%s not converted' % file
Longer, yes. Easier to follow? Most certainly. Superior, no
doubt. The
shell example would miss WAV, Wav, wAv, etc. Secondly the only place we
need
to escape the variable is when we need shell to do some work, namely the
call
to lame. Finally we don't end up with '.wav.mp3' files all over the
place.
We can check the results easily and handle failures gracefully. Can all
of
that be done in shell? Certainly. Is it worth doing in shell? Not
hardly.
On my Amiga I'm used to ARexx. It has some same advantages over AmigaDOS
like you describe above about bash vs. python. Fortunately there's
regina-rexx for
Linux. It has the same syntax and I've already written some scripts
combining
regina-rexx and grep. But I think the scope of regina-rexx is somewhat
limited
compared to python. But for the moment I can use it and gradually learn
bash,
python, perl or whatever suits me.
Greetings, Manon.
Re: bash vs. python scripts - which one is better?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/09/07 11:51, Florian Kulzer wrote:
On Thu, Aug 09, 2007 at 09:25:20 -0700, Steve Lamb wrote:
Vincent Lefevre wrote:
Why not zsh (more powerful than bash) or perl?
Because to some Perl is horrible compared to Python.
for FILE in *.wav; do lame -h -b 160 $FILE $FILE.mp3; done
Correct me if I'm wrong but wouldn't I just end up with with a bunch of
files named blahblah.wav.mp3?
[...]
So now we have to strip stuff out of the filename which involves at least
a call to cut (properly escaped, of course). Meh, even simple examples in
shell should be avoided.
You don't need to use cut; bash can do it directly if you use
${FILE%wav}mp3 as the output filename in the for loop.
Or use basename(1).
- --
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGu1HnS9HxQb37XmcRAuxhAKDROJfK9dx2QPwvr+jgyUFz7cXQ8QCfVyvb
LVICBc+TtSyr1djleMIEK1k=
=PqqS
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Hi Steve, On 8/9/07, Steve Lamb [EMAIL PROTECTED] wrote: python ... is sensitive to indentation; Well, that's a major disadvantage to me too. Actually, it isn't. At no time have I ever had any problems with Python code which would not also be an issue in other code as well. The only difference being you have to be careful about indention in one case, braces in the other. Besides, let's face it, if there is a person who puts code into place and then doesn't make the indention make sense to ensure they did the job properly is that someone who's opinion we're going to trust when it comes to decent coding practices? Most people are going to make the indention match *anyway*. Since pretty much every programmer's editor comes with de/indent a block of text there is no problem. Than, probably I didn't understand it correct. I thought of it as some prefixed indentation. I like eg. to indent with two spaces and not four or six. But then I consequently stick to it. If that's what you mean, then it ain't no problem for me. Manon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/09/07 12:19, Steve Lamb wrote: Manon Metten wrote: Well, I find Perl easier to understand. The problem may be with some programmers who don't know how to write readable code... Now, the thing I really hate concerning python is that it is sensitive to indentation; this means that some operations like copy-paste or inserting a loop can easily destroy code. And diff -b or diff -w can't be used reliably. Well, that's a major disadvantage to me too. Actually, it isn't. At no time have I ever had any problems with Python code which would not also be an issue in other code as well. The only difference being you have to be careful about indention in one case, braces in the other. Besides, let's face it, if there is a person who puts code into place and then doesn't make the indention make sense to ensure they did the job properly is that someone who's opinion we're going to trust when it comes to decent coding practices? Most people are going to make the indention match *anyway*. Since pretty much every programmer's editor comes with de/indent a block of text there is no problem. Just remember to tell you editor to inserts spaces as tab and set the tab width to something reasonable like 4. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGu1TRS9HxQb37XmcRAhLsAJ9jaJ+/CsXhjkiATKufjrJcUB1T+ACg3rPP tJLPLTlCgvVtnsxumbRUXiM= =4+Bb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Jeff == Jeff D [EMAIL PROTECTED] writes:
You would still have rename the file extention:
for FILE in *wav ; do lame -h -b 160 $FILE `echo $FILE
|sed s/.wav/.mp3/g ` ; done
Or just use the shell itself:
for FILE in *wav ; do lame -h -b 160 \$FILE\ \${FILE%.*}.mp3\; done
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Thu, 9 Aug 2007, mmiller3 wrote:
Jeff == Jeff D [EMAIL PROTECTED] writes:
You would still have rename the file extention:
for FILE in *wav ; do lame -h -b 160 $FILE `echo $FILE
|sed s/.wav/.mp3/g ` ; done
Or just use the shell itself:
for FILE in *wav ; do lame -h -b 160 \$FILE\ \${FILE%.*}.mp3\; done
Mike
Makes even more sense! Thanks! I don't know how many times I've read over
shell substitution, just never clicked I guess. But, it's always good to
learn new tricks!
-+-
8 out of 10 Owners who Expressed a Preference said Their Cats Preferred Techno.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Python intention (Was: bash vs. python scripts - which one is better?)
Manon Metten wrote:
Than, probably I didn't understand it correct. I thought of it as some
prefixed indentation. I like eg. to indent with two spaces and not four or
six. But then I consequently stick to it. If that's what you mean, then it
ain't no problem for me.
It is but it isn't. Take my previous example of code. There are 3 blocks
in it. The indention tells both the human and the interpretor which block is
which.
import os
for file in os.listdir('.'):
root, ext = os.path.splitext(file)
if ext.lower() == 'wav':
mp3 = root + '.mp3'
result = os.system(lame -h -b 160 '%s' '%s' % (file, mp3))
if result:
print '%s not converted' % file
I chose 4 spaces because that is the standard of the Python community.
You can do 2, as I did when I converted from Perl to Python, and as long as
you're consistent then you'll have no problems in your code. You will have
some minute problems importing code intended with 4 spaces but it really is
trivial to fix. On the other hand switching to 4 spaces makes it uniform and
I have found that the reasons I used 2 in Perl don't occur much in Python
though that might be more a function of my experience resulting in more
concise code than anything else.
Also you don't have to worry about indention as slavishly as in Fortran
which is what some people's experience with significant indention comes from.
The following is perfectly legal and identical in Python:
if something or that_thing and not something_else:
if something or
that_thing and
not something_else:
Also things like this:
foo = [spam,
ham,
eggs,
baked beans,
special sauce]
Significant indention does not apply inside statements or declarations.
It really is quite natural if you indent properly in the first place.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python intention (Was: bash vs. python scripts - which one is better?)
Hi Steve, Thanks for explaining. I'll examine some scripts I'll find on the web, to get an idea of how it looks. Manon.
Re: bash vs. python scripts - which one is better?
On Aug 9, 2007, at 9:25 AM, Steve Lamb wrote: for FILE in *.wav; do lame -h -b 160 $FILE $FILE.mp3; done Correct me if I'm wrong but wouldn't I just end up with with a bunch of files named blahblah.wav.mp3? Follow it with rename .wav.mp3 .mp3 *. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On Aug 9, 2007, at 10:19 AM, Steve Lamb wrote: Actually, it isn't. At no time have I ever had any problems with Python code which would not also be an issue in other code as well. The only difference being you have to be careful about indention in one case, braces in the other. Still, after dealing with all the nightmares of things like 'make' that care about tabs vs. spaces, etc., I'm inclined to shy away from languages where whitespace is critically important. Whitespace is so fragile. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
On 8/9/07, David Brodbeck [EMAIL PROTECTED] wrote: On Aug 9, 2007, at 10:19 AM, Steve Lamb wrote: Actually, it isn't. At no time have I ever had any problems with Python code which would not also be an issue in other code as well. The only difference being you have to be careful about indention in one case, braces in the other. Still, after dealing with all the nightmares of things like 'make' that care about tabs vs. spaces, etc., I'm inclined to shy away from languages where whitespace is critically important. Whitespace is so fragile. I make trailing spaces and TABS visible in vim. I know it's hard to keep conventions when you work with a team. http://wiki.freaks-unidos.net/weblogs/arhuaco/visible-spaces-in-vim BTW, I haven't found a better color for the tabs. One that is more similar to the background. Regards, Nelson.- -- http://arhuaco.org http://emQbit.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bash vs. python scripts - which one is better?
Just remember to tell you editor to inserts spaces as tab and set the tab width to something reasonable like 4. Please don't. TABs are 8 spaces apart. Always have been, always will be. People playing silly tricks with tab-width is the main reason why using TABs in languages like Python is a bad idea. Stefan PS: Also remember that the Python interpreter can't read your .emacs to figure out the width of a TAB you intended. Haskell defines TABs as being 8 spaces apart and I expect Python to do the same. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
